Beth Massi - Sharing the goodness that is VB : Data

Building Occasionally Connected Smart Clients with WPF

Beth Massi — Mon, 02 Nov 2009 22:57:00 GMT

This month Dev Pro Connections has an article by Milind Lele on using Sync Services in a WPF application:

Building Occasionally Connected Smart Clients with WPF

With Sync Services and Visual Studio 2008 you can visually design your local data cache and have it automatically synchronize your data with the backend remote database. So instead of figuring out your own caching mechanisms on the client, you can use SQL CE to store the local data and then use the sync framework to merge data with the backend.

If you’re looking to improve scalability of your client applications then you should consider caching data that is read-only, user-specific, changes rarely, or can tolerate some staleness. ADO.NET Sync Services can really help here.

You can catch more of Milind and team over on the VS Data Team Blog: http://blogs.msdn.com/vsdata/

Enjoy!

Inserting Master-Detail Data into a SQL-Server Compact Edition Database

Beth Massi — Wed, 16 Sep 2009 05:11:00 GMT

Yesterday John posted on the Visual Studio Data blog how to Refresh the Primary Key Identity Column during an Insert Operation using SQL Server. In that post he shows how the DataSet designer sets up a batch Insert statement to retrieve identity keys automatically. A while back I wrote about how to insert data into an Access database using TableAdapters and identity keys. Because Access doesn’t support batch statements, the Visual Studio Dataset designer doesn’t generate the code to retrieve the identity on new rows, so you end up having to write a bit of code yourself to do this as I showed in that post.

Since then I’ve had similar questions about how to do the same thing but using a SQL CE (Compact Edition) database so I thought I’d present the updated code to work with this type of database. Let’s take a look at how to do that, but first some background. (If you don’t care, just skip to the end for the code and sample download ;-))

What is SQL-Server Compact Edition (SQL CE)?

SQL CE is a file-based, single-user database that is really handy to use as local storage for your client applications because of its small footprint. And it’s included with Visual Studio 2008. Check out what’s new in SQL CE 3.5 here. One very typical use of SQL CE is as a local data cache to your SQL Server backend data using sync services in order to create an occasionally connected application. You can learn about the sync framework here and how to create a local data cache in Visual Studio 2008 here.

Setting up Parent-Child Tables and Relationships in SQL CE 3.5 Using Visual Studio 2008

To add a local database file to your Visual Studio 2008 project just select Add –> New Item, choose the Data category and then select Local Database. This will add a SQL CE database file with an .sdf extension to your project.

This will trigger the Data Sources wizard to start but first we need to create some tables in our database so cancel the wizard. Next open up the Server Explorer (or Database Explorer if you are using VS Express) and you should see your SQL CE database listed under Data Connections. Expand the database node and then right-click on Tables and select New Table. A dialog will open that allows you to design your table schema.

For this example I’ll create a parent Categories table and a child Products table with just a few fields to illustrate the concepts here. It’s important when you create a primary key that you choose the int data type, set Unique to Yes and then below in the column properties you set Identity to True. This will create an auto-incrementing, unique primary key.

Click OK when you’re done and then repeat the same process to add a new Products table. This time though we need to specify a field for the CategoryID foreign key and I’m going to make this a required field by setting Allow Nulls to No.

Now we need to add a relationship between these tables so that our little database will maintain referential integrity for us. We’re saying that a Product cannot exist without specifying a Category. We want the database to enforce this so that if we try to delete a Category it will prevent us from doing so if there are any Products. SQL CE 3.5 can maintain this kind of referential integrity for us, just go back to the Server Explorer and right-click on the Products table again but this time select Table Properties. Select the Add Relations page.

Type in the name of the relation you want to create and then select the Foreign Key Table Column, in my case I select CategoryID. Notice that you can also set up cascading or set null/default update and delete rules as well, but for this example we want to leave the rules as NO ACTION. Click Add Columns button then Add Relations button then click OK to save and close.

Setting up the Parent-Child DataSet

Now that we have the database set up we can design our DataSet. This is going to be almost exactly the same as how we set up our Access DataSet here so take a look at that post for the screen-shots, they’ll be the same here. To recap, you need to make sure you set up the relationship on the DataSet properly so that the primary key on the parent will cascade to the foreign key on the child. Right click on the relation in the DataSet designer and select "Both Relation and Foreign Key Constraint" and then set the Update and Delete rules to Cascade.

The other important thing you need to do is set the Primary Key fields on both DataTables to ReadOnly False. We need to do this so we can set them in code and have the DataRelation cascade rules work correctly.

The DataSet designer will set all the rest of the properties and statements up correctly so you don’t have to modify anything else, though I do encourage you to take a look through them. One important thing to notice is the AutoIncrement, AutoIncrementSeed and AutoIncrementStep properties here. These are set to True, –1 and –1 respectively. This means that on the DataSet (client side) the referential integrity on new rows is maintained between the products and categories DataTables using temporary primary keys that are negative integers. These do NOT correspond to the keys in the database for new rows. It’s not until we send the updates to the database that we get the real identity keys so keep that in mind. (And these properties are the same regardless if you are using SQL CE, Access, or SQL Server identity keys.)

Okay so now we are ready to design our master-detail form. This should be a familiar process at this point but just in case here’s a recap. Open the Data Sources window (Main Menu –> Data –> Show Data Sources) and you should see the Categories and Products DataTables that are in the DataSet we just created. Design your Master-Detail form like normal. For this example I drag the Categories as details and then select the related Products by expanding the Categories node and dragging the Products table under there. This will set up a relationship on the form as well so that when we select a Category, it will only show those related products. This is also important to get our inserts to work correctly because the temporary identity key (-1, –2, –3, etc) on the CategoryID will automatically cascade to the Product’s CategoryID.

Loading and Editing the Parent-Child DataSet

Now that the DataSet is set to enforce the foreign key relationships, this means that you must have a parent for every child so you have to load the data in parent then child order. Remember, you have to make sure that every row in the child DataTable will have a corresponding parent row in the parent DataTable. This also means that you have to make sure to call EndEdit on any new parent BindingSource before any children can be added. I’m doing this by adding a handler to the grid’s Enter event. So the code-behind for this form is the same as the Access sample I showed before:

Public Class Form1

    Private Sub CategoriesBindingNavigatorSaveItem_Click() _
                Handles CategoriesBindingNavigatorSaveItem.Click
        Me.Validate()
        Me.CategoriesBindingSource.EndEdit()
        'Make sure to call EndEdit on all BindingSources before an update
        Me.ProductsBindingSource.EndEdit()
        Me.TableAdapterManager.UpdateAll(Me.MyDatabaseDataSet)
    End Sub

    Private Sub Form1_Load() Handles MyBase.Load
        'Load parent before child because contraints are enabled on the DataSet
        Me.CategoriesTableAdapter.Fill(Me.MyDatabaseDataSet.Categories)
        Me.ProductsTableAdapter.Fill(Me.MyDatabaseDataSet.Products)
    End Sub
   
    Private Sub ProductsDataGridView_Enter() Handles ProductsDataGridView.Enter
        'You must commit the parent row to the DataTable before adding child rows 
        Me.CategoriesBindingSource.EndEdit()
    End Sub
End Class

Adding Code to Handle Inserts to SQL CE Databases

We need a way to set the primary key on the parent right after the row is inserted into the database and before any children are inserted. Now that we have keys cascading we just need to write code to handle the RowUpdated event on the DataAdapter inside the TableAdapter partial class. TableAdapters are generated classes that Visual Studio creates for us from the DataSet designer. These classes are declared as Partial Classes so that means we can add code to the same class even if it’s in a separate file. Right-click on the TableAdapter class in the DataSet Designer and select View Code and the partial class file that you can edit will be created for you.

Now we can write code to automatically query the database for the identity key because SQL CE supports the @@IDENTITY command just like Access. We need to execute this query after each new row has been inserted into the database, but before any children. If you’re using Visual Studio 2008 then the TableAdapterManager will handle sending parents first then children for insert operations so all we need to do is handle the DataAdapter’s RowUpdated event. Here’s the complete code listing for the DataSet and TableAdapter partial classes which includes code to set default values on the new rows. Notice it’s very similar to the Access code. We’re just working with a different data access client library by importing the System.Data.SqlServerCe instead of System.Data.OleDb.

