Access 2007 Runtime Issues

[John Glassco]

I've run into an issue packaging the Access 2007 runtime and a database
program using the ADE.

I'm working with a full version of Access 2007 SP1 under Windows Vista on
the development PC. The database itself is in the 2007 format, converted
from a 2000 format database. The test PC that will be running the runtime is
using Windows XP with no version of Office on it. (And all the computers
that will eventually be using this program are also XP with no Office.)

I create the package with the runtime (version 2) and install the package to
the test PC. However when I open the database program, it opens Access and
immediately displays a standard error of 'Microsoft Office Access has
encountered a problem and needs to close. We are sorry for the
inconvenience.' Then it has the option of repairing and restarting Access
with the Send/Don't Send buttons at the bottom. If I have it repair and
restart, it does the exact same thing again. This occurs on all the
computers on which we've used the runtime with our program.

This message doesn't come up in the full version of Access, as we have
several users currently using the program with the full version of Access.
On these computers, the program performs just as it should.

Has anyone experienced anything similar? And if not, is there any way at
all to troubleshoot this problem?

 

[Jeanette Cunningham]

Hi John
I have experience with using runtime, just not A2007.
I may be just telling you something you already know, if so, please forgive
me.

From experience, if you do not have error handling on every single routine
in your database, you can easily get the message about access needing to
close.
The first thing I would check is your error handling.


Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia

 

[John Glassco]

Hi Jeanette

Thanks for the response. We have one set of error handling code that we use
pretty universally. The error handler pretty much retries the main code five
times. If it fails all five times, it logs the error number and description
to a table in our backend and shows a custom error message.

All the functions and subs that are executed up to and including the ones
attached to our switchboard use this error handling code. Yet it doesn't
display the custom error messages, and it doesn't log any errors to the
table. All it gives is that standard Windows error message.

 

[John Glassco]

Okay, I think I've figured out the major problem with this. This is just
speculation, but it seems like the most likely culprit. It looks like my
references may be looking for files that "don't exist" on the client
computer. They're on the computer, just not in the right directories.

My development machine is Vista 64, so all the references are in C:\Program
Files (x86)\[etc]. The client machine is XP 32, so it has all the same files
in C:\Program Files\[etc]. If I change this on my development machine to
\Program Files\, it automatically changes it back to \Program Files (x86)\.

Is there a way around this, short of manually creating the \Program Files
(x86)\ directory on the client and copying over all the libraries? That
would be inconvenient to say the least, since we have to put this program on
a fair number of PCs.

 

[Chris O'C via AccessMonster.com]

Developers who develop on the same platforms with the same software versions
as their customers avoid many incompatibility probs.

The default library references should be found by your app without
difficulties, even if it's installed on a different os with different paths.
Code objects in other libraries should use late binding so the os uses the
registry to find the path to those registered libraries.

Chris
Microsoft MVP

Okay, I think I've figured out the major problem with this. This is just
speculation, but it seems like the most likely culprit. It looks like my
references may be looking for files that "don't exist" on the client
computer. They're on the computer, just not in the right directories.

My development machine is Vista 64, so all the references are in C:\Program
Files (x86)\[etc]. The client machine is XP 32, so it has all the same files
in C:\Program Files\[etc]. If I change this on my development machine to
\Program Files\, it automatically changes it back to \Program Files (x86)\.

Is there a way around this, short of manually creating the \Program Files
(x86)\ directory on the client and copying over all the libraries? That
would be inconvenient to say the least, since we have to put this program on
a fair number of PCs.

 

[John Glassco]

Well, we have machines running Vista and XP with 32 and 64 bit versions of
both. And I'm not entirely sure which of these wouldn't be considered
'default', but I'll look into the late binding option and see if that fixes
the problem. Thanks.

Developers who develop on the same platforms with the same software versions
as their customers avoid many incompatibility probs.

The default library references should be found by your app without
difficulties, even if it's installed on a different os with different paths.
Code objects in other libraries should use late binding so the os uses the
registry to find the path to those registered libraries.

Chris
Microsoft MVP

Okay, I think I've figured out the major problem with this. This is just
speculation, but it seems like the most likely culprit. It looks like my
references may be looking for files that "don't exist" on the client
computer. They're on the computer, just not in the right directories.

My development machine is Vista 64, so all the references are in C:\Program
Files (x86)\[etc]. The client machine is XP 32, so it has all the same files
in C:\Program Files\[etc]. If I change this on my development machine to
\Program Files\, it automatically changes it back to \Program Files (x86)\.

Is there a way around this, short of manually creating the \Program Files
(x86)\ directory on the client and copying over all the libraries? That
would be inconvenient to say the least, since we have to put this program on
a fair number of PCs.