Yes, Dev used Oracle, but that's not an issue. The issue is that
(unfortunately) it doesn't have very good instructions!
Look in function fReconnectODBC(). It's looking for hard-coded DSN names:
'Check to make sure ODBC DSNs are present
'You can follow the same steps to check for multiple DSNs
strTmp = fReturnRegKeyValue(HKEY_CURRENT_USER, _
cREG_PATH & "\qc03", "Server")
If strTmp = vbNullString Then Err.Raise cERR_NODSN
'Another ODBC DSN
strTmp = fReturnRegKeyValue(HKEY_CURRENT_USER, _
cREG_PATH & "\PMIP", "Server")
If strTmp = vbNullString Then Err.Raise cERR_NODSN
Those lines of code are checking for the existence of two user DSNs named
qc03 and PMIP. I'd say that the odds of you having DSNs with the same name
are pretty low. <g> You could change the hard coded DSN names, or you could
pass the name of a DSN to the function:
Function fReconnectODBC(DSN_Name As String) As Boolean
and replace that code with
'Check to make sure ODBC DSN is present
strTmp = fReturnRegKeyValue(HKEY_CURRENT_USER, _
cREG_PATH & "\" & DSN_Name, "Server")
If strTmp = vbNullString Then Err.Raise cERR_NODSN
(If you want to refer to System DSNs, as opposed to User DSNs, you also have
to change HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE.)
The reference to Oracle is due to the error message being hard coded as
If Err.Number = cERR_NODSN Then
MsgBox "The User DSN for Oracle Tables were not found. Please " _
& "check ODBC32 under Control Panel.", vbExclamation + vbOKOnly,
_
"Couldn't locate User Data Sources"
You'll probably want to change that.