Visual Studio Data : Typed Dataset

WPF Data Binding: How to Bind DataSet to WPF Designer

Yaohai — Fri, 13 Nov 2009 05:58:00 GMT

WPF Data Binding: How to Bind DataSet to WPF Designer

In our previous posts, we mostly used the Entity Data Model as the ORM (Object-relational mapping) layer for the WPF Data Binding scenarios.

Meanwhile, since DataSet is used broadly, we also provide the DataSet as a supported DataSource in the Data Binding stories. Following is a step-by-step example using C#. The example is based on Visual Studio 2010 Beta2 version.

Bind DataSet to WPF designer:

1. Open Visual Studio. From the main menu: File->New Project, choose WPF Application to create a new C# application. Here, we assume the project name to the default one: WpfApplication1.

2. From the main menu: Data->Add New Data Source…->DataBase->Dataset to trigger Data Source Wizard.

3. Follow the Wizard to connect to a Northwind SQL Server database, and choose tables: Customers, Orders. Following is what the Dataset designer looks like after this step finished:

4. From the main menu: Data->Show Data Sources to show the Data Sources Tool Window, and make sure that MainWindow.xaml is the active window:

5. Switch back to DataSources Tool Window, you can click on Customers node and click the drop-down menu. On the context menu, choose “Customize…” to popup the “Customize Control Binding” dialog. Select the ComboBox for the [List] Data type:

6. Bind the Customers to the “Combobox” control. After above steps, following is the snapshot before the drag&drop operation. From its icon, you can see the Customers is bound to Combobox now.

7. Drag&drop the Customers table to the top-left corner. Then, drag&drop the Customers.Orders to the center of the WPF designer. To layout the controls as follow:

With these steps, a simple DataSet Master-Details application is created. Press “Ctrl + F5” to run the application and see the data.

Behind the Scenes:

In step 5, there are two parts of code generated: One is the xaml markup code and the other is the C# code behind. The generated code is for demonstration purpose. Here, I will explain their corresponding meanings to provide guideline for modifying the code.

Regarding the xaml code, besides the markups for the controls/data-binding, which are the same when using the EDM as the ORM layer, it also generates resources section for the Window:

<Window.Resources>

<my:NorthwindDataSet x:Key="NorthwindDataSet" />

</Window.Resources>

The first line defines an object resource of the NorthwindDataSet instance, which is specific to DataSet. So when a Window is initialized, there will be a DataSet instance created. The 2^nd and 3^rd lines of code are doing master-details data-binding leveraging CollectionViewSource.

The generated C# code behind is:

private void Window_Loaded(object sender, RoutedEventArgs e)

{

WpfApplication1.NorthwindDataSet NorthwindDataSet = ((WpfApplication1.NorthwindDataSet)(this.FindResource("NorthwindDataSet")));

// Load data into the table Customers. You can modify this code as needed.

WpfApplication1.NorthwindDataSetTableAdapters.CustomersTableAdapter northwindDataSetCustomersTableAdapter = new WpfApplication1.NorthwindDataSetTableAdapters.CustomersTableAdapter();

northwindDataSetCustomersTableAdapter.Fill(NorthwindDataSet.Customers);

System.Windows.Data.CollectionViewSource customersViewSource = ((System.Windows.Data.CollectionViewSource)(this.FindResource("customersViewSource")));

customersViewSource.View.MoveCurrentToFirst();

// Load data into the table Orders. You can modify this code as needed.

WpfApplication1.NorthwindDataSetTableAdapters.OrdersTableAdapter northwindDataSetOrdersTableAdapter = new WpfApplication1.NorthwindDataSetTableAdapters.OrdersTableAdapter();

northwindDataSetOrdersTableAdapter.Fill(NorthwindDataSet.Orders);

System.Windows.Data.CollectionViewSource customersOrdersViewSource = ((System.Windows.Data.CollectionViewSource)(this.FindResource("customersOrdersViewSource")));

customersOrdersViewSource.View.MoveCurrentToFirst();

}

Again, the 1^st line is getting the DataSet object instance from the WPF designer resource dictionary. The 2^nd line is loading the Customers data into the table. You can replace it with other DataSet object instance as you prefer. The 3^rd and 4^th lines are initializing the CollectionViewSource. The lines 5~7, which are for the table Customers.Orders, are similar to lines 2~4.

You may notice that the data is loaded when the application starts. If you prefer to load it on demand, you can move this code to some other event handler such as a button click or something like that.

Hope this helps.

Refresh the Primary Key Identity Column during Insert Operation

John Chen — Tue, 15 Sep 2009 08:17:46 GMT

If you have an identity primary key column defined in a database table, its value will be automatically set by the database engine when you insert a new row to the table. The identity value is determined by the column’s Identity Seed and Identity Increment properties.

While in your client application, you can insert a new row into a corresponding ADO.NET DataTable (DataTable can be seen as the in memory cache of the data table in the database, I will use DataTable as the example in this post). You will not get the true value until you commit the update to the database. What you see before the update is not what you get after the update. For better user experience, you really want to refresh the database to retrieve the correct identity value back right after the insert operation.

In this post, I will describe the way to retrieve the identity value in ADO.NET applications with the help of Visual Studio Database Tools. I will start with a sample Windows Forms application using DataSet. My database server is SQL Server.

First in Visual Studio (2005 and after) server explorer, I establish a data connection connects to a SQL Server database. I create a data table in the database called MyCustomer with three columns: CustId, Name and Company. CustId is defined as primary key and an identity column. Identity Seed and Identity Increment are set as 1 by default as shown in Figure 1 below.

Figure 1 MyCustomer table defined in database

Then I create my DataSet through the Data Source Configuration Wizard, or by adding a DataSet and then dragging and dropping MyCustomer from Server Explorer to the DataSet Designer. By opening the DataSet and selecting the CustId column, you will see that it has the following properties: AutoIncrement=True, and AutoIncrementSeed = -1 , AutoIncrementStep = -1 (Figure 2). These properties are used by ADO.NET to auto generate the CustId’s placeholder values for newly added rows.

Figure 2. CustId properties in the DataTable

The AutoIncrement property corresponds to the Identity property in the database. AutoIncrementSeed corresponds to Identity Seed, and AutoIncrementStep to Identity Increment. You may be curious why both AutoIncrementSeed and AutoIncrementStep are set to -1. This is an approach to ensure that the placeholder values that ADO.NET generates will not conflict with values that already exist in the database. Another benefit is it looks like unreal so users will know that it is just a temporary placeholder value.

Now if you click on the MyCustomerTableAdapter header and show its CommandText for Insert Command, you will see this:

INSERT INTO [MyCustomer] ([Name], [Company]) VALUES (@Name, @Company);

SELECT CustId, Name, Company FROM MyCustomer WHERE (CustId = SCOPE_IDENTITY())

The command text contains two statements and the second one is used to retrieve the primary key value after the insert operation is committed. Notice the use of the SCOPE_IDENTITY function, which is defined so in MSDN:

“SCOPE_IDENTITY (Transact-SQL) Returns the last identity value inserted into an identity column in the same scope. A scope is a module: a stored procedure, trigger, function, or batch. Therefore, two statements are in the same scope if they are in the same stored procedure, function, or batch”

The auto generation of the second statement in Insert command is controlled by the “refresh data table option” in the TableAdapter Configuration Wizard (Figure 3).

Figure 3. Refresh the data table advanced option in the TableAdapter Configuration Wizard

Now let’s take a look what is the experience when applying this refresh data table feature at run time. Let me open the Form and then show the Data Sources Window. From the Data Sources Window, I drag and drop the MyCustomer table to the Form and I get the following layout (Figure 4):

Figure 4. At design time: Drag and Drop MyCustomer from the Data Sources window to the form

Hit F5 to run the app. Click on the Add New (the + sign) button to add some rows. Notice that I will get values of -1, -2, -3, etc. for CustId column.

Figure 5. CustForm at run time, before committing

Now I click the Save (the disk sign) button and I see that the CustIds are updated to 9,10,11. Oh! I would expect to get 2,3,4; someone may beat me and add some rows before me. You see that using -1,-2,-3 really make sense here to clearly indicate that the values are not committed.

Figure 6. CustForm at run time, after committing

Now if you are using MS Access database or SQL CE, you will see that the above walk through does not work as expected. When you click the save, the primary key -1,-2,-3 keep unchanged. If you check on the TableAdapter Configuration Wizard, the Refresh the data table option is disabled. If you check the generated insert command, there is only one statement. This is because MS Access database and SQL CE do not support batching SQL statements and therefore cannot use the SCOPE_IDENTITY function. The build-in refresh the data table option is not available for these databases.

The good news is there is a sound workaround to fix this by reset the primary key identity value on Adapter.RowUpdated event. Please see Beth Massi’s blog: Using TableAdapters to Insert Related Data into an MS Access Database. Beth promised to write a follow up post for SQL CE as well. J

In summary, SQL server or any database supporting batching operation has a reliable way to retrieve the identity value through the usage of the SCOPE_IDENTITY function. Visual Studio Data Tool provides the auto generated Insert command that leverages this support with the “Refresh the data table” option turn on by default. For databases that do not support batching of SQL statements, resetting the primary key value on row updated event is a good workaround.