Imports System.Data.SqlServerCe

Public Class SQLCEIDHelper
    ''' <summary>
    ''' Retrieves the primary key auto-number identity values from SQL CE
    ''' </summary>
    ''' <remarks></remarks>
    Public Shared Sub SetPrimaryKey(ByVal trans As SqlCeTransaction, _
                                    ByVal e As SqlCeRowUpdatedEventArgs)

        ' If this is an INSERT operation...
        If e.Status = UpdateStatus.Continue AndAlso _
           e.StatementType = StatementType.Insert Then
            Dim pk = e.Row.Table.PrimaryKey
            ' and a primary key PK column exists...
            If pk IsNot Nothing AndAlso pk.Count = 1 Then
                'Set up the post-update query to fetch new @@Identity
                Dim cmdGetIdentity As New SqlCeCommand("SELECT @@IDENTITY", _
                                                       CType(trans.Connection, SqlCeConnection), _
                                                       trans)
                
                'Execute the command and set the result identity value to the PK
                e.Row(pk(0)) = CInt(cmdGetIdentity.ExecuteScalar)
                e.Row.AcceptChanges()

            End If
        End If
    End Sub
End Class

Namespace MyDatabaseDataSetTableAdapters
    Partial Public Class CategoriesTableAdapter
        Private Sub _adapter_RowUpdated(ByVal sender As Object, _
                                        ByVal e As SqlCeRowUpdatedEventArgs) _
                                        Handles _adapter.RowUpdated

            SQLCEIDHelper.SetPrimaryKey(Me.Transaction, e)
        End Sub
    End Class

    Partial Public Class ProductsTableAdapter
        Private Sub _adapter_RowUpdated(ByVal sender As Object, _
                                        ByVal e As SqlCeRowUpdatedEventArgs) _
                                        Handles _adapter.RowUpdated

            SQLCEIDHelper.SetPrimaryKey(Me.Transaction, e)
        End Sub
    End Class
End Namespace

Partial Class MyDatabaseDataSet
    Partial Class CategoriesDataTable
        Private Sub CategoriesDataTable_TableNewRow(ByVal sender As Object, _
                                            ByVal e As System.Data.DataTableNewRowEventArgs) _
                                            Handles Me.TableNewRow
            'Set defaults so that constraints don't fail when EndEdit is called
            Dim cat = CType(e.Row, CategoriesRow)
            cat.CategoryName = "[new]"
        End Sub
    End Class

    Partial Class ProductsDataTable
        Private Sub ProductsDataTable_TableNewRow(ByVal sender As Object, _
                                             ByVal e As System.Data.DataTableNewRowEventArgs) _
                                             Handles Me.TableNewRow
            'Set defaults so that constraints don't fail when EndEdit is called
            Dim product = CType(e.Row, ProductsRow)
            product.ProductName = "[new]"
        End Sub
    End Class
End Class

Now when we run our form, click the Add button on the ToolStrip to add a new Category and then enter new Products in the DataGridView below. Click Save and you will see the identity keys refresh back into the DataTables from our SQL CE database.

So to recap:

Create your SQL CE tables, set the PKs to an Identity Integer column and then set up the relation to enforce referential integrity
Create your DataSet and edit the relation and set it to a “Relation and Foreign Key Constraint” then set the Update and Delete rules to Cascade
Make sure the PKs on the DataTables in the designer are set ReadOnly False
Make sure to design your form so that the parent and related children BindingSources are set up properly
Call EndEdit on the ParentBindingSource before you attempt to insert any child rows into the child DataTable so that the parent row is committed to the parent DataTable
Use the TableAdapterManager to handle updating parents and children in proper order (this happens by default if you use the designer)
Add a handler to the DataAdapter’s RowUpdated event to query the database for the new identity (SELECT @@IDENTITY) and set the PK on the DataRow to that value and this will cascade to any related children automatically

Download the sample application from Code Gallery.

I hope that clears up the confusion on how to work with file-based databases like Access and SQL CE that don’t support batch statements. Once you understand how ADO.NET is working with your DataSets then it’s much easier to understand how to configure things like this. SQL CE is a great FREE database for single-user applications and I encourage you to have a look at it if you’re building these types of client applications.

SQL CE also supports the Entity Framework so that would probably be a good follow-up post to this one… next time! ;-)

Enjoy!

New “How Do I” Videos Released on Entity Framework & WPF

Beth Massi — Wed, 26 Aug 2009 20:18:08 GMT

Yesterday we released a couple more videos onto the Visual Basic Developer Center on building WPF data-entry forms with Entity Framework:

That makes 5 videos total on working with EF in WPF applications. Others released previously:

These videos are based on articles I’ve posted here in the past. So if you like reading better that watching videos here you go:

There are also additional resources listed on the How Do I video pages themselves pointing to topics in the MSDN Library.

Enjoy!

N-Tier Application Patterns with Entity Framework

Beth Massi — Thu, 06 Aug 2009 01:20:52 GMT

This month’s MSDN Magazine has a particularly good article in there by Danny Simmons, Development Manager on the Entity Framework team, on N-Tier Application Patterns with Entity Framework that I recommend reading through. He explains the design considerations you need to take into account when building n-tier applications and also discusses some of the improvements that are coming in .NET Framework 4.0 that will make building n-tier applications with EF much much easier. I’m personally looking forward to self-tracking entities myself, hooray!

Tim Mallalieu also has a good best practices article in this issue that I just started digging into regarding the next version of Entity Framework.

Enjoy!

Working with a Local Database File in Visual Studio

Beth Massi — Fri, 31 Jul 2009 22:58:00 GMT

In this post and video I’ve shown folks how to work with a local database file (.mdf, .mdb, .sdf) that resides directly inside your project in order to see updates made while debugging your application. If it looks like everything saves fine while debugging, but you can’t see the updates if you look directly in the database, then there’s a simple fix. Today the VS Data Team wrote up a great blog post on this as well so check it out!

In general I prefer to develop against attached SQL Server databases because it’s easier to debug. But if you’re working with SQL Compact or Access databases you’ll need to be aware of how the database file is copied out with your application EXE and what file you are really working with.

Enjoy!

Filtering Child DataTables Using TableAdapters

Beth Massi — Thu, 23 Jul 2009 03:02:53 GMT

Since my last post on filtering child collections using Entity Framework, I have had more than a few emails about how to load filtered child DataTables that are part of a master-detail relationship and then get them to save properly through the TableAdapters. Many people are running into the problem where the designer won’t automatically generate the update/insert/delete commands for you when you are writing a select statement that uses multiple tables. Of course you could specify your own statements manually (and often you need to because your Select statement is too complex) but in this case there’s a much better way to specify this filter and still get the benefit of the designer creating your commands.

For instance, let’s take the same database tables Customer and Orders that we’ve been working with:

NOTE: If you are unfamiliar with how to set up and work with master-detail (parent-child) tables check out this "How Do I" video first.

So say we want to only pull up the Orders on the Customer who’s LastName is “Massi” -- meaning we want to filter both the parent (Customer) and child (Orders) on Customer.LastName. There’s a couple ways to do this.

Specifying a New Query

TableAdapters are great at managing your queries. By default when you use the designer to select related tables it will automatically create default Fill and GetData select methods for you as well as generate the update//insert and delete statements for you. If you look in the properties for the TableAdapter you will see a SelectCommand generated for you that selects ALL the fields and ALL the rows of the table in the database. In 99.999% of the cases you want to filter these rows for scalability reasons. (And I urge you to do so).

Also notice that Visual Studio has created Insert/Update/Delete commands as well for us. We can easily specify a new query that filters our rows and still take advantage of these update/insert/delete commands. We want to do this for both our tables.

First right-click on the child TableAdapter (in this case OrdersTableAdapter) and select Add –> Query. Then choose your command type, here I’ll leave the default “Use SQL Statements”. Click Next. Then choose your query type, in this case choose the default “SELECT which returns rows”. Click Next. Now you can write your select statement.

