I could not find this specific problem in any other discussions.

I have multiple databases, all of which have startup routines (I'm using the word "routine" loosely to refer to all the code that is supposed to run and forms that are supposed to open upon opening the database file). Some of the databases make use of an AutoExec macro, others load a hidden form at startup and code runs on the OnOpen event. For my purposes these two methods work equally well.

When a user (including me) opens one of the databases, everything works as expected, provided there are no other databases already open. If there is another database already open, the startup routine fails to run. I have experimented with the files enough to determine that, when another database is already open, neither the AutoExec macro is running nor is the startup form being opened.

Clearly my databases are interfering with each other on some level. Are there some sort of global parameters to MS Access itself that could be causing this problem?

(An FYI in case it's relevant: although I am using Access 2007, the databases themselves are in earlier file formats. My preference is to avoid changing this arrangement as that would most likely introduce other problems more irritating than the current topic).

Welcome to UtterAccess.

The problem you describe simply doesn't add up. Nothing in a standard installation would account for that behavior. All Access mdb/accdbs are stand-alone files. They simply don't interact unless you deliberately add code to them to do that. For example, you can link to tables in one accdb/mdb from another. Or, you can use code to manipulate an mdb/accdb file from a different file.

So, let's get some more detail.

Are all of these databases separate, standalone and NOT linked in anyway, such as having linked tables?
Are all of these databases independent in the sense that they are used for different purposes?
Do these databases reside in a single, common folder on one computer?
Has this problem been there all along, or is it a recent problem? Did things work correctly, and then stop working correctly?
Did this correspond to any change in your network?
Did you add or change anything in one or more of the databases recently?

Again, this is so far out of the expected that we really need to look carefully at the environment where these accdb/mdbs are running to understand what could be happening. The more details you can provice, the better.

This post has been edited by GroverParkGeorge: Apr 17 2012, 12:43 PM

"So far out of the expected." I like that.

Thank you for your response. Of course, after weeks of on-and-off trying to figure this out, I discover a solution shortly after posting the problem. I think you probably nudged me in the right direction by confirming that the two files wouldn't be interfering. Since you indicated that was impossible (or at least very improbable), I decided to take one more really close look through the code, operating under the far more likely premise that I did something wrong. Turns out I did, but it wasn't what I thought it would be.

Users launch the database by running a batch file, which fetches a copy of the most up-to-date version of the Front-End file from a network location, copies it to their local machine, and then opens it. Since I am constantly making revisions, I need a way to force the users to take this step (there are those who would continue to use the local copy, either by directly accessing the file or using the "recent documents" list in Access). The method by which I force users to use my batch file is as follows: the first function to run in the databases upon opening is some code designed to check the file attributes to ensure that the user is not trying to open an out-of-date version of the front-end file. If they are, it tells them to run the batch file and closes Access. If not, the startup routine continues normally.

One important bit here is that the last thing the batch file does is delete a temporary file used in the file attribute comparison. As I look at it now, I realize that this was poor design, as the temp file can potentially be deleted before it is needed. Since the error only seems to be occurring when there are multiple databases open, I have to conclude that this somehow slows down the code execution to the point where the file is indeed being deleted prior to when it is called in the vba code (whereas with no other databases open, the vba code executes just fast enough to read the file attributes before the temp file is deleted. This is just a guess... I don't know whether the notion that the code may be running more slowly is a valid one).

However, assuming that my idea is correct, then the missing file was causing an error in the version-checker function, of which I was unaware, because I didn't bother to build in an error handler. Let that be a lesson to me I guess. The undetected error was causing the whole process to just stop.

The solution was to remove the delete command from the batch file and replace it with a Kill statement at the very end of my startup routine (well after it has served its purpose). After doing this, the problem disappeared. I suspect that my methodology for testing the file attributes could use improvement, but I am not very adept at getting Access to interact with other software or the OS.

One additional question that arose out of all this. In the case of a database that has both an AutoExec macro and a Startup form with code set to run OnOpen, which of those two occurs first?

Congratulations on solving your problem. The solutions we come up with ourselves are always the most satisfying. And learning from the process is something of a bonus, as well.

I believe that the AutoExec macro will run before anything else.

Hi,

(IMG:style_emoticons/default/welcome2UA.gif)

I haven't seen your code but I suspect that it's not the slowness of the process but if you're using the same temporary file, then I suppose that the other database files are deleting it when the other database file is looking for it.

As for the question on which one fires up first, it depends:

1. If your database is stored in a Trusted Location, the Form event will fire first before the macro.

2. If your database is not stored in a Trusted Location, the Autoexec macro will fire, and the Form event will only fire after you enable the code (but the macro will fire again).

Just my 2 cents... (IMG:style_emoticons/default/2cents.gif)

Interesting. We confirmed this tonight at our user group meeting. Events on the Start-up form fire before the Autoexec macro. Three of us said the reverse, but testing confirmed it is this way. Thanks, DB. I got a chance to learn something new again today.

Thanks George.

And speaking of User Groups, I am scheduled to present at a local group next month. So, I will be raiding your group's site for some "inspiration" on how to create the slide decks. The topic will be about "UtterAccess."

Cheers (IMG:style_emoticons/default/cheers.gif)

Have a great time. We also learned last night that our Access meeting outdrew the local .net user group meeting recently. Most interesting.