System.Data Run-Time Breaking Changes

A user who does *all 4* of the following: 

1) Uses XML Inference to build the initial schema for DataSet (i.e. DataTable's schema),

2) Expects Column ordinals to be consistent,

3) Uses column ordinals to access DataColumn,

4) The input xml file used for inference incrementally adds attributes/elements to a specific element. For instance, Element Customer, that gets mapped to DataTable: Customer has its Content Model (structure) built incrementally by adding new Attributes (i.e. "age"). 

<Customer name="John"> <Order orderID = "10"></Order> ... </Customer> <Customer name="Jack" age="30"> <State>CA</State> <Order orderID = "10" items="10" > ... </Customer>In V1.1 the ordering will be: 

1. Customer.Hidden_PrimaryKey, ordinal = 0
2. Customer.name, ordinal = 1
3. Customer.age, ordinal = 2
4. Customer.State, ordinal = 3

In V2.0 the new ordering will be: 

1. Customer.State, ordinal = 0
2. Customer.Hidden_PrimaryKey, ordinal = 1
3. Customer.name, ordinal = 2
4. Customer.age, ordinal = 3

XmlDataDocument uses internal APIs to create partially initalized DataRows. The partial initialization for DataRows containing String columns can result in invalid rows in v1.x. The reason for invalid string column values stems from how v1.x stores NULL and DEFAULT column values. For all columns other than String the storage value for NULL and implicit SAME is same. However for String, the implicit default value is "null" and the NULL value is "DBNullValue" string constant.

The string column value is either a non-null value or a null value. i.e. the storage should be either user specified non null string or "DbNullValue". However, when internal API DataTable.CreateEmptyRow() is used by XmlDataDocument, the null string column values are stored as "null" instead of "DbNullValue". [The storage for string column value should never have "null" value in v1.x]. Now because CreateEmptyRow() does not do constraint checking, in this step no violation is detected in v1.x or v2.0.

