Prev: On Click Event
Next: Report based on field criteria
From: Paul on 13 Feb 2010 15:41 > I set the db to automatically boot users off that > do no actually work with the db for 60min and also the method you are > using. I've found several references on the Web for code that does that. Did you obtain one of those in the public domain, in which case can you recommend one, or did you write it yourself? > I suspect your issue may pertain to a specific pc or 2. Have been able to > identify which user(s) are retaining a lock on the mdb? > Is it always the > same pc(s)? No, but that sounds like a good ided for something I should do. One challenge I see to that is that while the ldb file shows everyone who logs on during a session, it doesn't seem to remove their entry when they log off. So I end up with 20-30 users shown in each ldb file. I've been thinking of adding a table to keep track of who logs on and off and when they do it, so I'll be able to tell who is still on at any time. > Are they up-to-date with both windows and office updates? Presumably, but it's hard to tell if there are exceptions. > 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. > Can you manually delete the ldb file? Or does > the system stop you from deleting it because there is still and active > connection? It won't let me delete it. > Hope this helps, It does. You've given me some new avenues to pursue. Thanks, Daniel.
From: Douglas J. Steele on 13 Feb 2010 17:35 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: David W. Fenton on 13 Feb 2010 18:28 "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 13 Feb 2010 18:28 "Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in news:O6LcoRMrKHA.4752(a)TK2MSFTNGP04.phx.gbl: > The simplest way is to reboot the server. That will force the > handle on the database to be released. Rebooting a server is not a SIMPLE solution. The simplest way to release a file handle is to force close it by going into the computer management control panel and in Shares, finding the open file handle and forcing it closed. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 13 Feb 2010 18:29
=?Utf-8?B?RGFuaWVsIFBpbmVhdWx0?= <DanielPineault(a)discussions.microsoft.com> wrote in news:188AF766-F418-453C-B6FF-DB0580C0C289(a)microsoft.com: > What happens if you reboot while there is a live connection? Will > this possibly risk the integrety of the data? Yes, indeed it can. And it's inconvenient. Before rebooting, force close the open file(s) through Computer Management, as I've explained in two other posts. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |