One of the biggest problems with ADO.NET in previous versions is that no matter how responsive your application was, everything still had to wait for a command to execute. In other words, all command executions were done synchronously, whether the command took .2 or 200 seconds to execute.
Most developers got around this by wrapping the command execution in a method that was spawned in a background thread to allow the execution to take place while the rest of the application remained responsive.
With ADO.NET 2.0, that workaround is no longer necessary. You can use the standard Begin/End asynchronous method pattern that is prevalent throughout the .NET Framework. The SqlCommand class now has a corresponding Begin/End pair for some of its execute methods: ExecuteNonQuery(), ExecuteReader(), and ExecuteXmlReader().
Using these new methods, you can initiate an asynchronous command and then continue responding to events from the rest of the application. When the results are available, they will be returned to your application using one of the appropriate End methods, as shown in Listing 18.3.
Listing 18.3. Asynchronous Command Execution
Note that you have to include the Asynchronous Processing=true option in the connection string in order to enable asynchronous command execution in SQL Server. Also keep in mind that asynchronous processing is not part of the DbCommand abstract base class; it is part of the SqlCommand class only.