It is VERY IMPORTANT that you only select the fields from the child (Orders) table and not include fields from other tables in the result set. Otherwise the generated commands will not work. You can filter the rows any way you like with a WHERE clause (and you definitely should) but keep in mind that if you select fields from other tables to be included in the result set, then you will need to specify your own Insert\Update\Delete commands above.

To write our filter on the child Orders table I’ll use the command builder to join the Customer table and then use the LastName in the WHERE clause.

Here’ I’m creating a parameterized query so that I can specify the LastName on the Form and not hard-code it here. Notice that the structure of the result set (the fields in the SELECT clause above) exactly match the fields in the OrdersDataTable.

SELECT Orders.OrderID,
        Orders.CustomerID,
        Orders.OrderDate,
        Orders.ShipDate,
        Orders.Modified
FROM    Orders INNER JOIN
        Customer ON Orders.CustomerID = Customer.CustomerID
WHERE (Customer.LastName = @LastName)

Click OK to get out of the Query Builder (if you were in there) and then Click Next. Now you get to choose which methods to generate and what they should be named. For this example I named them FillByLastName and GetDataByLastName. This creates methods on the TableAdapter that you can now use to query the child rows.

Now repeat this process for the parent table (Customer). Select the CustomerTableAdapter in the dataset designer, right-click and select Add –> Query. Same steps as before except the SELECT statement is much easier, no JOIN necessary, just a filtered WHERE clause.

SELECT CustomerID, LastName, FirstName, Address, City, State, ZIP, Modified
FROM Customer
WHERE LastName = @LastName

I named the methods the same as I did for the child, FillByLastName and GetDataByLastName.

Now you can design your master-detail form. From the Data Sources Window expand and then drag the parent (Customer) and then drag the related Orders (the one under Customer) onto your Windows form. Basically design your winform like normal and let Visual Studio generate the code to load and save for you.

The only thing you have to do now is change the method names on the TableAdapters (and make sure they load in parent then child order) in the form Load handler:

Private Sub Form1_Load() Handles MyBase.Load
    Me.CustomerTableAdapter.FillByLastName(Me.OMSDataSet.Customer, "Massi")
    Me.OrdersTableAdapter.FillByLastName(Me.OMSDataSet.Orders, "Massi")
End Sub

Everything else will work like before but now we are filtering both the tables. You can add as many new queries to the TableAdapters as you need. As long as the fields in your query (SELECT clause) match the structure of your generated DataTable then you can use the generated update/insert/delete commands.

But what if you already have hundreds of forms that use the default Fill or GetData methods and you really need to set up a filter on these SelectCommands because you don’t want to have to change all your forms? That’s pretty easy too.

Filtering the Default GetData and Fill Methods

If we want to modify the default Fill and GetData methods to support this filter then there’s a little trick we can do. Once the DataSet is set up with your “unfiltered” parent-child tables, open up the properties window and expand the SelectCommand (like pictured above) and edit the CommandText property for both of the TableAdapters. Specify the same select statements as above. Once you modify the property Visual Studio will ask you “Do you want to regenerate updating commands based on the new command text? (Current updating commands will be overwritten)”. Just say NO.

Now the calls to GetData and Fill will have a filter set but the generated commands will not be overwritten!

I hope this clears things up for folks. Remember that it’s best practice to put filters on your queries to narrow your result sets – this puts a lot less strain on your databases and networks. There’s a couple tricks you need up your sleeve to do this in Visual Studio, but it is the way it is so that the dataset designer can handle complex and completely custom scenarios too, like multi-table views and stored procedures. Hmmm… maybe it’s time for a How Do I video on that…. ;-)

Enjoy!

Master-Detail Data Binding in WPF with Entity Framework

Beth Massi — Wed, 15 Jul 2009 02:24:00 GMT

Today I thought I would talk about a really common scenario in data applications, creating a master-details (one-to-many) data entry form. I’ve written about WPF data binding and Entity Framework a lot in the past:

Posts:

Videos:

Today I want to pull these concepts together and walk through one way to create a master-detail form in WPF using entities from the Entity Framework. Specifically, we’ll declare CollectionViewSources in our XAML like I showed here, to bind to an ObservableCollection of entities like I showed here, where the children are explicitly loaded like I showed here. Everybody got that? ;-)

Creating the Entity Data Model

First let’s create a simple Entity Data Model (EDM) that demonstrates a Master-Detail relationship. I’ll use a simple database called OMS that has Customer and Orders tables with a non-nullable foreign key set up between them on CustomerID, meaning that no Order can exist without a Customer. This relationship is inferred by Entity Framework (EF) to set up the navigation properties. Notice that there is an Orders EntityCollection on Customer.

What we want to do is build a simple form that will let us Edit, Add, and Delete Customers and their Orders. First let’s set up the WPF Data Binding in XAML.

Defining the CollectionViewSource and Data Bindings

To recap, a CollectionViewSource is a proxy for the CollectionView which manages the currency (the position) in the list of entities. It has a property called Source which can be set in our code behind. This way, we can set up CollectionVieSources in XAML for all our data lists and bind them to the corresponding controls all in XAML. Then at runtime in our code we set the Source properties and only at that time does the data pull from the database.

To define a Master-Detail relationship we define two CollectionViewSources one for the master and one for the detail collections. Then on the detail we set the Source property to the master CollectionViewSource and then specify the Path property as the name of the child collection. In our case the name of the collection on Customer is “Orders”. So we can specify the XAML like so:

<Window.Resources>
    <CollectionViewSource x:Key="MasterViewSource" />
    <CollectionViewSource x:Key="DetailsViewSource" 
                    Source="{Binding Source={StaticResource MasterViewSource}, Path='Orders'}" />
</Window.Resources>

Now as the position changes in the MasterViewSource to point to a new Customer, the DetailsViewSource will filter automatically to only those related Orders for that Customer. We can now set the rest of the data bindings on the controls on the form by setting the BindingContext of the container controls to the CollectionViewSource we want to display. For example, we can set up a StackPanel to contain the Customer fields and set the StackPanel.DataContext to the MasterViewSource. Under that we can set up a ListView to display the Orders by setting the ListView.ItemsSource to the DetailsViewSource.

<Grid>
...
    <StackPanel Name="StackPanel2" 
                Grid.Column="1" 
                DataContext="{Binding Source={StaticResource MasterViewSource}}">
        <TextBox Name="TextBox1" IsReadOnly="True" 
                 Text="{Binding Path=CustomerID, Mode=OneWay}"/>
        <TextBox Name="TextBox5"
                 Text="{Binding Path=LastName}"/>
...
    </StackPanel>
...
    <ListView Grid.Row="3" Name="ListView1" 
              IsSynchronizedWithCurrentItem="True"
              ItemsSource="{Binding Source={StaticResource DetailsViewSource}}">
        <ListView.View>
            <GridView>
                <GridViewColumn Header="ID" Width="75">
                    <GridViewColumn.CellTemplate>
                        <DataTemplate>
                        <Label Content="{Binding Path=OrderID}" 
                                     Margin="-6,0,-6,0"/>
                        </DataTemplate>
                    </GridViewColumn.CellTemplate>
                </GridViewColumn>
                <GridViewColumn Header="Order Date" Width="100">
                    <GridViewColumn.CellTemplate>
                        <DataTemplate>
                            <TextBox Text="{Binding Path=OrderDate}" 
                                     Margin="-6,0,-6,0"/>
                        </DataTemplate>
                    </GridViewColumn.CellTemplate>
                </GridViewColumn>
...

The only thing we need to do now is set the Source property of the MasterViewSource in code to the collection of our Customer entities.

Defining the Master-Detail Entities in an ObservableCollection

I showed before how we can create a collection of entities that inherits from ObservableCollection in this post to make it easier to work with WPF data binding. But in that example we were only working with a simple collection of Customers and not their Orders. If you recall, the ObjectContext is what tracks changes on entities so in order for the ObjectContext to be notified that adds and deletes to the ObservableCollection need to be tracked you need to override the InsertItem and RemoveItem methods so that you can tell the ObjectContext to either add or delete the entity which will ultimately execute against the database. In the constructor I pass a reference to the ObjectContext. You can also pass in any collection of entities, say from a LINQ query, and then add them to the ObservableCollection. However, we need to make a couple modifications to our collection so that we can also track the child order entities correctly.

