Cursors
Chapter 7 teaches you about the different cursor types and some of their properties. The two main forms in the Cursors sample—frmGoFish and frmSeeChanges—can help you build on that knowledge.
Remember the game Go Fish? In this simple card game, you ask another player for a specific card such as an ace or a king. If that player does not have that card in his or her hand, you must "go fish" by taking a card from the deck. If you're lucky, the card you draw from the deck will be the card you asked for.
Many programmers run into cursor-related problems when they do not receive the type of cursor they asked for. I often hear programmers say they're experiencing unexpected behavior when they open a particular type of cursor. Because I usually wind up asking questions such as, "I know you requested a keyset cursor, but did you get what you asked for?" I decided to name one of the forms in this sample frmGoFish. You can use this form, shown in Figure B-1, to supply a connection string and a query string, as well as values for the Recordset's CursorLocation, CursorType, and LockType properties. After you run the query, the form will indicate the resulting values for the Recordset's CursorLocation, CursorType, LockType, and RecordCount properties, as well as whether the Recordset supports bookmarks.
Figure B-1. Click the Go Fish button to bring up the frmGoFish form, titled Did You Get What You Asked For?
The other main form in the project, frmSeeChanges, will help you understand which changes made by other users will be visible in your Recordset. Because providing this functionality is quite an undertaking, I've tried to make this sample helpful without making it overly complex. Consider it a starting point on which you can build.
With this form, shown in Figure B-2, you can specify a connection string, as well as values for the Recordset's CursorLocation, CursorType, LockType, and CacheSize properties. When you click the Run Query button, the form's code connects to the specified database and creates a sample table, populates that table with 20 rows, retrieves those rows into a Recordset, and then simulates changes made by other users by modifying, deleting, and inserting rows in the database (but not in the Recordset). You can then navigate through the Recordset with a simplistic data control to see whether some of those changes are visible.
Figure B-2. Click the See Changes button to bring up the frmSeeChanges form, titled Seeing Changes Made By Other Users.
The table that this form's code creates, SeeChanges, is simple. It has an integer field named ID, which serves as its primary key, and a Description field. When the code opens the Recordset object, the table contains 20 rows with ID values of 1-20 and a description of "Original Entry". After the code opens the Recordset, it modifies some rows by setting the description of rows 2, 3, 5, 7, 11, 13, 17, and 19 to "Modified By Another User". The code also deletes rows with IDs of 1, 4, 9, and 16, and it creates new rows with IDs of 21-24 and the description "Entered By Another User".
Both frmGoFish and frmSeeChanges use code copied from the What's My Constant sample to display the names of constants associated with values retrieved from the Recordset's CursorLocation, CursorType, and LockType properties. This code appears in the module named modADOConstants.
These two forms also use a common form called frmManageConnectionStrings, shown in Figure B-3, that allows the user to manipulate and store multiple connection strings for the form. You access this form by selecting <Manage Connection Strings> from the ConnectString drop-down list box. The user interface for frmManageConnectionStrings is fairly simplistic, but it lets you add, edit, and delete connection strings and make them available on the frmGoFish and frmSeeChanges forms in the ConnectString drop-down list box. There is one highlight of the code for this form that I'd like to point out. If you double-click the connection string text box while you're in Edit mode, the code invokes the Data Link Properties dialog box to help you edit the connection string. The frmGoFish and frmSeeChanges forms in this sample use similar code. I also use the frmManageConnectionStrings form in the Detecting Conflicts sample.
Figure B-3. The frmManageConnectionStrings form, titled Manage Connection Strings.
NOTE
There's one minor "gotcha" to using the Data Link Properties dialog box in these sample applications. By default, if you enter a password in the dialog box, that password will not be returned with the rest of the connection information. Check the Allow Saving Password check box to return the password in the connection string.
There's a module called modSettingsFile that I use to store and retrieve settings for a particular application. But this code doesn't store this information in the Microsoft Windows Registry. Instead, this code persists a Recordset to store data in a settings file where the application resides. Why store settings this way? Not only to familiarize myself with using ADO's persistence functionality, but also because I work on a number of different computers on the same network. I like the idea of copying the executable and the settings file to another computer so that I can use the same settings on that computer. You'll also find this module in the Detecting Conflicts sample.
EAN: N/A
Pages: 131