Breaking ADO.NET Issues with .NET 3.5 SP1 Fixed by Update KB959209 of 12/20/2008
The .NET Framework team released an update (KB959209) on 12/20/2008 that received little publicity. Following are the three ADO.NET-related fixes (including ASP.NET Dynamic Data fixes) that affect developers using .NET 3.5 SP1:
From KB958481: List of the breaking issues with the .NET Framework 2.0 Service Pack 2 after you upgrade to the .NET Framework 3.5 Service Pack 1
The new [ASP.NET] dynamic data feature that is included in the .NET Framework 3.5 SP1 cannot navigate one-to-one relationships. Because of the inability to navigate one-to-one relationships, any attempt to create a dynamic data Web site that is running on an entity framework data model fails.
The ADO.NET Data Services client enables a client developer to insert a new entity into the service and to associate that entity with other related entities. If the client is talking to a data service that is backed by a relational database, the schema rules of the database are enforced on inserts to the service. In databases, it is common to put a NOT NULL constraint on foreign keys in tables. In such a case, an insert to that table must include a foreign key to the related entity. However, because of a code defect in the ADO.NET client library, new entities and reference associations cannot be set at one time. Therefore, you cannot use the ADO.NET Data Services client together with common foreign key table constraints.
From KB958483: List of the breaking issues with the .NET Framework 3.0 Service Pack 2 after you upgrade to the .NET Framework 3.5 Service Pack 1
After you install the .NET Framework 3.5 SP1, [ASP.NET] dynamic data cannot display foreign key IDs in a one-to-one relationship. Web sites or applications that are created by using ASP.NET dynamic data are broken because dynamic data assumes that property descriptors exist. Dynamic data uses the property descriptors to obtain labels for links.
Note the subtle differences in wording from the first breaking issue above.
AutoCommit behavior in Oracle transactions is different in the .NET Framework 2.0 SP1 from the behavior in the .NET Framework 2.0 SP2. In the .NET Framework 2.0 SP2, if an application starts a transaction, completes the transaction, and then starts a new transaction on the same connection, all the commands that are executed in the second transaction execute in auto-commit mode. The changes that are made by those commands are committed to the database even if the transaction is rolled back.
From KB958484 List of the breaking issues with the .NET Framework 3.0 Service Pack 1 after you upgrade to the .NET Framework 3.5 Service Pack 1
Same as KB958483 above.
Thanks to Scott Hunter for the heads-up in his Update for .NET 3.5 SP1 Released post of 12/30/2008.
Atom 1.0 site feed
0 comments:
Post a Comment