Adds to the Customer.Orders EntityCollection will will cause the addition of a new Order to the collection as well as the association to Customer automatically. However removing the Order from the Customer.Orders EntityCollection will only remove the association and will not attempt to actually delete the Order from the database. Instead it attempts to set the CustomerID to NULL (to remove the association from the Customer) but since we have referential integrity set up to disallow this we will get an error if we attempt to SaveChanges.

In a lot of scenarios it makes sense to just remove the association and set the foreign key to NULL in the database. But in this example we really mean to delete the Order record completely when the Order is removed from the collection. So the key is adding an event handler to the AssociationChanged event on the Orders EntityCollection that’s hanging off our Customer entity and telling the ObjectContext to explicitly delete the Order.

Public Class CustomerCollection
    Inherits ObservableCollection(Of Customer)

    Private _context As OMSEntities
    Public ReadOnly Property Context() As OMSEntities
        Get
            Return _context
        End Get
    End Property


    Sub New(ByVal customers As IEnumerable(Of Customer), ByVal context As OMSEntities)
        MyBase.New(customers)
        _context = context

        For Each c In customers
            AddHandler c.Orders.AssociationChanged, AddressOf Orders_CollectionChanged
        Next
    End Sub

    Protected Overrides Sub InsertItem(ByVal index As Integer, ByVal item As Customer)
        AddHandler item.Orders.AssociationChanged, AddressOf Orders_CollectionChanged

        'Tell the ObjectContext to start tracking this customer entity
        Me.Context.AddToCustomers(item)
        MyBase.InsertItem(index, item)
    End Sub

    Protected Overrides Sub RemoveItem(ByVal index As Integer)
        Dim customer = Me(index)
        RemoveHandler customer.Orders.AssociationChanged, AddressOf Orders_CollectionChanged

        For i = customer.Orders.Count - 1 To 0 Step -1
            'When deleting a customer, delete any orders if any exist
            Me.Context.DeleteObject(customer.Orders(i))
        Next

        'Tell the ObjectContext to delete this customer entity
        Me.Context.DeleteObject(customer)
        MyBase.RemoveItem(index)
    End Sub

    Private Sub Orders_CollectionChanged(ByVal sender As Object, _
                                         ByVal e As CollectionChangeEventArgs)
        If e.Action = CollectionChangeAction.Remove Then
            'Adding an order to a customer is handled automatically 
            ' for us but we need to tell the ObjectContext to delete the order
            ' if an order is removed from the Orders EntityCollection 
            Me.Context.DeleteObject(CType(e.Element, Order))
        End If
    End Sub
End Class

Loading the Master-Detail Entities

Finally we’re ready to write a LINQ query to load the entities into our CustomerCollection and then set that as the Source property of the MasterViewSource. In this example I’m loading the Orders explicitly by calling .Include(“Orders”) on the LINQ query which constructs a single statement to retrieve the Customer and all their Orders from the database. I discuss explicit load in this post.

We can then grab a reference to the MasterViewSource & DetailViewSource’s View property in order to add/remove items in the collections. When we’re done, we can call SaveChanges on the ObjectContext and the database will be updated.

Private db As New OMSEntities 'EF ObjectContext connects to database and tracks changes
Private CustomerData As CustomerCollection 'inherits from ObservableCollection

Private MasterViewSource As CollectionViewSource
Private DetailViewSource As CollectionViewSource

'provides currency to controls (position & movement in the collections)
Private WithEvents MasterView As ListCollectionView
Private DetailsView As BindingListCollectionView

Private Sub Window_Loaded() Handles MyBase.Loaded

    Dim query = From c In db.Customers.Include("Orders") _
                Where c.CustomerID = 1 _
                Select c

    Me.CustomerData = New CustomerCollection(query, db)

    Me.MasterViewSource = CType(Me.FindResource("MasterViewSource"), CollectionViewSource)
    Me.DetailViewSource = CType(Me.FindResource("DetailsViewSource"), CollectionViewSource)
    Me.MasterViewSource.Source = Me.CustomerData

    Me.MasterView = CType(Me.MasterViewSource.View, ListCollectionView)
    Me.DetailsView = CType(Me.DetailViewSource.View, BindingListCollectionView)
End Sub

Private Sub MasterView_CurrentChanged() Handles MasterView.CurrentChanged
    'We need to grab the new child view when the master's position changes
    Me.DetailsView = CType(Me.DetailViewSource.View, BindingListCollectionView)
End Sub

Private Sub btnSave_Click() Handles btnSave.Click
    Try
        db.SaveChanges()
        MessageBox.Show("Customer data saved.", Me.Title, MessageBoxButton.OK, MessageBoxImage.Information)
    Catch ex As Exception
        MsgBox(ex.ToString())
    End Try
End Sub

Private Sub btnDelete_Click() Handles btnDelete.Click
    If Me.MasterView.CurrentPosition > -1 Then
        Me.MasterView.RemoveAt(Me.MasterView.CurrentPosition)
    End If
End Sub

Private Sub btnAdd_Click() Handles btnAdd.Click
    Dim customer = CType(Me.MasterView.AddNew, Customer)
    Me.MasterView.CommitNew()
End Sub

Private Sub btnPrevious_Click() Handles btnPrevious.Click
    If Me.MasterView.CurrentPosition > 0 Then
        Me.MasterView.MoveCurrentToPrevious()
    End If
End Sub

Private Sub btnNext_Click() Handles btnNext.Click
    If Me.MasterView.CurrentPosition < Me.MasterView.Count - 1 Then
        Me.MasterView.MoveCurrentToNext()
    End If
End Sub

Private Sub btnAddDetail_Click() Handles btnAddDetail.Click
    Dim order = CType(Me.DetailsView.AddNew, Order)
    Me.DetailsView.CommitNew()
End Sub

Private Sub btnDeleteDetail_Click() Handles btnDeleteDetail.Click
    If Me.DetailsView.CurrentPosition > -1 Then
        Me.DetailsView.RemoveAt(Me.DetailsView.CurrentPosition)
    End If
End Sub

Now we can Add, Edit, and Delete Customer and their Orders at the same time and changes will be propagated properly to the database through Entity Framework in one call to SaveChanges. I’ve updated this complete sample application that demonstrates this as well as other aspects of WPF Data Binding with Entity Framework so have a look.

UPDATE: Milind talks about some of the tooling improvements in Visual Studio 2010 on the VSData blog regarding building WPF forms against Entity Data Models so check it out --> WPF Data Binding: Creating a Master-Details form in Visual Studio 2010

Enjoy!

WPF Data Binding Samples on Code Gallery

Beth Massi — Wed, 17 Jun 2009 22:41:28 GMT

One of the many samples released for Visual Studio 2010 Beta 1 that you should be aware of are examples of WPF data binding against Entity Data Models. You can find some easy to follow samples here: http://code.msdn.microsoft.com/WPFDatabinding

This sample demonstrates how to create a WPF Forms solution that checks user input with validation code, demonstrates common controls such as DataGrid and ComboBox, and shows typical data manipulation including create, read, update, and delete. The sample solution is available in both Visual Basic and C# and is intended for use with Visual Studio 2010 Beta 1 and with the .NET Framework 3.5. In the future, we will release a sample that performs with the .Net Framework 4.0 Beta.

Check out the VS Data Team blog for more information on WPF data-binding and Karl’s blog on a great WPF sample series.

Enjoy!

Visual Studio 2010 Beta 1 – Everyone can download and play today!

Beth Massi — Wed, 20 May 2009 20:50:00 GMT

Here it is folks, Visual Studio 2010 Beta 1 has been released to the public today. Check out the Visual Studio 2010 and .NET Framework 4 Beta 1 site to download the Beta, submit product feedback on the Beta 1 Forums, report bugs on Connect, and find additional information. Also visit the Beta 1 walkthroughs page for information on how to use the new features and download the Visual Studio 2010 Samples. There’s also some good language-focused resources on the Visual Basic 2010 and C# 2010 that are hanging off the Developer Centers.

Some of my favorite features include those around the WPF Designer and the Data Sources Window which now supports the same drag-drop RAD experience of Winforms in WPF applications:

