msaccess.exe process does not terminate on closing Access

Where is your app installed on the Vista box? If you dropped it in Program Files, you may be running into UAC issues. Try running it in the My Documents folder and see what happens.

By "app" I assume you mean the .mdb file (or .mde file) that I am running. These are always stored in another drive, either on the local machine or on a shared folder on a NAS device.

If you mean the Access.exe application, then this is in "C:\Program Files\Office 2000" or "C:\Program Files\Office 2003" as appropriate, i.e. as close to the MS default as possible.

Let me know which you are referring to; if it's the latter I can try and re-install it in my equivalent of the "My Documents" folder.

I am assuming that if I had simply installed Access 2003 and avoided Access 2000 altogether, the problem would not have occurred - after all there must be 000's of such Vista / Access 2003 implementations which work just fine.

There is no problem in running the application initially, and sometimes when it is terminated by closing a form which runs a "DoCmd.Quit" function, it seems to close the msaccess.exe process OK. But if I have the database window open and I simply use the Close option from the menu bar, then this is usually when the problem occurs.

The issue may be solved by installing office 2000 service pack 3 if you have not done that yet.

you can download office 2000 service pack 3 from the following URL:

http://www.microsoft.com/downloads/details.aspx?FamilyID=5C011C70-47D0-4306-9FA4-8E92D36332FE&displaylang=EN

I've followed your advice and installed all of the main SRs (1A, 2, 3) for Office 2000, but unfortunately it hasn't cured the underlying problem.

The location would be relevant to your database, not the msacess.exe file. Your database must be installed to a read/write directory, and the Program Files directory on a Vista box is not.

You mention that these are stored "off machine" ... this is not a recommended setup, unless you're referring to the Backend of a split application. You should install a FE to each machine as needed, and run that local copy. This could be causing your issue ...

My normal practice is to store both the front end and back end components on the D: drive of my local machine (a partition on my single hard disk) whilst I am doing development work. [Obviously when these apps are distributed to clients, the components are stored on a shared server, with the front end downloaded to the user's PC just before execution.] So I don't think this is the cause of the problem.

I need to know, though, whether under Vista, the msaccess.exe process should disappear from the processes list in Task Manager when Access is closed (note that the Microsoft Access application disppears from the Applications tab, it is only on the Processes tab that it "gets left behind"). Under XP, the process does disappear on closure (but perhaps not if the app crashes - I'm afraid I haven't been able to test this), so I would be surprised if it were different under Vista.

So I am still left with the problem that I sometimes have to delete all extant versions of msaccess.exe from the process list before I can run any more instances of Access, and this can't be right. This is currently without Access 2003 even being installed.

"I need to know, though, whether under Vista, the msaccess.exe process should disappear from the processes list in Task Manager when Access is closed"

Yes.  In any OS, that should happen ... under normal operation.  But when a crash occurs, it probably will remain in the background.

mx

I also have another problem with this setup. I usually use a different workgroup for my development activities from the default System.mdw. Under XP OS if you initiate an Access session (whether or not you hold down the Shift key) the dialogue box for confirming the userid and password is displayed until the OK button is pressed. Under Vista, this does not seem to be the case - the Shift key must be held down ehwn starting up Access in order to cause the dialogue box to remain on screen; if you don't do this it is briefly displayed and then disappears again, meaning that you cannot halt the execution of the Autoexec macro on startup.

Any ideas on why this happens?

DatabaseMX

Thanks for the confirmation. Any thoughts on the underlying problem. Maybe I'm the only Access developer who is actually trying to run the 2000 version under Vista, and that's why no-one else has experienced these issues....

To continue my response to DatabaseMX, I am assuming that what is happening is that Access is not in fact terminating properly, and it leaves part of the app running, hence not clearing out msaccess.exe from memory....

Scott is probably the best help here. I'm not running Vista. I really don't know why this is happening in your case, but ... I feel your pain.

mx

I had a case a while back ...wherein an Error 9 occurred just prior to closing (a long story). User would click OK ... and app (not Access.exe) would close ... and all looked well. But .. Access.exe was still a process.  Subsequent attempts to open the database - like in your case - did nothing ... until the process was killed in Task Manager.  

mx

How about the usual stuff:

Compact and Repair

Does the app Compile ok?

Have you  done a Decompile.  I will paste in my Decompile routine if you need it ?

mx

Hi MX

Thanks for the feedback and support! This happens with all of my apps, but they all work fine on my other laptop (XP OS and Access 2000, but also with Access 2002 installed), which for the above reasons is the one that I use as my prime development machine. The apps all get compacted and repaired between each release (of which there have been many over the past 18 months). The problems only occur if I copy the app onto the Vista laptop and try to work on it from there.

I've noticed that if I don't run any code the app seems to close fine - it's only after running the Autoexec macro that the problem occurs - all my apps use similar start processes so maybe there's some VBA code that Vista doesn't like.

What is also concerning me is the problem with my workgroup assignment. As a security measure, I use a special workgroup for development, which has full rights to view, edit and save the components of the DB, whereas the default workgroup (System.mdw) does not have these permissions. I do not use a password for the Developer user in this workgroup. Normally when you start Access, it will open the dialogue box for the workgroup user and wait until you have provided a password and click the OK button. If you hold the Shift key down at this point it will not run the Autoexec macro. However, on the Vista machine, although the dialogue box is displayed, it seems to think I've pressed the OK button and carries on without halting (since my password is blank, it thinks I've typed in the correct one). I also get this problem if I try to look at the References in the VB editor window. This is similarly protected with a password, but Access again assumes I've entered one; in this case there is actually a password it then claims I've typed in the wrong (blank) one and waits for me to type in the right one. This absolutely does not happen on the XP machine, which behaves as you would expect and waits for me to hit the enter key before proceeding. This is really weird. Any thoughts?

