Developing against SQL Server 2005 using the .NET Framework 1.1 provides a decent story for developers.  You won’t get the benefit of the productivity and/or light up features we implemented in 2.0 specifically for Yukon or features that target multiple versions of SQL Server (SqlBulkCopy, Async execution of commands, and Batching to name a few), or a bunch of the updates we made to improve the existing features.

 

There are 3 main issues to be aware of when using ADO.NET 1.1 against SQL Server 2005:

 

1)     Datatypes are represented as downlevel types (the Xml Datatype is ntext, VarChar(max) is text, NVarChar(Max) is ntext, VarBinary(max) is image, and a UDT is a varbinary).

2)     SqlDependency, SqlNotification, System.Transaction integration (promotable transactions), MARS, etc are not available

3)     For some server specific features you can access them via TSQL functionality (e.g. Snapshot Isolation is the best option)

 

When/if you upgrade you client apps from 1.1 to 2.0 you will run into the following issues that you should be aware of:

1)     Error Codes for failure cases have changed for some things.  We’ve gotten rid of “General Network Error”  and replaced it with more granular error codes and messages.  For common tasks like timeout we’ve kept the error code the same. 

2)     New SQL Server 2005 Types are represented as different types in 2.0 (e.g. XML used to be SqlString and now it’s SqlXml when calling GetSqlValue()).  This will often impact applications that work with these datatypes so we introduced a new feature in Whidbey to enable Whidbey Clients to view the new datatypes as downlevel (“Type System Version” is the connection string keyword to use and the you specify “SQL Server 2000” as the value).  This is documented in the msdn help content.

3)     Finally there are a number of breaking changes we took.  These are all posted at http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/sysdata.aspx.

 

 

-- Carl