TESTING THE CONNECTIONS OF LINKED TABLES AT STARTUP
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.)
Listing 27.3. VideoApp(ADO).mdb: Testing the Links
'-- 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.