For Office solutions, check out the Advanced Office Solution Deployment topic in the library and the VSTO Team blog for some cool new Office client features:

Take a look through the Visual Studio 2010 Product Highlights and What's New in Visual Studio 2010 for more info on other new features including multi-monitor – YUMMY! :-)

New Team Bloggers

I’d also like to introduce the “come-back” of the Visual Studio Data team blog. We’ve got a lot of new faces on the team that are building some amazing tools in Visual Studio to help you build business applications. They’ll be posting a lot of great VS 2010 content here.

Visual Studio 2010 Beta 1 resources:

My recommended blogs on VS 2010:

Enjoy!

Using TableAdapters to Insert Related Data into an MS Access Database

Beth Massi — Fri, 15 May 2009 03:48:00 GMT

I’ve posted before about how to use TableAdapters to update parent-child (master-detail) relationships against SQL server. It’s pretty straightforward and Visual Studio generates all the code for you to properly insert, update and delete your data. However if you’re using MS Access then there’s one thing that Visual Studio doesn’t do because it’s not supported when using Access.

How Parent-Child Inserts Work

When Visual Studio generates the insert commands on a SQL-Server TableAdapter it looks to see if the table’s primary keys are auto-generated (identity columns) and if so, Visual Studio will write an additional statement to retrieve the key using the SCOPE_IDENTITY functionality of SQL Server. When in the DataSet designer, if you look at the insert statement in the properties window for the SQLTableAdapter you will see two statements separated by a semi-colon:

INSERT INTO [dbo].[Products] ([ProductName], [SupplierID], [CategoryID], [QuantityPerUnit], [UnitPrice], [UnitsInStock], [UnitsOnOrder], [ReorderLevel], [Discontinued]) VALUES (@ProductName, @SupplierID, @CategoryID, @QuantityPerUnit, @UnitPrice, @UnitsInStock, @UnitsOnOrder, @ReorderLevel, @Discontinued);
SELECT ProductID, ProductName, SupplierID, CategoryID, QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, ReorderLevel, Discontinued FROM Products WHERE (ProductID = SCOPE_IDENTITY())

SQL Server supports batch statements through ADO.NET commands so this will populate the primary key back in the DataRow inside the DataSet as each row is inserted into the database. If you are enforcing foreign key constraints with a parent-child relation set up on two DataTables and you set the Update Rule to Cascade then any foreign key references will also be updated in the children. Because the TableAdapterManager will save the children after their parent records, when the child saves to the database it will contain the correct parent key which must already exist in the database before a child can be inserted in order to maintain referential integrity in the database.

Unfortunately Access doesn’t support batch statements. If you look at what is generated for Access you will only see one statement (also the OLEDB provider does not support named parameters hence the question mark placeholders):

INSERT INTO `Products` (`ProductName`, `SupplierID`, `CategoryID`, `QuantityPerUnit`, `UnitPrice`, `UnitsInStock`, `UnitsOnOrder`, `ReorderLevel`, `Discontinued`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)

So if you are doing inserts, especially for related parent-child data, you need a way to intercept the DataRow and set the primary key right after the row is inserted into the database and before any children are inserted. There’s an excellent article by Bill Vaughn (VB MVP) that explains this issue as well as a KB Article that shows how to solve it using the DataAdapter. These were written before Visual Studio had the concept of TableAdapters (which were added in VS 2008) so let’s see how we could use this technique to enhance our TableAdapters via partial classes.

Setting up the Parent-Child DataSet

The first step is to make sure you set up the tables in your Access database to use the AutoNumber feature for the primary keys on the rows. Here I’m using Access 2007 against the Northwind Access database. AutoNumber is used for both the primary keys on the Products and Categories tables:

Next you need to make sure you set up the relationship on the DataSet properly so that the primary key on the parent will cascade to the foreign key on the child. Set the relation in the DataSet designer to "Both Relation and Foreign Key Constraint" and then set the Update and Delete rules to Cascade. Just right-click on the relation and select "Edit Relation" in the DataSet designer:

Loading and Editing the Parent-Child DataSet

You now are telling the DataSet to enforce the foreign key relationship which means that you must have a parent for every child. This means you have to load the data in parent then child order. You also have to be careful with your queries. You have to make sure that every row in the child DataTable will have a corresponding parent row in the parent DataTable. This also means that you have to make sure to call EndEdit on any new parent BindingSource before any children can be added.

For example, from the Data Sources window drag the Categories parent table as details and the related child Products table as a DataGridView on the form and Visual Studio will generate the code to load and save our data.

Head over to the code behind and make sure that the parent is filled first before the child. Also make sure that EndEdit is called on the CategoriesBindingSource before a new product can be inserted into the DataGridView. EndEdit will flush the data row being edited by the controls into the DataTable. In this example I just am calling EndEdit on the CategoriesBindingSource when the user selects the grid.

Public Class Form1

    Private Sub CategoriesBindingNavigatorSaveItem_Click() _
            Handles CategoriesBindingNavigatorSaveItem.Click
        Me.Validate()
        'Call EndEdit on all BindingSources! 
        Me.CategoriesBindingSource.EndEdit()
        Me.ProductsBindingSource.EndEdit()
        Me.TableAdapterManager.UpdateAll(Me.ProductsDataSet)
    End Sub

    Private Sub Form1_Load() Handles MyBase.Load
        'Load parent before child!
        Me.CategoriesTableAdapter.Fill(Me.ProductsDataSet.Categories)
        Me.ProductsTableAdapter.Fill(Me.ProductsDataSet.Products)
    End Sub

    Private Sub ProductsDataGridView_Enter() Handles ProductsDataGridView.Enter
        'You must commit the parent row to the DataTable before adding child rows 
        Me.CategoriesBindingSource.EndEdit()
    End Sub

End Class

Note that anytime you call EndEdit and flush the data to the DataTable, the row must not fail any constraints either (i.e. if NULLs aren’t being allowed then you have to set those values). One way to handle this is to add code to set default values in the TableNewRow handler on the DataTable.

Enhancing the TableAdapter Partial Classes

Now for the good stuff. Like I mentioned in the beginning, you need a way to set the primary key on the parent right after the row is inserted into the database and before any children are inserted. Now that we have keys cascading we just need to write code to handle the RowUpdated event on the DataAdapter inside the TableAdapter partial class. TableAdapters are generated classes that Visual Studio creates for us from the DataSet designer. These classes are declared as Partial Classes so that means we can add code to the same class even if it’s in a separate file. Right-click on the TableAdapter class in the DataSet Designer and select View Code and the partial class file that you can edit will be created for you.

Namespace ProductsDataSetTableAdapters

    Partial Public Class CategoriesTableAdapter

    End Class

    Partial Public Class ProductsTableAdapter

    End Class
End Namespace

In these classes we can handle the RowUpdated event on the private variable _adapter which gives us access to the ADO.NET DataAdapter that is executing the updates to our rows. The way we retrieve the primary key is by executing the statement SELECT @@IDENTITY which tells Access to send back the last primary key it used on the connection. Because you have to add this handler to all your TableAdapters that are working against MS Access, to make things more manageable you can create a class with a Shared (static) method to handle setting the key and then call that from the handlers.

Imports System.Data.OleDb

Public Class AccessIDHelper
    ''' <summary>
    ''' Retrieves the primary key autonumber values from Access
    ''' </summary>
    ''' <remarks></remarks>
    Public Shared Sub SetPrimaryKey(ByVal trans As OleDbTransaction, _
                                    ByVal e As OleDbRowUpdatedEventArgs)
        If e.Status = UpdateStatus.Continue AndAlso _
           e.StatementType = StatementType.Insert Then
            ' If this is an INSERT operation...
            Dim pk = e.Row.Table.PrimaryKey
            ' and a primary key column exists...
            If pk IsNot Nothing AndAlso pk.Count = 1 Then
                Dim cmdGetIdentity As New OleDbCommand("SELECT @@IDENTITY", trans.Connection, trans)
                ' Execute the post-update query to fetch new @@Identity
                e.Row(pk(0)) = CInt(cmdGetIdentity.ExecuteScalar)
                e.Row.AcceptChanges()
            End If
        End If
    End Sub
