Bypass Autoexec programmatically?

[Ahliana]

My overall goal is to programmatically import objects (modules and a form) that are called from the autoexec function (that is called from the autoexec macro). Unfortunately, since they are called from the autoexec function, then once these are loaded into memory, you can't bring in new copies, or you get a duplicate definition error.

We send users a database that has just their new objects to update their application, and we need to run code to import these objects and remove the old copies. We also have a security.mdw, as these databases are locked.

I created an external vb app to close the open forms, but I didn't realize that the autoexec function is still running, so it still locks all objects it has loaded in memory. My external vb app calls a macro that just calls a function. The vb app closes all open forms in the main db, and I thought this would unload the autoexec code from memory, but it doesn't, so I'm ending up calling my function with the autoexec code still loaded, so I will still get the duplicate definition error if I try to import the objects.

This app was started before I got here. The autoexec macro does nothing but call a function called AutoExecStart. That function runs all the code. When I look at the call stack, I see that the autoexecstart function is running, it has called my external vb app, which has then called the macro/function I want to run to import the objects. I thought that since the vb app closed forms and then called a macro/function, that the autoexecstart code would not be in the same stack and could therefore be unloaded, but that doesn't seem to be the case. What have I missed? I have DoEvents sprinkled liberally about to try to get things to finish up what they are doing and unload.

Is there a way I can start up access without running the autoexec macro? I could close the app and restart it and work with it if I could get it to not run the autoexec. I have not been able to find a way to programmatically open the db WITH SECURITY and be able to get to the objects, not just data. I can use DAO/ADO if I just wanted data, but I have to open 2 db's (the main one and the update one) and get objects transferred between them. I could open the main db with security, but not get a handle to it and get the objects, unless I run the autoexec which then has loaded the objects I'm trying to replace.

If I could make that any more confusing, I'd have a career in politics!

Helpful suggestions welcome and very much appreciated.


Ahliana
Argue for your limitations and, sure enough, they're yours! - Richard Bach

 

[HitechUser]

Ahliana,

I believe there is no way to bypass the Autoexec macro. Just delete it!

Instead you can create a startup form (hidden) then call your code(let it complete), then open your "Applications main form", then close your hidden form.

You should be able to access objects and data. I have done it from VBA from one MDB to another (not using an external VB application).

Try some of these... Also search this site.

http://www.tek-tips.com/viewthread.cfm?qid=968029

http://www.tek-tips.com/viewthread.cfm?qid=733102

I hope this helps.

Good Luck...

 

[Ahliana]

Thanks very much, I appreciate your time and suggestions.

I am one of a team working on this app, which has been in production for some time. They would not give up the autoexec, even for something as important as this added functionality. The AutoExecStart function drives a large number of things that we couldn't afford to possibly break.

However, I have found that the vb app was calling the function within Access that I wanted so quickly that it was put in the same call stack as the running AutoExecStart. With a sufficient sprinkling of DoEvents, and a loop of DoEvents placed before calling the function, I was able to have the vb app start the function after code within the AutoExecStart made it exit early. Then after importing the new object and deleting the old one, I had to have another DoEvents loop to wait until the metadata tables were updated before I could successfully rename the new object to the old name. If I didn't, it was left in a half-deleted state and duplicate definition errors were generated.

It finally works, and will allow us to update all obejcts (except the module with the function, which can be updated a different way). I wish this thing could be simpler - but then they wouldn't be paying me to work on it, I suppose.

As for accessing objects and data, it's easy from within Access, not easy to do it programmatically from outside, when you have security involved. I scoured many sites, and finally went with Microsoft's recommendation of using GetObject(, "Access.Application") to get a handle to the current instance of Access, which I could then control. It's not completely bulletproof, but should do for what we are doing at the specific times we are doing it.

I read the threads you suggested. In the second, you look at transferring objects. ADO is for data only, not objects themselves, such as forms or modules. Data transfer is easily (ok, at least compared to what I've just been through for this mess) accomplished with ADO. Objects are a different beast.

Thanks again for your help, and if you are interested in hearing more about how I solved it, I'll be glad to share.

Ahliana
Argue for your limitations and, sure enough, they're yours! - Richard Bach

 

[HitechUser]

Ahliana,


My suggestion was to "replace" the Autoexec macro with a startup form that calls your code. Basically same functionality, yet less hassle. See link below.

Also you CAN bypass startup options (which was your original requirement) just not AutoExec.

http://whidbey.msdn.microsoft.com/l...derationssettingoptionsistartupdialogboxs.asp

The link below shows code on how to (via program) allow bypass to occur (or not).

http://www.tek-tips.com/viewthread.cfm?qid=843828

In closing as I stated previously set your startup options to open the form (hidden) the call your code. Once that has completed then open the User's main form and close the hidden one. Now you can decide if you need to override the startup or not.

Hey, just an idea.

 

[DoubleD]

Ahliana,
HighTechUser is right. If you really didn't want to modify the AutoExec macro, all you would need to do is rename it. Have a form open at Startup that calls your macro. Now you can put VBA code before the macro without chancing breaking the macro.

I am what I am based on the decisions I have made.

DoubleD

 

[Ahliana]

Thanks very much for your suggestions. I may suggest that to the team lead, although for now I have managed to solve what I needed. You do have a point, though.

I appreciate your advice.

Ahliana
Argue for your limitations and, sure enough, they're yours! - Richard Bach