[** Note in version 2.0, null values for string is stored as "null" instead of "DbNullValue" just like for all other DataTypes having "null" as a legal value in it's value space **]

AllowDbNull constraint:
If this column has a AllowDbNull constraint set to false (i.e. no nulls allowed), the check for null looks for "DbNullValue" string constant instead of "null" and cannot honor the constraint i.e. it allows columns to have null values.

Merge:
When DataSet X created by XmlDataDocument is merged into another empty DataSet Y, the merge process trusts the incoming rows and uses an internal API "MergeRow" that copies the exact column values [bypassing the regular row creation and initialization process] as the result the illegal "null" column value in v1.x gets SUCCESSFULLY copied over to dataset 'Y'. The null constraint checker does not find any NULL column values.

Version 1.1 Behavior:
DataRow with illegal column values created by XmlDataDocument's use of internal DataTable.CreateEmptyRow method is successfully merged into another DataSet. AllowDbNull constraint is compromised.

Version 2.0 Behavior:
AllowDbNull constraint is always honored and the constraint checking that happened at the end of the merge process throws exception.

1. User populates XmlDataDocument which in turn creates rows in it's underlying DataSet. The DataSet has table with one or more String columns with AllowDbNull=false (i.e. column value cannot be null).
2. While populating with XmlDataDocument, user does not specify an explicit value for the string column.
3. User then merges the underlying DataSet to an empty DataSet. The merge is successful in v1.x but may throw constraint violation exception for v2.0.

All DataColumn access APIs:

1. DataTable.rows[rowIndex][columnIndex]
2. DataRow.Add(Object[] values)
3. All other APIs which cause a column's values to get modified.

There is extremely limited support for UDTs in DataSet for v1.0 and v1.1. UDT columns can be created, but there is no support for:

• populating UDTs through DataAdapter
• UDT serilzation
• besides, it an un-documented feature

Given this, it is not a useful feature as shipped in v1.0/v1.1. UDT columns were treated as 'Object' for storage purposes. This allowed for assignment of any Object to UDT's value. Using untyped 'Object' storage for UDTs compromised 'type checking'.

We want to allow a UDT value to take on the value of the specified type or its derived types only.

Existing users can use UDTs only through in-memory operations; they cannot be persisted either to XML or database.

The user is casting the object that is returned from the ExecuteXmlReader api call to an XmlTextReader. In v1.1 this worked, however we changed the internal type from V1.1 to V2.0 for a number of reasons:

1. Support for BinaryXml coming from the server.
2. A security issue, resulting from the fact that the XmlTextReader exposes the Stream from which it is parsing.

Users should not be depending on the fact that the returned reader was an XmlTextReader.

In v1.x a DataRowView was an immutable instance. DataView maintains a cache of DataRowViews and re-creates the complete cache (where size could be 1 to 1 million DataRowViews) whenver any dataRow in the underlying DataTable is changed.

In v1.x a DataRowView was an immutable instance whereas in v2.0 it is not the case. DataRowView.Row can get changed so that it is in sync with it's DataRowView.Index value. DataRowView contains 2 components:

1. DataRowView.Index (private member) points to index of DataRowView as appearing in DataView[n]
2. DataRowView.DataRow (public, read-only) refers to DataRow associated with position DataView[n]

For v2.0, DataRowView.Index is immutable whereas the DataRowView.DataRow can change to point to the current DataRow associated with DataView[n]

In V1.x, since the complete DataRowView cache was re-created on any change in DataView, the discarded DataRowInstances were not updated and could be stale like pointing to the wrong index or DataRow; they are kind of practically unusable.

In v 2.0, users can hold on to DataRowView, the discarded (if any) are marked as such to avoid inconsistency.

In addition, in V1.x DataRowView.GetHashCode always returns the same value (delegated to underlying DataRow and reference to it is immutable). In V2.0, as it's reference to DataRow can change, so can it's HashCode.

Affected APIs:

1. DataRowView.GetHashCode()
2. DataRowView.Row
3. DataRowView.Delete()

Affected User Scenario(s):

1. User creates DataView over DataTable.
2. Keeps reference to DataRowView instances.
3. Makes changes to underlying DataTable's DataRows.
4. Uses the saved, stale DataRowView instances and invokes the APIs (1), (2) or (3).

The result is unpredictable as the instances are stale (more like stale c++ pointers) but may be repeatable for a fixed sequences of operations

Workaround:

1. Get the DataRowView at the disired position using DataView[index].
2. Scan the DataView[] for locating the DataRowView with the desired DataRow.
3. Hold reference to the DataRow object and use it as needed.

1. DataSet.Merge(DataSet dataSet)
2. DataSet.Merge(DataTable dataTable)
3. DataSet.Merge(DataRow[] rows)

In v1.x DataTable support the notion of XSD Namespace but didn't attach any semantics to it. DataTable in DataSet were indintifiable by their Names alone, as it was a requirement that TableNames in a DataSet be unique. In v2.0, DataSet fully supports the notion of XSD namespaces, and the combination of DataTable.NameSpace and DataTable.TableName are required to uniquely identidy the DataTable in a DataSet.

For backwards compatibilty v2.0 supports lookups using TableName alone and works as v1.0 when 2 tables with the same name do not exist (as was the case in v1.x).

Merge in v2.0 only uses the Namespace for looking up the tables if the current DataSet has a non-empty namespace ad does a namespace agnostic lookup else it uses Namespace for lookups.

1. User creates 2 different DataSets and assigns different namespaces to each of them.
2. The user assumes v1.x behavior and expects DataSet.Merge to ignore Table namespace while matching tables
3. User uses any of the 3 affected APIs v2.0 scenario would be different instead of merging the incoming rows to an existing table it would create a new table and inert the rows there.
4. This only happens when the namespace on the current DataSet on which Merge is invoked has a non-empty namespace that is different than the Namespace of the incoming DataTable or DataSet.

1. Before Merge reset namespace of both DataSet to (empty) or some other string so that they have the same namespace and Restore namespaces post Merge.
2. Create Method like:
Public void MyMerge(DataSet targetds, DataRows[] rows
)
   { DataTable table = targetds.Tables[rows.Table.TableName]; //
ignore Namespace for table lookups.
   // Use requied LoadOption to get a more fine grain control on
Merge
   For (int i=0; i<rows.Length; i++)
      Table.LoadDataRow(rows[i], LoadOption.Upsert);
}