Autoexec error on Access 2003 runtime program run on Windows 2000 sp3 computer
I installed my Access 2003 program using the Runtime package wizard onto three computers. It works fine on the two Windows XP computers but not on the Windows 2000sp3 computer. I get the following error when the autoexec macro runs:
Action Failed
Macro Name: AutoExec
Condition: True
Action Name: RunCode
Arguments: autoexec()
The autoexec macro calls my autoexec function. The called procedure, LinkTables, relinks the tables in the backend database. Here's the function:
Function AutoExec()
On Error GoTo AutoExecErr
'Take care of startup duties.
On Error GoTo AutoExecErr
AutoExec = True
Call LinkTables
DoCmd.OpenForm ("frmStartup")
AutoExecDone:
On Error Resume Next
DoCmd.Hourglass False
On Error GoTo 0
Exit Function
AutoExecErr:
Select Case Err
Case Else
MsgBox "Module AutoExec, Error#" & Err.Number & ": " & Err.Description, _
vbOKOnly + vbCritical, "AutoExec"
End Select
Resume AutoExecDone
End Function
Action Failed
Macro Name: AutoExec
Condition: True
Action Name: RunCode
Arguments: autoexec()
The autoexec macro calls my autoexec function. The called procedure, LinkTables, relinks the tables in the backend database. Here's the function:
Function AutoExec()
On Error GoTo AutoExecErr
'Take care of startup duties.
On Error GoTo AutoExecErr
AutoExec = True
Call LinkTables
DoCmd.OpenForm ("frmStartup")
AutoExecDone:
On Error Resume Next
DoCmd.Hourglass False
On Error GoTo 0
Exit Function
AutoExecErr:
Select Case Err
Case Else
MsgBox "Module AutoExec, Error#" & Err.Number & ": " & Err.Description, _
vbOKOnly + vbCritical, "AutoExec"
End Select
Resume AutoExecDone
End Function
jefftwilley
Are you able to debug the code as it runs?
ASKER
It's the runtime version of Access that is being used, so the VBA environment is not available.
All my procedures have error-trapping code. The macro error is the only error that appears.
If I had a Windows 2000 computer with Office 2003 on it, I would run the program using the full version of Access to try to debug it.
All my procedures have error-trapping code. The macro error is the only error that appears.
If I had a Windows 2000 computer with Office 2003 on it, I would run the program using the full version of Access to try to debug it.
My suggestion to begin with is to make sure all mapping is the same. If that proves unfruitful, it looks like it never makes it to your error check. The error looks like it's the macro itself that's reporting the error.
ASKER
What do you mean by "mapping?"
Although I cannot set breakpoints, etc., I suppose I could add a message box right after "Call LinkTables."
I am wondering whether I should do away with the autoexec and just move Call LinkTables to frmStartup (which is unbounded) and make frmStartup my startup form. What do you think?
Although I cannot set breakpoints, etc., I suppose I could add a message box right after "Call LinkTables."
I am wondering whether I should do away with the autoexec and just move Call LinkTables to frmStartup (which is unbounded) and make frmStartup my startup form. What do you think?
mapping - I'm referring to mapped network drives. Depending on where your back end is located, it may simply not be able to get to it. But the same applies. If this is a .mde that you're running though, it is sometimes flaky when it comes to reporting proper errors. It seems like something besides the linking is wrong though, because again..the error is being reported by the macro, and not your error handler.
Have you tried to open the database while holding down the Shift key? This should bypass your Databases Setup and take you straight to the database window.
J
Have you tried to open the database while holding down the Shift key? This should bypass your Databases Setup and take you straight to the database window.
J
ASKER
When the program is first used on another computer, the path for the linked database is, indeed, invalid for the new computer. The LinkTables procedure deals with that by checking to see if the link is valid. If it is not, then the user is asked to navigate to a valid backend database file. This all works fine using the full version of Access 2003--and using the runtime version on some computers.
The shift key does not bypass the macro when the runtime version is used. In addition, the runtime version does not support the database window.
The shift key does not bypass the macro when the runtime version is used. In addition, the runtime version does not support the database window.
I'm just guessing here but I'm sure it has to do with your Windows 2000 environment. The dll's are kept in a different directory location. Since you can't use the VBA window, you wouldn't be able to see if there are any missing references. There are miles of discussion about this topic here on EE. I work in a mixed environment as well, where we have all manner of OS and Windows versions. I am forced to compile my database apps in the lowest possible scenario. I do not know how this might apply to you though, as you're using a runtime wizard. I still do not believe it's even gettting to run your code, it's failing at the macro call to the code.
J
J
ASKER
Thanks. I only program in VBA-Access, and I rarely create a runtime installation. So, I have not really had to deal with problems related to differing Windows environments. As long as the user had the current Windows and Office service packs, things have worked fine so far.
I suppose my best next step would be to install Office 2003 on the offending computer. Then I can use the full version of Access, use the debugging environment, check for missing references, etc. If the problem occurs with both the full and runtime versions of Access 2003, then I should be able to find it. If the problem, however, is limited to the runtime version, I might be out of luck.
I suppose my best next step would be to install Office 2003 on the offending computer. Then I can use the full version of Access, use the debugging environment, check for missing references, etc. If the problem occurs with both the full and runtime versions of Access 2003, then I should be able to find it. If the problem, however, is limited to the runtime version, I might be out of luck.
ASKER
I found the problem, but not the cure.
I found a computer with Win2000sp4 and Office 2003. I opened my Access program using the full version of Access 2003. It hit an error when it found a Missing reference: "Microsoft ADO Ext. 2.5 for DDL and Security." When I selected this reference, it worked.
My computer, the one that created the Access program, has version 2.8 of this reference. So, I assume that the program was looking for version 2.8 when it ran on the Win2000 computer but could not find it.
My computer does not have version 2.5--only version 2.8--of the reference. I think that's because I also installed the SQL Server desktop engine on my computer.
Do you think things will work if I put version 2.8 on my computer and set that as the reference? If so, how do I put version 2.5 on my computer without messing things up? Both versions have the same filename:
C:\Program Files\Common Files\System\ado\msadox.dl
If all else fails, I can replace the code that uses the reference with DAO code. I am seriously thinking of doing that anyway--because the offending piece of ADO code is not working properly (relinking a linked database which has a database password). I rewrote some DAO code in ADO.
I found a computer with Win2000sp4 and Office 2003. I opened my Access program using the full version of Access 2003. It hit an error when it found a Missing reference: "Microsoft ADO Ext. 2.5 for DDL and Security." When I selected this reference, it worked.
My computer, the one that created the Access program, has version 2.8 of this reference. So, I assume that the program was looking for version 2.8 when it ran on the Win2000 computer but could not find it.
My computer does not have version 2.5--only version 2.8--of the reference. I think that's because I also installed the SQL Server desktop engine on my computer.
Do you think things will work if I put version 2.8 on my computer and set that as the reference? If so, how do I put version 2.5 on my computer without messing things up? Both versions have the same filename:
C:\Program Files\Common Files\System\ado\msadox.dl
If all else fails, I can replace the code that uses the reference with DAO code. I am seriously thinking of doing that anyway--because the offending piece of ADO code is not working properly (relinking a linked database which has a database password). I rewrote some DAO code in ADO.
ASKER
Correction.
I meant to ask, in the fourth paragraph: "Do you think things will work if I put version 2.5 on my computer ..."
I meant to ask, in the fourth paragraph: "Do you think things will work if I put version 2.5 on my computer ..."
Hey Gordon,
You might try the other way around actually. If you're able to compile the program on the 2000 machine, then try running it on the higher version computers.
There's a very good chance it will work for all environments. Compiling in the lowest, has been the only proven method I've found to run different environments. You can play upward, but you can't play downward.
J
You might try the other way around actually. If you're able to compile the program on the 2000 machine, then try running it on the higher version computers.
There's a very good chance it will work for all environments. Compiling in the lowest, has been the only proven method I've found to run different environments. You can play upward, but you can't play downward.
J
ASKER
Thanks, but I don't have another developers version of Access I can put on the Win2000 machine. I think I might have found a workaround, though. I do have a Win2000 computer with the full version (of Access 2003). I copied the database to the Win2000 machine. I opened it using full Access. It quickly halts due to a reference error. Then I fix the broken references interactively. I save the changes and exit the database.
I do the regular install on a third Win2000 computer. I replace the program database with the one I fixed on the other Win2000 machine. I have not tried this but iI think it should work.
By the way, I think the problem occurs only when I try to install the runtime version on computers that already have some version of the two offending ADOX libraries. The DLL files already exist (albeit the wrong version), so the installation program does not replace them.
I also wrote some code I found on the MS website that tries to fix broken references, but it did not work:
http://support.microsoft.com/kb/194374/en-us
I do the regular install on a third Win2000 computer. I replace the program database with the one I fixed on the other Win2000 machine. I have not tried this but iI think it should work.
By the way, I think the problem occurs only when I try to install the runtime version on computers that already have some version of the two offending ADOX libraries. The DLL files already exist (albeit the wrong version), so the installation program does not replace them.
I also wrote some code I found on the MS website that tries to fix broken references, but it did not work:
http://support.microsoft.com/kb/194374/en-us
ASKER
I ended up rewriting my ADOX code in DAO. Thus, the offending program library (i.e., ADOX) is no longer needed. This now works on at least one Win2000 computer. I suspect it will work on the others as well.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.