End Class

Namespace ProductsDataSetTableAdapters

    Partial Public Class CategoriesTableAdapter

        Private Sub _adapter_RowUpdated(ByVal sender As Object, _
                                        ByVal e As System.Data.OleDb.OleDbRowUpdatedEventArgs) _
                                        Handles _adapter.RowUpdated

            AccessIDHelper.SetPrimaryKey(Me.Transaction, e)
        End Sub
    End Class

    Partial Public Class ProductsTableAdapter

        Private Sub _adapter_RowUpdated(ByVal sender As Object, _
                                        ByVal e As System.Data.OleDb.OleDbRowUpdatedEventArgs) _
                                        Handles _adapter.RowUpdated

            AccessIDHelper.SetPrimaryKey(Me.Transaction, e)
        End Sub
    End Class
End Namespace

So that’s how you can get the primary keys into the data rows and have them properly cascaded to the child rows. So now when the children are updated they will have the correct foreign key and the parent will exist in the database. I hope this helps clear up how to work with Access and Visual Studio.

I’ve posted this example on CodeGallery so have a look.

Enjoy!

Using the WPF ObservableCollection with EF Entities

Beth Massi — Sat, 09 May 2009 01:29:00 GMT

The ObservableCollection is a special WPF collection that provides proper notifications to the UI when items are added, removed, or the list is refreshed because it implements INotifyCollectionChanged. It’s common to use this collection (or inherit from it) to contain your business objects you want to bind to in WPF.

Class Window1
    Private CustomerData As ObservableCollection(Of Customer)

You can then set up a CollectionViewSource and use it’s View property to get a reference to the ListCollectionView in order to add and remove items instead of working with the source collection directly. This decouples your data source (and therefore any collection logic) from the form itself making it much easier to change sources later. I’ve showed how to use CollectionViewSources before but basically you just declare them in the Window.Resources section and bind to them in XAML:

<Window x:Class="Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="282" Width="440" Name="Window1">
    <Window.Resources>
        <CollectionViewSource x:Key="CustomerSource" />
    </Window.Resources>
    <Grid DataContext="{Binding Source={StaticResource CustomerSource}}">

And then you can set the Source property in code to your collection and obtain the ListCollectionView.

Dim customerSource = CType(Me.Resources("CustomerSource"), CollectionViewSource)
customerSource.Source = Me.CustomerData

Me.View = CType(customerSource.View, ListCollectionView)

Then you use the View to add and remove items from the collection and the UI will update properly:

Private Sub btnDelete_Click() Handles btnDelete.Click
       If Me.View.CurrentPosition > -1 Then
           'removes the currently selected customer from the underlying collection 
           Me.View.RemoveAt(Me.View.CurrentPosition)
       End If
   End Sub

   Private Sub btnAdd_Click() Handles btnAdd.Click
       'adds a new customer to the underlying collection 
       Dim customer = CType(Me.View.AddNew, Customer)
       'do something with customer if needed...
       Me.View.CommitNew()
   End Sub

Calling these methods on the ListCollectionView will execute the InsertItem and RemoveItem methods on the ObservableCollection.

Now if you are using an Entity Data Model (EDM) the designer in Visual Studio 2008 SP1 will generate entity classes for you that you can also bind to in your UI. Access to these entities is done through the ObjectContext and the designer also creates a class for you that inherits from this when you create the EDM. It is named something like xxxEntites. (For instance, in Visual Studio 2008 SP1 “Add New Item” and select ADO.NET Entity Data Model and name it Northwind.edmx. Generate from Database and select Northwind. Select all the tables and then the designer will generate an ObjectContext called NorthwindEntities and entity classes based on the tables in the database.)

Because the ObjectContext is what tracks changes on entities you can place entities inside an ObservableCollection but in order for the ObjectContext to be notified that adds and deletes need to be tracked you need to write a bit of code. The easiest thing to do is to create your own class that inherits from ObservableCollection and override the InsertItem and RemoveItem methods so that you can tell the ObjectContext to either add or delete the entity which will ultimately execute against the database. In the constructor pass a reference to the ObjectContext. You can also pass in any collection of entities, say from a LINQ query, and then add them to the ObservableCollection. For example:

Imports NorthwindDAL
Imports System.Collections.ObjectModel

Public Class CustomerCollection
    Inherits ObservableCollection(Of Customer)

    Private _context As NorthwindEntities
    Public ReadOnly Property Context() As NorthwindEntities
        Get
            Return _context
        End Get
    End Property

    Sub New(ByVal customers As IEnumerable(Of Customer), ByVal context As NorthwindEntities)
        MyBase.New(customers)
        _context = context
    End Sub

    Protected Overrides Sub InsertItem(ByVal index As Integer, ByVal item As Customer)
        Me.Context.AddToCustomers(item)
        MyBase.InsertItem(index, item)
    End Sub

    Protected Overrides Sub RemoveItem(ByVal index As Integer)
        Me.Context.DeleteObject(Me(index))
        MyBase.RemoveItem(index)
    End Sub

End Class

Then you can use the collection on your WPF form instead like so:

Imports NorthwindDAL

Class Window1
    Private db As New NorthwindEntities
    Private CustomerData As CustomerCollection
    Private View As ListCollectionView

    Private Sub Window1_Loaded() Handles MyBase.Loaded

        Dim results = From c In db.Customers _
                      Where c.City.ToLower = "seattle" _
                      Order By c.LastName, c.FirstName _
                      Select c

        Me.CustomerData = New CustomerCollection(results, db)

        Dim customerSource = CType(Me.Resources("CustomerSource"), CollectionViewSource)
        customerSource.Source = Me.CustomerData
        Me.View = CType(customerSource.View, ListCollectionView)
    End Sub

    Private Sub btnSave_Click() Handles btnSave.Click
        Try
            db.SaveChanges()
            MsgBox("Customer data was saved.")
        Catch ex As Exception
            MsgBox(ex.ToString())
        End Try
    End Sub

    Private Sub btnDelete_Click() Handles btnDelete.Click
        If Me.View.CurrentPosition > -1 Then
            Me.View.RemoveAt(Me.View.CurrentPosition)
        End If
    End Sub

    Private Sub btnAdd_Click() Handles btnAdd.Click
        Dim customer = CType(Me.View.AddNew, Customer)
        'do something with customer if needed...
        Me.View.CommitNew()
    End Sub

End Class

Now any updates, adds or deletes you make in the UI will be propagated to the database through the Entity Framework.

Enjoy!

Notifying the UI when Entity References Change in Lookup Comboboxes

Beth Massi — Tue, 05 May 2009 05:51:20 GMT

Last week I wrote about how to data bind WPF lookup comboboxes to entities returned from the Entity Framework. I described that the key to this type of binding is setting the SelectedItem to the object reference itself on the navigation property instead of setting SelectedValue and SelectedValuePath as in the case when you have foreign key scalar properties like LINQ to SQL classes or DataTables.

However, depending on your UI, you may need a notification to fire when the entity reference changes. By default this doesn’t happen with entities generated by the EF designer. Only scalar properties raise change notifications. For instance, going back to our Customer (1)—(*) Order example, the Order entity has a reference to its Customer parent as specified by the navigation property:

In the database there is a foreign key relationship on CustomerID and that is inferred here by EF. If you look at the Order class that is generated you will see only change notifications raised on the scalar properties, not the navigation properties. For instance, if we take a look at a scalar property that is generated you will see the change notification partial methods generated as well:

Partial Public Class Order
    Inherits Global.System.Data.Objects.DataClasses.EntityObject
.
.
.
    Public Property OrderID() As Integer
        Get
            Return Me._OrderID
        End Get
        Set
            Me.OnOrderIDChanging(value)
            Me.ReportPropertyChanging("OrderID")
            Me._OrderID = StructuralObject.SetValidValue(value)
            Me.ReportPropertyChanged("OrderID")
            Me.OnOrderIDChanged
        End Set
    End Property
    Private _OrderID As Integer
    
    Partial Private Sub OnOrderIDChanging(ByVal value As Integer)
    End Sub
    
    Partial Private Sub OnOrderIDChanged()
    End Sub

