Prev: On Click Event
Next: Report based on field criteria
From: David W. Fenton on 13 Feb 2010 18:30 "Paul" <BegoneSpam(a)forever.com> wrote in news:#oNbvtOrKHA.4492(a)TK2MSFTNGP05.phx.gbl: > I suspected that might be the case. However, I also suspect that > out network administrators only reboot on weekends, but I will > have to check with them. You don't need to reboot. An administrator can force close open file handles via the Computer Management console in Control Panel. I've explained it in two other posts. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Daniel Pineault on 13 Feb 2010 19:20 I too have that exact scenario, where a pc appear to close access, but the process msaccess.exe remain active. I have determined, I think, that it is because the pc is out of date and is missing numerous updates. Out of my hands though. So I created a script that kills the process using simple vbs. Not the ideal situation, but until the IT dept. fixes the situation, it will have to do. -- Hope this helps, Daniel Pineault http://www.cardaconsultants.com/ For Access Tips and Examples: http://www.devhut.net Please rate this post using the vote buttons if it was helpful. "David W. Fenton" wrote: > "Paul" <BegoneSpam(a)forever.com> wrote in > news:#1PGmzOrKHA.3536(a)TK2MSFTNGP06.phx.gbl: > > >> When you say that the ldb remains, is it actually in use or was a > >> connection improperly closed? > > > > I don't know how to determine that. > > On the server, in the Control Panel, go to Administrative Tools and > open the Computer Management control panel. Under SHARED FOLDERS > click on OPEN FILES. That will show you what files are open and who > has them open (though if multiple users have the same file open, I'm > not sure if it's listed multiple times or if the last user is the > only one listed as having it open). > > I would suggest that you might want to check if Access is closing > down successfully on all PCs. I just picked up a new client who has > one workstation where when you close Access the MSACCESS.EXE > executable continues running and has to be force closed in Task > Manager. If that's the case on any of the PCs in your situation, > that would mean that the lock on the LDB file might not be closed. > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ > . >
From: Paul on 14 Feb 2010 04:59 You're right, Doug. In my situation, nothing is being written because no one is in the office. "Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in message news:O5i%23LzPrKHA.3408(a)TK2MSFTNGP06.phx.gbl... > Well, it all depends on whether something's actually being written at the > time of reboot. > > From Paul's description, it sounds as though that may not be the case. > > However, you're right that I should have advised caution. > > -- > Doug Steele, Microsoft Access MVP > http://I.Am/DougSteele > (no e-mails, please!) > > > > "Daniel Pineault" <DanielPineault(a)discussions.microsoft.com> wrote in > message news:188AF766-F418-453C-B6FF-DB0580C0C289(a)microsoft.com... >> Douglas, >> >> What happens if you reboot while there is a live connection? Will this >> possibly risk the integrety of the data? >> -- >> Hope this helps, >> >> Daniel Pineault >> http://www.cardaconsultants.com/ >> For Access Tips and Examples: http://www.devhut.net >> Please rate this post using the vote buttons if it was helpful. >> >> >> >> "Douglas J. Steele" wrote: >> >>> The simplest way is to reboot the server. That will force the handle on >>> the >>> database to be released. >>> >>> -- >>> Doug Steele, Microsoft Access MVP >>> http://I.Am/DougSteele >>> (no private e-mails, please) >>> >>> >>> "Paul" <begone(a)spam.com> wrote in message >>> news:ubkPkEMrKHA.4752(a)TK2MSFTNGP04.phx.gbl... >>> > Is there any way to unlock a back end database file? >>> > >>> > I understand that one answer is to get all the users that are linked >>> > to it >>> > to close down. However, we're tried that and the file will sometimes >>> > remain locked for a few days. >>> > >>> > We're using Access 2003 in a multi-user environment, and every night >>> > we >>> > import data from other databases, then compact and repair the back end >>> > mdb >>> > file. To ensure that all the users close down their front end file at >>> > the >>> > end of every day, I have a timer event in a hidden form that checks >>> > the >>> > name of a file on the network server every 30 minutes. If the >>> > extension >>> > of that file name is "yes", it closes down. If it's "no", it does >>> > nothing. >>> > >>> > This works great 99% of the time. All the user front ends close down, >>> > the >>> > ldb file disappears and the back end file can be compacted and >>> > repaired. >>> > However, every couple of months, this technique doesn't succeed, and >>> > the >>> > back end remains locked for several days, during which time we can't >>> > compact and repair it, (because it won't run the compact and repair >>> > operation while it's locked). Thus far the locking never lasts for >>> > more >>> > than a few days, after which it will mysteriously unlock itself, and >>> > we >>> > can resume normal maintenance operations. >>> > >>> > My biggest concern is that it may reach the point where it never >>> > unlocks, >>> > and just keeps getting larger over time. I've noticed that even while >>> > it's locked I can copy the back end file to another folder (and copy >>> > and >>> > repair the new copy), but I can't delete or copy over the locked file. >>> > It would be great if there were some way to force it to unlock, so we >>> > could compact and repair it every night. Alternatively, if there were >>> > a >>> > way to delete or copy over the file, then we could replace it with the >>> > copy that was compacted and repaired in another folder. >>> > >>> > Is there any way to solve this problem of the back end mdb file that >>> > remains locked? >>> > >>> > Thanks in advance, >>> > >>> > Paul >>> > >>> > >>> > >>> >>> >>> . >>> >
From: Paul on 14 Feb 2010 05:11 Good information, David. I can't wait to try it out when our network admins are back in harness, because I don't have direct access to the server console. Three questions: > On the server, in the Control Panel, go to Administrative Tools and > open the Computer Management control panel. Under SHARED FOLDERS > click on OPEN FILES. Am I right in thinking that can only be done on the server's monitor, and not from my workstation which is only connected to the server through the Windows XP OS? > one workstation where when you close Access the MSACCESS.EXE > executable continues running and has to be force closed in Task > Manager. Would that be Task Manager in that particular client workstation (C drive)? And finally, elsewhere you said > An administrator can force close open file > handles via the Computer Management console in Control Panel. Don't laugh, but what are open file handles? Would that be the front end mdb file running on the client's computer? Thanks Paul "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9D1EBBF22E915f99a49ed1d0c49c5bbb2(a)74.209.136.89... > "Paul" <BegoneSpam(a)forever.com> wrote in > news:#1PGmzOrKHA.3536(a)TK2MSFTNGP06.phx.gbl: > >>> When you say that the ldb remains, is it actually in use or was a >>> connection improperly closed? >> >> I don't know how to determine that. > > On the server, in the Control Panel, go to Administrative Tools and > open the Computer Management control panel. Under SHARED FOLDERS > click on OPEN FILES. That will show you what files are open and who > has them open (though if multiple users have the same file open, I'm > not sure if it's listed multiple times or if the last user is the > only one listed as having it open). > > I would suggest that you might want to check if Access is closing > down successfully on all PCs. I just picked up a new client who has > one workstation where when you close Access the MSACCESS.EXE > executable continues running and has to be force closed in Task > Manager. If that's the case on any of the PCs in your situation, > that would mean that the lock on the LDB file might not be closed. > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 14 Feb 2010 13:58
"Paul" <begone(a)spam.com> wrote in news:eLj4V4VrKHA.4220(a)TK2MSFTNGP05.phx.gbl: >> On the server, in the Control Panel, go to Administrative Tools >> and open the Computer Management control panel. Under SHARED >> FOLDERS click on OPEN FILES. > > Am I right in thinking that can only be done on the server's > monitor, and not from my workstation which is only connected to > the server through the Windows XP OS? If the remote registry editing service is on, it can be done from any machine that has network access to the server. You just open the Computer Management console and right click on the top-level node of the tree and choose CONNECT TO ANOTHER COMPUTER. This will give you the same view as if you were logged onto the server console. It does require the same level of administrative access. >> one workstation where when you close Access the MSACCESS.EXE >> executable continues running and has to be force closed in Task >> Manager. > > Would that be Task Manager in that particular client workstation > (C drive)? Yes. I don't know that it's possible to remotely kill a process at all (not sure what the parenthetical C drive reference is about, though). > And finally, elsewhere you said > >> An administrator can force close open file >> handles via the Computer Management console in Control Panel. > > Don't laugh, but what are open file handles? Would that be the > front end mdb file running on the client's computer? The open file handles are what is causing the problem. When an application uses a file it opens it, and it is so marked by the file system. Have you ever tried to clean out your TEMP folder and been told that files were in use? That's because the files are being held open (either read or write) by some process on your computer. It's really very similar to record locking in a database. If you want to see this on your own computer, download and run Process Explorer, which is Task Manager on steroids. After you've done that, go to your TEMP folder and find a file that can't be deleted. Then in Process Explorer, search for the file name in the FIND menu. Once it's been located in the running processes/resources tree, you can force close that file handle if you like (though it's usually not advisable unless you know something has gone wrong). More properly, once you've identified what process has it open, you can close the app in question and that will release the lock on the file. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |