From: David W. Fenton on
"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
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
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
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
"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/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: On Click Event
Next: Report based on field criteria