.
.
.

EF entities that are generated by the designer inherit from EntityObject that in turn inherits from StructuralObject that implements INotifyPropertyChanged. This interface is necessary for notifying the UI (WPF and Winforms) that data bound controls should refresh their value. So say you programmatically change a scalar property then any controls bound to that property will be refreshed with the new value automatically. Or in many cases you have a UI with multiple controls bound to the same property. If the user makes a change to one control, the rest update automatically.

However this notification isn’t generated on entity references. Which means that if you have a lookup combobox set up like I described in last week’s post and also have another control bound to the same Customer navigation property, then it won’t refresh properly.

For instance, say we have an Order form with a combobox set up like before, where the SelectedItem is bound to the Customer property (SelectedItem="{Binding Path=Customer}"), but we also have a listbox that shows OrderDate, Customer.LastName, Customer.FirstName:

<ListBox Grid.Row="1" Name="ListBox1" ItemsSource="{Binding}" IsSynchronizedWithCurrentItem="True">
<ItemsControl.ItemTemplate>
    <DataTemplate>
        <StackPanel Orientation="Horizontal">
            <TextBlock Width="60" Text="{Binding Path=OrderDate, StringFormat='d'}" />
            <TextBlock Text="{Binding Path=Customer.LastName}" />
            <TextBlock Width="5">, </TextBlock>
            <TextBlock Text="{Binding Path=Customer.FirstName}" />
        </StackPanel>
    </DataTemplate>
</ItemsControl.ItemTemplate>

If the user changes the OrderDate then that change will automatically be reflected in the listbox. But if the user changes the Customer in the dropdown combobox then it will NOT update the listbox because a change notification is not raised on Customer. What’s also interesting is if you look at that part of the generated Order entity then you will actually see two properties, one we expect called Customer and one called CustomerReference:

.
.
.
Public Property Customer() As Customer
    Get
        Return CType(Me, IEntityWithRelationships).RelationshipManager. _
        GetRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer").Value
    End Get
    Set(ByVal value As Customer)
        CType(Me, IEntityWithRelationships).RelationshipManager. _
        GetRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer").Value = value
    End Set
End Property
.
.
.
Public Property CustomerReference() As EntityReference(Of Customer)
    Get
        Return CType(Me, IEntityWithRelationships).RelationshipManager. _
        GetRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer")
    End Get
    Set(ByVal value As EntityReference(Of Customer))
        If (Not (value) Is Nothing) Then
            CType(Me, IEntityWithRelationships).RelationshipManager. _
            InitializeRelatedReference(Of Customer)("OMSModel.FK_Orders_Customer", "Customer", value)
        End If
    End Set
End Property

The Customer property is a navigation property to the parent Customer entity itself as we expect. The CustomerReference is an EntityReference class. This class describes the relationship between the Order and Customer. It also defines an event called AssociationChanged that you can handle to notify the UI properly when the reference changes. When you change the reference this event will fire twice, first to remove the old reference and then again to add the new one. You can easily extend the Order partial class by creating another Partial Class declaration for Order in the same namespace (which is automatically imported in VB) and then calling the appropriate property change notifications:

Imports System.ComponentModel

Partial Public Class Order
    Sub New()
        MyBase.New()
        AddHandler Me.CustomerReference.AssociationChanged, AddressOf Customer_AssociationChanged
    End Sub

    Private Sub Customer_AssociationChanged(ByVal sender As Object, _
                                            ByVal e As CollectionChangeEventArgs)
        If e.Action = CollectionChangeAction.Remove Then
            OnPropertyChanging("Customer")
        Else
            OnPropertyChanged("Customer")
        End If
    End Sub
End Class

So now we can change the Customer in the dropdown and the UI will be notified properly. Sweet. For more information on Entity Framework and data binding see this topic in the MSDN library.

Enjoy!

Data Binding WPF Lookup Combobox Values to EF Entities

Beth Massi — Thu, 30 Apr 2009 17:57:00 GMT

It’s extremely common to have to hook up lookup tables on your data entry forms in order to populate foreign keys in a database. I’ve talked about how to do this in Winforms and WPF with Datasets and LINQ to SQL before:

The common theme between all of these is that the data sources, either the LINQ to SQL classes or the DataTables that we bind to, uses a navigation path based on the foreign key and that foreign key is exposed as a property (or DataColumn). For instance if we have a Customer related to Orders we would have a CustomerID property on Orders.

DataSets (like databases) rely on this type of navigation. So when you want to find the parent Customer of an Order you have to know the relation. Using typed datasets helps you more but you still end up having to know the details of relationships and foreign keys of the DataSet. That’s why people who are familiar with databases are usually comfortable with working with DataSets.

LINQ to SQL classes also include navigation properties as direct object references and collections. So they have both the foreign key and the navigation properties. Customer will have a collection of Orders and Order will have a reference back to Customer but the classes also contain the CustomerID property. This isn’t “pure” I suppose but it does make data binding and subsequent saves back to the database pretty much a no brainer.

For instance say I want to hook up a lookup combobox using a LINQ to SQL class on an Order with a reference to Customer. I want to display a list of Customers the user can pick from and that Customer should be associated with that Order. It’s pretty straight forward and works the same with DataTables.

XAML:

<Window.Resources>
    <CollectionViewSource x:Key="OrdersSource" />
    <CollectionViewSource x:Key="CustomerLookup" />
</Window.Resources>

<Grid Grid.Row="1" Name="Grid1" DataContext="{Binding Source={StaticResource OrdersSource}}">
<ComboBox Height="23" Name="ComboBox1" Width="177" Margin="2"  HorizontalAlignment="Left" 
          IsEditable="False"
          ItemsSource="{Binding Source={StaticResource CustomerLookup}}"
          DisplayMemberPath="LastName"
          SelectedValuePath="CustomerID" 




          SelectedValue="{Binding Path=CustomerID}" 
          />
...

Code-behind:

