Disconnected Recordsets

[Previous] [Next]

What do you need to consider when you communicate with your database infrequently? For example, let's say that when your application starts up you want to retrieve data from your database but that you might not need to communicate with the database again during the lifetime of your application.

You might not want to keep a connection to your database open during long stretches of time when you're not actively using it. When using the ADO Cursor Engine, you can simply set the ActiveConnection property on your Recordset object to Nothing, and then close your Connection object and still have access to the data in your Recordset object. In fact, you can use the Cursor Engine's batch updating functionality and modify the contents of your Recordset object without a live connection to your database. You can later reopen your Connection object, reset the ActiveConnection property on the Recordset object, and call the object's UpdateBatch method to submit the changes to your database. This process is demonstrated in the following code:

 strSQL = "SELECT CustomerID, CustomerName, BalanceDue FROM Customers" rsCustomers.CursorLocation = adUseClient rsCustomers.Open strSQL, cnDatabase, adOpenStatic, adLockBatchOptimistic Set rsCustomers.ActiveConnection = Nothing cnDatabase.Close  'Modify your Recordset object while it's off line.  'Reconnect to the database. cnDatabase.Open Set rsCustomers.ActiveConnection = cnDatabase rsCustomers.UpdateBatch 

It's that easy. We won't discuss this feature, per se, in later chapters. However, we will talk about ways to use it more effectively in the chapters on updating your database with the ADO Cursor Engine (Chapter 10), handling optimistic updating conflicts (Chapter 12), and persisting your Recordset (Chapter 13).



Programming ADO
Programming MicrosoftВ® ADO.NET 2.0 Core Reference
ISBN: B002ECEFQM
EAN: N/A
Year: 2000
Pages: 131
Authors: David Sceppa

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net