Hi Doug, thanks for the reply.
This is an application I have deployed successfully in Access2002 and
distributed using the package and deployment wizard included with the Access
2002 Dev. Edition.
Yes, it runs fine on the development machine, including the MDE running with
[ /runtime]. And I have no macros...everything is VBA.
I've run the debugger and compiled the code in Access 2003, so there is no
missing references. I have code in the splash screen form that checks for
links to the backend. If it's not there, then opens a form to browse to the
location and refresh the links.
Any input would be greatly appreciated. I'm due to deliver this tomorrow.
Not that it matters, but the development box is running x64. I noticed that
the versions of the Visual Studio 2005 installed were 64 bit versions.
Pretty cool that it's coded for 64 bit.
And of course, everything is patched current according to Microsoft Update.
Which should go without saying...but you just never know with some people...
You give a lot of information there, but you haven't answered my question!
Can you identify the line of code it's failing on?
Not quite sure what your "compiled the code in Access 2003, so there is no
missing references." is implying: you do realize, I hope, that just because
the references are fine for a given database on machine A doesn't mean
they'll be fine on machine B.

Signature
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)
> Hi Doug, thanks for the reply.
>
[quoted text clipped - 57 lines]
>>> Larry Hodges
>>> Maximize Software
Larry Hodges - 21 Jul 2006 16:51 GMT
> You give a lot of information there, but you haven't answered my question!
> Can you identify the line of code it's failing on?
No, there is no code reference. The text I provided was verbatim.
> Not quite sure what your "compiled the code in Access 2003, so there is no
> missing references." is implying: you do realize, I hope, that just
> because the references are fine for a given database on machine A doesn't
> mean they'll be fine on machine B.
Prior to creating the MDE, open the code window. On the toolbar, select
Debug > Compile. This compiles the VBA code and will tell you if you have
any missing references, which is quite possible when upgrading to a new
version of Access. For example, you may have some ADO code in your project
but be missing the ADO Reference.
Hey, I thought you were the MVP? :p
-Larry
>> Hi Doug, thanks for the reply.
>>
[quoted text clipped - 60 lines]
>>>> Larry Hodges
>>>> Maximize Software
Larry Hodges - 21 Jul 2006 18:42 GMT
> You give a lot of information there, but you haven't answered my question!
> Can you identify the line of code it's failing on?
[quoted text clipped - 3 lines]
> because the references are fine for a given database on machine A doesn't
> mean they'll be fine on machine B.
It was my understanding that the Package and Deployment wizard would analyze
those dependencies and include them with the installation? Calendar Control
for example. Is that not the case anymore with VS2005 tools?
-Larry
<snip>
Douglas J. Steele - 21 Jul 2006 20:49 GMT
>> You give a lot of information there, but you haven't answered my
>> question! Can you identify the line of code it's failing on?
[quoted text clipped - 8 lines]
> Calendar Control for example. Is that not the case anymore with VS2005
> tools?
It wasn't really the case with any version. Yes, if the required DLL or OCX
was missing, it should provide it. However, if it already exists but isn't
the same version, there can be problems. As well, your users can certainly
install other software after installing your application, which can cause
your application to break.
As to my suggestion as to identifying the line of code that's failing, if
your error trapping isn't giving you details of where in the code you are,
you might have to provide a customized version of the application that does
indicate line number.

Signature
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)