ADO.NET 2.0 Can Multi-Task—Almost
Since I anticipated that my MSDN Index search application might at times take quite a while to complete a complex search, I decided to try the new asynchronous DataReader features in ADO.NET 2.0 to display a progress bar. Although this detail was easy to implement, it didn't prevent lockups during long queries because executing a query and returning the rowset is a two-phase process. When you use the SqlClient.SqlCommand's BeginExecuteReader to start execution of your search query, control returns to your application immediately. At this point, you can display a progress bar or do whatever you need to do to entertain users so that they don't press CTRL-ALT-DEL in frustration. Once the IsCompleted state is set, you can access the DataReader stream—but the waiting isn't over. You still have to return the rows, which can take considerable time. ADO.NET doesn't provide asynchronous Load or Fill methods (which would be nice), so you'll have to resort to BackgroundWorker threads. Although these threads aren't tough to figure out, leaving out asynchronous Fill and Load seems like an oversight to me. Incidentally, this new feature almost catches up with COM-based ADO—which also supports asynchronous Connection Open.
ADO.NET 2.0 Makes Smarter Updates
COM-based ADO "classic" implemented batch updates years ago, and ADO.NET 2.0 finally includes this feature. This means you'll be able to make a dozen (or a thousand) changes to a DataTable and get ADO.NET to apply those changes with far fewer—perhaps just one—round trips to the server. To support this feature, ADO.NET exposes a new set of events that provide highly granular control of the operations and the exceptions that can occur.
Unless this feature gets cut (and it's on the chopping block as I write) ADO.NET 2.0 might also improve the way the CommandBuilder constructs action commands to handle concurrency. By exposing the new ConflictOption property, ADO.NET 2.0 lets you choose CompareAllSearchableValues (the current setting in ADO.NET 1.1), CompareRowVersion (which checks the RowVersion—timestamp—for concurrency tests), or OverwriteChanges (which forces the change by eliminating the WHERE clause from the UPDATE statement). This added flexibility means the CommandBuilder can better match your concurrency management approach. I don't see that using the CommandBuilder is any smarter when you're working with complex SelectCommand syntax.
ADO.NET 2.0 and SQL Server Work More Closely
SQL Server 2005 Express is Microsoft's replacement for the MSDE version of SQL Server. One of ADO.NET's more interesting features is its ability to open a SQL Server database (especially targeted toward SQL Server Express instances) simply by pointing to a SQL Server .mdf database file. Although accessing a database through .mdf files was supported in ADO.NET 1.0, ADO.NET 2.0 now permits the ConnectionString to contain a relative path to the .MDF file and lets you use it with application configuration settings. In addition, when you use the User Instance=True option, SQL Server copies the master, model, and tempdb databases, as well as your application database, to the current user's private data area. This move greatly simplifies database access and security and prevents damage to a shared master database and other system databases.
Although ADO.NET 2.0 still doesn't support server-side cursors, it does employ technology that might be a better match for many applications. Imagine having SQL Server fire an event in your application when any row in a specific rowset changes. That's exactly what happens with the new SqlNotificationRequest class when you're working with SQL Server Notification Services. This immediate notification lets developers refresh locally cached data when server-side data changes, and this technology can work with Windows Forms or ASP.NET applications.
ADO.NET also supports all of the new SQL Server data types, including varbinary(max), BLOB, and CLOB types as well as Common Language Runtime (CLR) user-defined types (UDTs). There's even a new SqlClient interface for use in CLR-based stored procedures, functions, aggregates, and triggers.
ADO.NET 2.0 No Longer Requires the MDAC Stack
In the past, developers and architects would take a deep breath and hope for the best as a new version of the MDAC stack was announced. They knew there was a good chance that it could break some of their deployed applications. With ADO.NET 2.0, you don't have to worry (as much) about breaking existing code because you no longer need the MDAC stack (which contains the COM-based ADO and selected netlib DLLs) to deploy ADO.NET applications. When you're building .NET Framework applications, the application executables can reside in a single directory that's not affected by new code installed after deployment. You can still mark selected DLLs to be installed and registered in common areas on the target system or in the Global Assembly Cache (GAC).
It's clear that Microsoft has spent considerable time working on the new ADO.NET 2.0 features and integrating them into Visual Studio and SQL Server 2005. It's also clear that Microsoft is serious about strongly typed data, data binding, and reporting. These new features can help developers implement smarter, safer, and faster designs with less code.
End of Article
Prev. page
1
[2]
next page -->
