As you continue to examine the sections of the ap_AppInit() function, now look at Section 3, which opens and tests the connection for a table located in the back end, with the connection being a link in the front end (see Listing 27.3.)
'-- Section 3: Open the table containing the list of ' linked tables and test the link. ' Open employee table. rstSharedTables.Open "tblSharedTables", cnnLocal, adOpenStatic On Error Resume Next rstSharedTables.MoveLast Dim rstTestTable As New ADODB.Recordset Dim strTableName As String strTableName = rstSharedTables!TableName rstTestTable.Open strTableName, cnnLocal, adOpenStatic lngCurrError = Err.Number If lngCurrError = 0 Then Dim varTest As Variant varTest = rstTestTable(0).Name lngCurrError = Err.Number End If strCurrError = Err.Description Do Until lngCurrError = 0 On Error GoTo Error_ap_App_Init Select Case lngCurrError Case apErrInvalidSQL |
In this version of section 3, the link is tested at the field level as well as opened. Opening the link might not trigger an error, but accessing the field will.
The code in Section 3 performs these actions:
1. |
The tblSharedTables table is opened and assigned to rstSharedTables, which is a static type ADO recordset data type variable. |
2. |
The code sets error handling to ignore errors and just moves to the next line by using the On Error Resume Next statement. |
3. |
It tries to open the last table in rstSharedTables as a static recordset, and then stores the error codes (if any) to variables for later use. |
4. | |
5. |
The code begins a loop that performs another test (at the bottom) as in step 3. Inside this loop are the corrections for the various errors. When one error is solved—for example, a moved back end—the loop tests again and resends the code execution through the error list. |
6. |
The code turns on error handling again and examines the possible errors that occurred. Constants are used to represent the errors you want to look for. |
Note
In Chapter 26, numerous error codes are trapped. As of the writing of this book, the only error code constant supplied is apErrInvalidSQL, which seems to cover quite a bit of ground. Whenever the database moved, the error number stored in this constant, in the Declarations section of the modGlobalUtilities modules, was raised. If you receive other error codes that don't get trapped, add them to the list of constants.
3.133.124.21