Class Window1
    Private db As New MyDataObjectContext
    Private OrderData As IEnumerable(Of Order)

    Private Sub Window1_Loaded(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles Me.Loaded
        'Load all the orders from the database
        Me.OrderData = db.Orders
        'Get the customer lookup list (this is the Combobox ItemsSource)
        Dim customerList = From c In db.Customers _
                           Where c.Orders.Count > 0 _
                           Order By c.LastName, c.FirstName

        Dim ordersSource = CType(Me.FindResource("OrdersSource"), CollectionViewSource)
        ordersSource.Source = Me.OrderData
        Dim custSource = CType(Me.FindResource("CustomerLookup"), CollectionViewSource)
        custSource.Source = customerList.ToList()

    End Sub
...

Almost all of this code is just to set up the context of this discussion, you can watch this video for details on building a complete example. Here I’m using CollectionViewSources in the XAML and setting their Source property in code. This technique is handy especially if you are using nested DataTemplates. The important piece to note are the four properties on the Combobox. ItemsSource, DisplayMemberPath, SelectedValue, and SelectedValuePath. To set up your combobox:

Set the ItemsSource to the list of Customers you want to display in the Combobox.
Next set the DisplayMemberPath to the property name on this list that you want to use to display in the list, here I used LastName.
Then set the SelectedValuePath to the property name on this list that will be used to populate the foreign key value on the Order.
Finally you set the SelectedValue to the property binding on the Order that is foreign key. LINQ to SQL (and DataSets) will happily save your data with this binding in place.

This is how you always bind DataTables and it also works well for LINQ to SQL classes. But since LINQ to SQL classes also include the navigation properties (the Orders collection on Customer and the Customer object reference on Order) you can use a different technique by binding directly to the Customer reference. This is the only choice we have with Entity Framework entities in .NET 3.5 SP1.

What’s unique with Entity Framework is that the associations between other entities use only navigation properties -- so there isn’t a CustomerID foreign key property value on the Order at all.

What you have to do instead is bind directly to the Customer object reference. The change in the above example is the Combobox binding in XAML:

<ComboBox Height="23" Name="ComboBox1" Width="177" Margin="2"  HorizontalAlignment="Left" 
          IsEditable="False"
          ItemsSource="{Binding Source={StaticResource CustomerLookup}}"
          DisplayMemberPath="LastName"          
          SelectedItem="{Binding Path=Customer}" 
          />

The important pieces in this case are the three properties on the Combobox. ItemsSource, DisplayMemberPath, and SelectedItem.

Set the ItemsSource to the list of Customers you want to display in the Combobox -- same as before.
Next set the DisplayMemberPath to the property name on this list that you want to use to display in the list, here I used LastName – same as before.
Now set the SelectedItem to the property binding on the Order that is the navigation property to Customer.

This will work properly with LINQ to SQL classes and Entity Framework entities but there is one caveat. You need to make sure that you pull the entire Customer entity into in the lookup list from the same ObjectContext you used to query the Orders. This is because the same ObjectContext (DataContext in LINQ to SQL) needs to resolve the entity references between the queries. Entity Framework does this based on the EntityKeys. The neat side effect of this with EF is that you don’t have to pull down the Customers with the Orders query, they will automatically become references when the Customer lookup list is queried through the same context. (See my post on explicit load for more details on how to bring down related EF entities when you only make one call.)

This behavior may be desired in a lot of scenarios but if we do not need to modify the Customer, like in our example, this can be overkill especially if the Customer has a lot of large fields you aren’t using. In the first example we could have only pulled a subset of fields from the Customer table – the only required ones would be the ones used in the data binding, CustomerID and LastName. So with DataTables and LINQ to SQL classes that bind on the values we could have optimized our lookup list query to:

Dim customerList = From c In db.Customers _
                   Where c.Orders.Count > 0 _
                   Order By c.LastName, c.FirstName _
                   Select c.CustomerID, c.LastName

This will not work if we bind directly to the navigation properties because the customerList is now a list of anonymous types and not a list of Customer entities. So binding to the values gives you greater flexibility with your lookup list queries. Unfortunately in the current version of EF you cannot bind this way but they are planning to enable this in the next version. In .NET 4.0 the EF team will add support for a new type of association called "FK Associations". Read more about that here.

And I’m working on the next set of WPF Forms over Data How Do I videos, this time with Entity Framework, that will hopefully explain how to use EF in practical way by building WPF data applications. Stay tuned!

Enjoy!

Tally Rows in a DataSet that Match a Condition

Beth Massi — Tue, 28 Apr 2009 05:24:21 GMT

Today I got a question that comes up often in data application programming about how to count rows in a DataSet that matched a condition. The DataSet may be bound to a DataGridView or other list control and it’s tempting to start looking at the control to see if you can coax it into returning what you need but usually there is a much better way.

For instance, say we have a table in our database called “Inbox” that has varchar fields Subject, From, and Status and we’d like to tally all the rows where the Status = “Unread”. Suppose we’ve also created a typed DataSet that contains this Inbox table. You create a data-bound Windows Form with a DataGridView on it by dragging the table from the Data sources window onto the form (like I showed in this video). When you do this, Visual Studio generates code that hooks up your DataGridView’s DataSource property to a BindingSource object which in turn has it’s DataSource set to your DataSet. This is a good thing. The BindingSource is a simple controller that provides currency between your DataSet and the DataGidView UI. (In WPF this is similar to the CollectionView object). You write code against the BindingSource instead so that it doesn’t matter what kind of control is being used to display the data.

BindingSource to the Rescue

The BindingSource in this case is actually working with a DataView, not the actual DataTable, which may seem confusing. This is needed for related data binding to work (see this video and this one). Since the BindingSource manages the currency (current row position) that is being displayed by the controls, in this example the BindingSource.List will return the DataView and the BindingSource.Current property will always return the DataRowView. You access your typed DataRow by casting the DataRowView.Row property. So to get a count of items in the DataView we could just simply ask the BindingSource for a count of it’s rows no matter what kind of control is being used for the display:

Dim count = Me.InboxBindingSource.Count

Or we could grab the DataView and ask for its count:

Dim dv = CType(Me.InboxBindingSource.List, DataView)
Dim count = dv.Count

Once you have the DataView you can apply more filtering on it directly or we can loop through it to tally the rows where Status = “Unread”.

Dim dv = CType(Me.InboxBindingSource.List, DataView)
Dim count = 0
For Each drv As DataRowView In dv
    Dim inboxRow = CType(drv.Row, EmailDataSet.InboxRow)
    If inboxRow.Status = "Unread" Then
        count += 1
    End If
Next

But the neat thing about using the BindingSource is that you always know the current row being displayed. So if we want to tally the rows based on a condition in the current row we go through the BindingSource. You can easily write the code that gets the current row as your typed data row by using a code snippet. Right-click in the editor, select Data – LINQ, XML, Designer, ADO.NET > Designer Features and ADO.NET > Converts BindingSource.Current to a specific row in a DataTable:

This code returns a tally of rows in the current view that have the same status as the selected row. Instead of looping through the data manually with For Each, this code sets the Filter property of the DataView instead:

Dim currentRow As EmailDataSet.InboxRow
currentRow = CType(CType(Me.InboxBindingSource.Current, DataRowView).Row, EmailDataSet.InboxRow)

Dim dv = CType(Me.InboxBindingSource.List, DataView)
dv.RowFilter = "Status ='" & currentRow.Status & "'"
Dim count = dv.Count

This technique causes any bound controls to update to the new filter. To remove the filter, set the Filter property to Nothing or the empty string. Although this code may work for a lot of scenarios, we may have a situation where we do not want to affect any of the bound controls by changing the filter. And even though this is a simple condition it would be nice not to have to manually write the loop ourselves. This is a perfect place to use LINQ instead.

LINQ to the Rescue

If we want to tally the entire DataTable for rows matching a condition we can use LINQ to DataSets with Visual Basic’s Aggregate clause. This doesn’t involve a BindingSource at all but be aware that the DataView that a BindingSource may be displaying data from may be filtered. In the case of this example the DataView contains the same rows as the DataTable (no filter) so we can write a simple Aggregate query to count the rows:

Dim count As Integer = Aggregate row In Me.EmailDataSet.Inbox _
                       Where row.Status = "Unread" _
                       Into UnreadCount = Count()

This will return an integer indicating the number of rows in the entire DataTable that matched the Where clause. But what if we do want to use the BindingSource and take into account any filters that are being applied to the DataView in which controls are bound? In this case we can still use an Aggregate LINQ query it will just be against the DataView so we will need to cast a few things:

Dim dv = CType(Me.InboxBindingSource.List, DataView)
Dim count As Integer = Aggregate row In dv.Cast(Of DataRowView).AsQueryable _
                       Where CType(row.Row, EmailDataSet.InboxRow).Status = "Unread" _
                       Into UnreadCount = Count()

Now what would be really nice is to automatically tally this information from the DataSet and display it in a label on the Form anytime the user made any changes to the rows. We can do this easily by handling the BindingSource’s ListChanged event and putting our Aggregate LINQ query in there:

Private Sub InboxBindingSource_ListChanged() Handles InboxBindingSource.ListChanged
    Dim count As Integer = Aggregate row In Me.EmailDataSet.Inbox _
                           Where row.Status = "Unread" _
                           Into UnreadCount = Count()

    Me.lblStatus.Text = count.ToString() & " unread email."
End Sub

Now this will give us a “live” running tally and we’re not bound to the UI controls at all. Nice. For more information on Aggregate queries and DataSets check out this video.

More resources:

Enjoy!

Channel 9 Interview: WPF Improvements in VS2010 for Business Apps

Beth Massi — Tue, 24 Mar 2009 19:01:08 GMT

I just posted an interview on Channel 9 on WPF Improvements in Visual Studio 2010 for Building Business Apps.

At the MVP Summit a few weeks ago, Italian MVP Alessandro del Sole was so excited about the new WPF features in Visual Studio 2010 that he asked me if he could interview Milind Lele himself to get the low-down -- I said sure!

Milind is a Program Manager on the Visual Studio Pro Tools team. In this interview he chats with Alessandro about the new WPF improvements in Visual Studio 2010 for building business applications. This time Milind shows off the new Visual Studio UI and the new WPF data grid as he quickly builds a master-details form against an Entity Data Model using the new RAD drag-drop data binding features for WPF.

Also check out Milind's blog post on this topic for more information.

Enjoy!