For the record, I found a couple of newsgroup postings where the comment was made that Vista supports ONLY 2002 and up. In those same threads, several other users, some of them MVPs, reported that Access 2000 ran fine on their Vista box. I'd think that MS's comment had more to do with their SUPPORT of Access 2000 on Vista - that is, you can run it, but if you have troubles we won't provide assistance.

The other issues you mention - the dialog box that flashes onscreen, the missing Shift key bypass, etc etc - all lead to a faulty installation of Access at some level. The security measures provided by ULS are derived from both the database and the workgroup file; if you have the correct workgroup file on the machine, and reference it properly when opening the app (i.e. you've either Joined the workgroup file, or you've built a Shortcut where you are using the /wrkgrp switch), you should ALWAYS get the dialog box (unless your shortcut also provides the User and Pwd arguments).

When you use the Close menuitem, what forms are running? Can you pinpoint that the issue recurs with specific objects opened? That is, can you determine if this happens when frmA and frmB are open, but not if frmC and frmD are open when you shut down the app? If you manually close all forms, then close the app, does the problem recur?

Have you tried importing all your objects to a new, blank database?

Have you tried moving the db to a read/write folder on the Vista laptop? The User Documents folder is generally R/W.

Unfortunately, like many other mature software products, Access is dependent on many underlying utilities and libraries. You may have something on the Vista laptop that's hosed which is causing this. You can try a full uninstall/reinstall of all Office products to see if that solves your issue.

Hi LSM

I've been doing some further digging, partly on my own and partly in conjunction with Microsoft Technical Support. I have discovered that the problem arises when running MS Access 2000 and a form is loaded, at which point the memory consumed by Access rises steadily in 100/200Kb increments over time. And when the app is closed, the msaccess.exe process remains in memory, and ultimately prevents Access from loading again. Bizarrely, once the prpblem has occurred, it happens even on loading the standard Northwind database (which displays a simple menu form on startup).

I have sent a cutdown version of the app (which exhibits the problem on my PC) to MS Tech Support but they can't reproduce the problem on their own Vista / Access 2000 setup. They suggested restarting my machine with no additional services running (via msconfig) but this has no effect - I still get the problem. They are going to escalate the problem within Microsoft so if I get any solution I'll pass this on (in the unlikely event of anyone else expereincing the same problem).

wow.  Good luck with MS tech support.

mx