How to Workaround Sorting Errors when Updating Self-Referencing DataSet Tables with Visual Studio 2008 SP1

Gavin Fu — Sat, 05 Sep 2009 07:14:00 GMT

Hierarchical update is an important feature of typed dataset that refers to the process of saving updated data back to a database while maintaining referential integrity rules. This feature is enhanced in Visual Studio 2008 by introducing a TableAdapterManger component to manage all TableApdaters in a typed dataset. When updating related tables, TableAdapterManager uses foreign-key relationships to determine the correct order to send Insert, Update, and Delete commands from a dataset to the database without violating the foreign-key constraints (referential integrity) in the database.

TableAdpaterManager is automatically generated when you create a typed-dataset in a project with Hierarchical Update enabled (For more information, see How to Enable and Disable Hierarchical Update), and it could greatly reduce the code to save data to multiple related tables. Users just need to call TableAdpaterManager.UpdateAll(DataSet). You could see how easy it is to use this class in “Sample Code Snippet to Update the Database” section of this article. However, when updating self-referencing tables, TableAdpaterManager has some defects in determining the correct order of affected rows, which could cause constraint violation errors when committing the changes to database. We have noticed this problem and are investigating how to resolve it. I’ll explain the idea of the solution and how to work around this issue with Visual Studio 2008 SP1.

What the Problem is

Sample Table

Suppose that you have a self-referencing table named Temp with three columns and a foreign-key relationship.

Table Definition:

Foreign-Key Relation:

Generated Typed-DataSet Code Snippet

Suppose you add a typed-dataset (say, dataset1) to your application, and drag-drop the Temp table from Server Explorer to the dataset designer, Visual Studio will generate code of the typed-dataset for you. Below is the code snippet that is related to this topic.

[C#]

public partial class TableAdapterManager : global::System.ComponentModel.Component {

public virtual int UpdateAll(DataSet1 dataSet) {

. . . . . .

this.UpdateInsertedRows(dataSet, allAddedRows));

. . . . . .

this.UpdateDeletedRows(dataSet, allChangedRows));

. . . . . .

}

private int UpdateInsertedRows(DataSet1 dataSet, global::System.Collections.Generic.List<global::System.Data.DataRow> allAddedRows) {

. . . . . .

this.SortSelfReferenceRows(addedRows, dataSet.Relations["FK_Temp_Temp"], false);

. . . . . .

}

private int UpdateDeletedRows(DataSet1 dataSet, global::System.Collections.Generic.List<global::System.Data.DataRow> allChangedRows) {

. . . . . .

this.SortSelfReferenceRows(addedRows, dataSet.Relations["FK_Temp_Temp"], true);

. . . . . .

}

protected virtual void SortSelfReferenceRows(global::System.Data.DataRow[] rows, global::System.Data.DataRelation relation, bool childFirst) {

global::System.Array.Sort<global::System.Data.DataRow>(rows, new SelfReferenceComparer(relation, childFirst));

}

private class SelfReferenceComparer : object, global::System.Collections.Generic.IComparer<global::System.Data.DataRow> {

private global::System.Data.DataRelation _relation;

private int _childFirst;

. . . . . .

public int Compare(global::System.Data.DataRow row1, global::System.Data.DataRow row2) {

if (object.ReferenceEquals(row1, row2)) {

return 0;

}

if ((row1 == null)) {

return -1;

}

if ((row2 == null)) {

return 1;

}

// Is row1 the child or grandchild of row2

if (this.IsChildAndParent(row1, row2)) {

return this._childFirst;

}

// Is row2 the child or grandchild of row1

if (this.IsChildAndParent(row2, row1)) {

return (-1 * this._childFirst);

}

return 0;

}

[VB]

Partial Public Class TableAdapterManager

Inherits Global.System.ComponentModel.Component

Public Overridable Function UpdateAll(ByVal dataSet As DataSet1) As Integer

. . . . . .

Me.UpdateInsertedRows(dataSet, allAddedRows)

. . . . . .

Me.UpdateDeletedRows(dataSet, allChangedRows)

. . . . . .

End Function

Private Function UpdateInsertedRows(ByVal dataSet As DataSet1, ByVal allAddedRows As Global.System.Collections.Generic.List(Of Global.System.Data.DataRow)) As Integer

. . . . . .

Me.SortSelfReferenceRows(addedRows, dataSet.Relations("FK_Temp_Temp"), False)

. . . . . .

End Function

Private Function UpdateDeletedRows(ByVal dataSet As DataSet1, ByVal allChangedRows As Global.System.Collections.Generic.List(Of Global.System.Data.DataRow)) As Integer

. . . . . .

Me.SortSelfReferenceRows(addedRows, dataSet.Relations("FK_Temp_Temp"), True)

. . . . . .

End Function

Protected Overridable Sub SortSelfReferenceRows(ByVal rows() As Global.System.Data.DataRow, ByVal relation As Global.System.Data.DataRelation, ByVal childFirst As Boolean)

Global.System.Array.Sort(Of Global.System.Data.DataRow)(rows, New SelfReferenceComparer(relation, childFirst))

End Sub

Private Class SelfReferenceComparer

Inherits Object

Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow)

Private _relation As Global.System.Data.DataRelation

Private _childFirst As Integer

. . . . . .

Public Function Compare(ByVal row1 As Global.System.Data.DataRow, ByVal row2 As Global.System.Data.DataRow) As Integer

Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow).Compare

If Object.ReferenceEquals(row1, row2) Then

Return 0

End If

If (row1 Is Nothing) Then

Return -1

End If

If (row2 Is Nothing) Then

Return 1

End If

'Is row1 the child or grandchild of row2

If Me.IsChildAndParent(row1, row2) Then

Return Me._childFirst

End If

' row2 the child or grandchild of row1

If Me.IsChildAndParent(row2, row1) Then

Return (-1 * Me._childFirst)

End If

Return 0

End Function

End Class

Sample Code Snippet to Update the Database

Then, you could update the table with the help of TableAdapterManager. Below is snippet of sample code to insert some rows to the self-referencing Temp table, and then delete them.

[C#]

DataSet1 ds = new DataSet1();

DataSet1.TempRow row1 = ds.Temp.AddTempRow(1, null, "Row 1");

DataSet1.TempRow row4 = ds.Temp.AddTempRow(4, null, "Row 4");

DataSet1.TempRow row2 = ds.Temp.AddTempRow(2, row1, "Row 2");

DataSet1.TempRow row3 = ds.Temp.AddTempRow(3, row4, "Row 3");

DataSet1TableAdapters.TableAdapterManager manager = new DataSet1TableAdapters.TableAdapterManager();

. . . . . .

manager.UpdateAll(ds); // Insert the rows

row1.Delete();

row2.Delete();

row3.Delete();

row4.Delete();

manager.UpdateAll(ds); // Delete the rows

[VB]

Dim ds As DataSet1 = New DataSet1

Dim row1 As DataSet1.TempRow = ds.Temp.AddTempRow(1, Nothing, "Row 1")

Dim row4 As DataSet1.TempRow = ds.Temp.AddTempRow(4, Nothing, "Row 4")

Dim row2 As DataSet1.TempRow = ds.Temp.AddTempRow(2, row1, "Row 2")

Dim row3 As DataSet1.TempRow = ds.Temp.AddTempRow(3, row4, "Row 3")

Dim manager As DataSet1TableAdapters.TableAdapterManager = New DataSet1TableAdapters.TableAdapterManager

manager.UpdateAll(ds) ' Insert the rows

row1.Delete()

row2.Delete()

row3.Delete()

row4.Delete()

manager.UpdateAll(ds) ' Delete the rows

What is the Problem and Why

From the code at the beginning of the post, we can see that TableAdapterManager uses System.Array.Sort<T>(T, IComparer<T>) to sort all rows before inserting them into or deleting them from database so that no violations to foreign-key constraints occur. The expected sorting result is: parent first for inserted rows, and child first for deleted rows. Take the sample code above for example, before calling SortSelfReferenceRows method, content of the array to insert is <R₁, R₄, R₂, R₃>. After calling the sorting method, R₁should come before R₂, and R₄ should come before R₃. Because R₁ is Parent of R₂, and R₄ is Parent of R₃. Sequence between two rows that do not have Parent-Child (or Grandparent-Grandchild, etc) relationships are undetermined, e.g., R₁ could come either before or after R₄.

For each pair <row1, row2> in the array to sort, SortSelfReferenceRows.Compare() will be called to determine their sequence in the output array. From the implementation of SortSelfReferenceRows.Compare, we could see that any two rows that do not have a Parent-Child (or Grandparent-Grandchild, etc) relationship are treated equal. This is OK if all possible row pairs are compared, e.g. < R₁, R₄>, < R₁, R₂>, < R₁, R₃>, < R₄, R₂>, < R₄, R₃>, < R₂, R₃> are all explicitly compared by passing them to SortSelfReferenceRows.Compare. However, System.Array.Sort is implemented using QuickSort, it does not compare every possible row pair. Instead, equation relationships of rows are treated transitive. For example, if < R₁, R₄>is compared and the result is R₁ == R₄, < R₄, R₂> is compared and the result is R₄ == R₂, then System.Array.Sort will indicate that R₁ == R₂, and does NOT compare < R₁, R₂> at all! Clearly, you could see that R₁ is Parent of R₂, < R₁, R₂> should be explicitly compared and the result should be R₁ < R₂.

The Idea of the Solution

So, how to sort the array so that no foreign-key constraints are violated? The idea is to treat the array as a forest, group all rows that have the same root into a tree, and compare the rows based on their root and their distance to the root. For example, suppose we have an array < R₁, R₂, …, R₁₄>, and the Parent-Child relationships among its elements are shown like picture below.

We still use System.Array.Sort<T>(T, ICompare<T>) to sort the array. That means we do not have direct control over the sorting algorithm, and we do not know what row pairs to be compared or the sequence of these comparisons. However, we do could impact the sorting process by controlling the comparison result of row pairs. That’s why we need to re-write the SelfReferenceComparer.Compare method.

The pseudo code of the new Compare method is (suppose Parent First):

int Compare (DataRow row1, DataRow row2)

DataRow root1 = row1’s root;

int distance1 = row1’s distance to root1

DataRow root2 = row2’s root;

int distance2 = row2’s distance to root2;

if (root1 == root2)

return distance1 – distance2;

else

return root1.RowIndex – root2.RowIndex;

end

How to Work-Around The Problem with Visual Studio 2008 SP1

With Visual Studio 2008 SP1, as a workaround, you could derive from the generated TableAdpaterManager and override its SortSelfReferenceRows method to implement this algorithm by yourself. Of course, you could put your code anywhere of your project, but it’s recommended to put them in the typed-dataset’s source code file. Right-click the typed-dataset (say, DataSet1.xsd), and choose “View Code”, Visual Studio will automatically create the source code file for you (DataSet1.cs in this case). It’s recommended you put your implementation code here.

Your code could be like this:

[C#]

// Derive from the generated TableAdapterManager and use it in your code instead

public class MyTableAdpaterManager : DataSet1TableAdapters.TableAdapterManager {

// Override this virtual method, and pass your own IComparer class

protected override void SortSelfReferenceRows(System.Data.DataRow[] rows, System.Data.DataRelation relation, bool childFirst) {

System.Array.Sort<System.Data.DataRow>(rows, new MySelfReferenceComparer(relation, childFirst));

}

private class MySelfReferenceComparer : object, global::System.Collections.Generic.IComparer<global::System.Data.DataRow> {

private global::System.Data.DataRelation _relation;

private int _childFirst;

internal MySelfReferenceComparer(global::System.Data.DataRelation relation, bool childFirst) {

this._relation = relation;

if (childFirst) {

this._childFirst = -1;

}

else {

this._childFirst = 1;

}

// Get the root of a row, and calculate its distance to the root

private global::System.Data.DataRow GetRoot(global::System.Data.DataRow row, out int distance) {

global::System.Diagnostics.Debug.Assert((row != null));

global::System.Data.DataRow root = row;

distance = 0;

// Save all traversed rows to avoid infinite loop

global::System.Collections.Generic.IDictionary<global::System.Data.DataRow, global::System.Data.DataRow> traversedRows = new global::System.Collections.Generic.Dictionary<global::System.Data.DataRow, global::System.Data.DataRow>();

traversedRows[row] = row;

global::System.Data.DataRow parent = row.GetParentRow(this._relation, global::System.Data.DataRowVersion.Default);

while ((parent != null) && !traversedRows.ContainsKey(parent)) {

distance++;

root = parent;

traversedRows[parent] = parent;

parent = parent.GetParentRow(this._relation, global::System.Data.DataRowVersion.Default);

}

// This is mainly for Deleted rows

if (distance == 0) {

traversedRows.Clear();

traversedRows[row] = row;

parent = row.GetParentRow(this._relation, global::System.Data.DataRowVersion.Original);

while ((parent != null) && !traversedRows.ContainsKey(parent)) {

distance++;

root = parent;

traversedRows[parent] = parent;

parent = parent.GetParentRow(this._relation, global::System.Data.DataRowVersion.Original);

}

return root;

}

public int Compare(global::System.Data.DataRow row1, global::System.Data.DataRow row2) {

if (object.ReferenceEquals(row1, row2)) {

return 0;

}

if ((row1 == null)) {

return -1;

}

if ((row2 == null)) {

return 1;

}

// Get root of row1 and calculate its distance to the root

int distance1 = 0;

global::System.Data.DataRow root1 = this.GetRoot(row1, out distance1);

// Get root of row2 and calculate its distance to the root

int distance2 = 0;

global::System.Data.DataRow root2 = this.GetRoot(row2, out distance2);

if (object.ReferenceEquals(root1, root2)) {

return this._childFirst * distance1.CompareTo(distance2);

}

else {

// Compare root1 and root2 with their row index to ensure the correct sort order

global::System.Diagnostics.Debug.Assert((root1.Table != null) && (root2.Table != null));

if (root1.Table.Rows.IndexOf(root1) < root2.Table.Rows.IndexOf(root2)) {

return -1;

}

else {

return 1;

}

[VB]

' Derive from the generated TableAdapterManager and use it in your code instead

Public Class MyTableAdapterManager

Inherits DataSet1TableAdapters.TableAdapterManager

' Override this virtual method, and pass your own IComparer class

Protected Overrides Sub SortSelfReferenceRows(ByVal rows() As System.Data.DataRow, ByVal relation As System.Data.DataRelation, ByVal childFirst As Boolean)

Global.System.Array.Sort(Of Global.System.Data.DataRow)(rows, New MySelfReferenceComparer(relation, childFirst))

End Sub

Private Class MySelfReferenceComparer

Inherits Object

Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow)

Private _relation As Global.System.Data.DataRelation

Private _childFirst As Integer

Friend Sub New(ByVal relation As Global.System.Data.DataRelation, ByVal childFirst As Boolean)

Me._relation = relation

If childFirst Then

Me._childFirst = -1

Else

Me._childFirst = 1

End If

End Sub

' Get root of a row, and calculate its distance to the root

Private Function GetRoot(ByVal row As Global.System.Data.DataRow, ByRef distance As Integer) As Global.System.Data.DataRow

Global.System.Diagnostics.Debug.Assert((Not (row) Is Nothing))

Dim root As Global.System.Data.DataRow = row

distance = 0

' Save all traversed rows to avoid infinite loop

Dim traversedRows As Global.System.Collections.Generic.IDictionary(Of Global.System.Data.DataRow, Global.System.Data.DataRow) = New Global.System.Collections.Generic.Dictionary(Of Global.System.Data.DataRow, Global.System.Data.DataRow)()

traversedRows(row) = row

Dim parent As Global.System.Data.DataRow = row.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.[Default])

Do While ((Not (parent Is Nothing)) _

AndAlso (traversedRows.ContainsKey(parent) = False))

distance = distance + 1

root = parent

traversedRows(parent) = parent

parent = parent.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.Default)

Loop

' This is mainly for Deleted rows

If (distance = 0) Then

parent = row.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.Original)

Do While ((Not (parent Is Nothing)) _

AndAlso (traversedRows.ContainsKey(parent) = False))

distance = distance + 1

root = parent

traversedRows(parent) = parent

parent = parent.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.Original)

Loop

End If

Return root

End Function

Public Function Compare(ByVal row1 As Global.System.Data.DataRow, ByVal row2 As Global.System.Data.DataRow) As Integer Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow).Compare

If Object.ReferenceEquals(row1, row2) Then

Return 0

End If

If (row1 Is Nothing) Then

Return -1

End If

If (row2 Is Nothing) Then

Return 1

End If

'Get root of row1 and calculate its distance to root

Dim distance1 As Integer = 0

Dim root1 As Global.System.Data.DataRow = Me.GetRoot(row1, distance1)

'Get root of row2 and calculate its distance to root

Dim distance2 As Integer = 0

Dim root2 As Global.System.Data.DataRow = Me.GetRoot(row2, distance2)

If Object.ReferenceEquals(root1, root2) Then

Return Me._childFirst * distance1.CompareTo(distance2)

Else

' Compare root1 and root2 with their row index to ensure the correct sort order

Global.System.Diagnostics.Debug.Assert((Not root1.Table Is Nothing) AndAlso (Not root2.Table Is Nothing))

If (root1.Table.Rows.IndexOf(root1) < root2.Table.Rows.IndexOf(root2)) Then

Return -1

Else

Return 1

End If

End Function

End Class

For the complete sample code, you could download it at Code Gallery. Cheers!

Multi-Targeting and N-Tier Dataset

Shichao Hu — Wed, 29 Jul 2009 17:21:00 GMT

Multi-Targeting in Visual Studio

What is Multi-Targeting in Visual Studio?

The multi-targeting feature of Visual Studio lets you specify the version of the .NET Framework, or its profile, that is required for your application.

For example, with Multi-Targeting, you can use the latest Visual Studio to continue to develop your existing projects that were created in Visual Studio 2008 or even earlier without adding new .NET Framework dependencies. The key benefit is you can leverage those new features/tools in the latest release of Visual Studio.

In Visual Studio 2008, we've already had some support for Multi-Targeting -- you can create and develop projects targeting to .NET 2.0, 3.0 and 3.5. All these framework versions still use the same common language runtime (CLR) 2.0 so it’s easier for Visual Studio to switch targets.

However, in Visual Studio 2010, it is much more complicated than before. For example, we have different .NET framework versions (2.0, 3.0, 3.5 and 4.0); we have different profiles (Client Profile vs. Full Profile); we have different .NET runtime versions (2.0 vs. 4.0); we have different frameworks (.NET framework vs. Silverlight framework). The good news is that Visual Studio 2010 will be fully supporting Multi-Targeting. You can use it to create and develop projects targeting any configuration.

If you'd like to learn more about Multi-Targeting, here is the walkthrough for Visual Studio 2010 beta 1.

http://msdn.microsoft.com/en-us/library/bb398202(VS.100).aspx

If you are also interested in other features in Visual Studio 2010 beta 1, here is the complete walkthroughs,

http://msdn.microsoft.com/en-us/vstudio/dd441784.aspx

You can download and try Visual Studio 2010 beta 1 here.

http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

N-Tier Dataset

Now, let's talk about Dataset Designer -- one of the frequently used data related features in Visual Studio. Some of you may already know that Dataset Designer supports N-Tier applications by splitting Datasets and TableAdapters into different projects. This is usually called N-Tier Dataset. If you are unfamiliar with this feature, please see this How Do I video. This means that you can now physically separate the data access layer (the tableAdapters) from your entities (the dataset structure and validation code). This allows you to share just the entities on the client-side leaving the data access layer on the server side giving you clean n-tier separation.

In Visual Studio 2010, we have the complicated Multi-Targeting scenarios, so what is the impact on the N-Tier Dataset?

An example of a N-Tier DataSet application is shown as below. The dataset project item is in the TableAdapter project, which is the data access layer. The dataset classes will be generated in the DataSet project, which is the data structure layer.

In Visual Studio 2008, when you want to split the DataSet from the TableAdapters, the .NET framework version of the target DataSet project must be equal or greater to the TableAdapter project. Because we need to make sure the Datasets are working correctly in the target project. However, you may find that this is not true in Visual Studio 2010. Because with the new CLR 4.0, if the TableAdapter project is targeting the .NET framework 3.5 (CLR 2.0), it cannot reference a DataSet project which targets the .NET framework 4.0 (CLR 4.0).

So in Visual Studio 2010, the requirement will be -- The dataset project must be targeting to the same version of the .NET framework as the TableAdapter project.

There is also another interesting scenario I'd like to mention here. For instance, say you have a Visual Studio 2008 solution with two projects as an N-Tier Dataset application and both of these two projects are targeting the .NET framework 3.5. (figure below)

Now you want to use Visual Studio 2010 for development and you want to re-target both of your projects to the .NET framework 4.0. So you reset the target framework version of TableAdapter project, then you may see an error about the MSDataCodeGenerator custom tool.

This is because at this time, you have one project re-targeted 4.0, but the other one is still 3.5. You can ignore this error and continue to re-target the other project. After you finish, you can re-run the MSDataSetCodeGenerator custom tool by right-clicking the dataset project item and then click [Run Custom Tool]. It will regenerate Dataset classes in the target project, and you are good now!

Cheers!

Using TableAdapters to Insert Related Data into an MS Access Database

Beth Massi — Fri, 15 May 2009 04:54: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.

Read more on my blog here…

TableAdapter and Multiple Result Sets

youngjoo — Fri, 09 Mar 2007 01:22:00 GMT

Several people asked me whether TableAdapter can be used to retrieve multiple result sets from stored procedures. The quick answer is... No, you can't do that with TableAdapter.Fill() method that gets generated as a part of Typed Dataset. But there's a very simple work-around.

DataAdapter.Fill() & Multiple Result Sets

TableAdapter.Fill() method calls DataAdapter.Fill() to retrieve data from database. And DataSet.Fill() method allows you to retrieve multiple result sets from a stored procedure. In order to retrieve multiple result sets, an overload of DataAdapter.Fill() that takes Dataset as a parameter needs to be used. If you do that, you get back a Dataset that contains multiple data tables filled with result sets returned by your stored procedure.

Here's a simple example that shows you how this works.

Let's say that you have a stored procedure called dbo.spSelectCustomersOrders in Northwind database.

CREATE PROCEDURE spSelectCustomersOrders

BEGIN

SET NOCOUNT ON;

SELECT * FROM Customers

SELECT * FROM Orders

END

Below code will call this stored procedure and fill Dataset with both result sets.

Dim myConn As New System.Data.SqlClient.SqlConnection

Dim myAdapter As New System.Data.SqlClient.SqlDataAdapter

Dim mySelectCommand As New System.Data.SqlClient.SqlCommand

Dim myDataset As New System.Data.DataSet

myConn.ConnectionString = "Data Source=.\SQLExpress;Initial Catalog=Northwind;Integrated Security=True"

mySelectCommand.Connection = myConn

mySelectCommand.CommandText = "dbo.spSelectCustomersOrders"

myAdapter.SelectCommand = mySelectCommand

myAdapter.Fill(myDataset)

For Each table As System.Data.DataTable In myDataset.Tables

Console.WriteLine("Table Name:" & table.TableName)

Output of this code looks like this.

Table Name: Table
Table Name: Table1

As you can see, DataAdapter.Fill() method executed the stored procedure and put each result set into two separate DataTables.

TableAdapter Solution

But why doesn't TableAdapter.Fill() correctly handle multiple result sets? It's because TableAdapter.Fill() calls DataAdapter.Fill() overload that takes DataTable, not Dataset. This can be easily addressed by creating a new Fill method in TableAdapter that calls DataAdapter.Fill() overload that takes Dataset.

Assume we have NorthwindDataset.xsd that contains both Customers and Orders. And let's use the above stored procedure for our new Fill method. Add following code to your partial class file. You can create a partial class file by either double-clicking on the Dataset Designer surface, right-click on the Dataset Designer surface and choose "View Code" or add an empty class file manually.

Namespace NorthwindDataSetTableAdapters

Partial Public Class CustomersTableAdapter

Public Function FillCustomersOrders(ByVal dataSet As NorthwindDataSet) As Integer

Dim multiSelectCommand As New System.Data.SqlClient.SqlCommand

Dim returnValue As Integer

multiSelectCommand.Connection = Me.Connection

multiSelectCommand.CommandText = "dbo.spSelectCustomersOrders"

Me.Adapter.SelectCommand = multiSelectCommand

'' Map auto-created Table1 that holds the second result-set (Orders rows) to

'' Orders DataTable in our Dataset.

Me.Adapter.TableMappings.Add("Table1", "Orders")

returnValue = Me.Adapter.Fill(dataSet)

Return returnValue

End Function

End Class

End Namespace

Couple of key points to note.

First, this new FillCustomersOrders takes Dataset as a parameter. This way, when we call DataAdapter.Fill() we can retrieve both result sets and fill Dataset appropriately.

Second, notice how we use TableMapping to map automatically created DataTable to Orders DataTable in our Dataset. When result sets are retrieved by DataAdapter.Fill() method, each result set is stored in separate DataTables in Dataset. By default, these DataTables are named as Table, Table1, Table2, etc. In order to map these DataTables to typed DataTables defined in our Dataset, we need to use TableMapping. If you open up code behind file for NorthwindDataset.xsd, for example, and browse to InitAdapter() method of one of TableAdapter class, you will see something similar to below.

tableMapping.SourceTable = "Table"

tableMapping.DataSetTable = "Customers"

'' Colum mapping code skipped

...

Me._adapter.TableMappings.Add(tableMapping)

This block of code ensures that what gets returned by DataAdapter.Fill method maps to the correct typed DataTable in our Dataset. In our case with FillCustomersOrders, we know that the second result set contains Orders rows. So we need to create a mapping between Table1 and Orders to make sure Orders DataTable gets filled correctly.

After you add above code to the partial class file, you can call FillCustomersOrders to fill both Customers and Orders with just one round-trip to database.

CustomersTableAdapter.FillCustomersOrders(Me.NorthwindDataSet)

Performance Consideration

I can see how this kind of capability could be helpful in some cases. But you have to remember that this comes with its own issues. Although you might think that avoiding multiple trips to database would help in terms of performance, you could end up hurting performance by retrieving large set of data when you only need a sub-set. A lot of times, it is much better to retrieve smaller set of data, only what you need at the moment, and make another call to database when you need other sets of data. ADO.NET does a pretty good job of optimizing connection pooling so making multiple connections to database doesn't cause performance bottleneck in many cases. Rule of thumb. Only retrieve what you need.

But I can see how retrieving multiple result sets can be helpful in some cases. So, make use of the technique I described here and just make sure you consider performance issues always.

Additional Resources

DataAdapter.Fill(DataSet): http://msdn2.microsoft.com/en-gb/library/377a8x4t.aspx
DataTableMapping Class: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdatacommondatatablemappingclasstopic.asp
How to: Extend the Functionality of a Dataset: http://msdn2.microsoft.com/en-us/library/ms171896(VS.80).aspx

- Young Joo, Program Manager, Visual Basic