Solved Who keeps Access opened ? (1 Viewer)

[TipsyWolf]

hey guys,
i have my db.accdb in network where many ppl use this db.
Now i need to update this file and i need to remove it from network and then put updated file back. BUT !
there is laccdb temp file which is created when someone runs access. But prob. someone opened access and forget about it, but i need him to close it and i have no idea which PC is using this db.

is there a way to find out through this laccdb ? like bsod viewer or something ... is there a laccdb viewer ? lol

 

[Gasman]

Have you looked in the file?
Open it with Notepad.

I hope it is split and you are not sharing the FE or the unsplit DB?

 

[TipsyWolf]

Have you looked in the file?
Open it with Notepad.

I hope it is split and you are not sharing the FE or the unsplit DB?

i couldn't believe it might be so simple !!

thank you very much, Gasman !

 

[TipsyWolf]

Have you looked in the file?
Open it with Notepad.

I hope it is split and you are not sharing the FE or the unsplit DB?

whats FE ?

i haven't slip my db. any benefits of doing it ?

 

[TipsyWolf]

oh... prob. so it is updatable even if someone opens a db , correct ?

 

[TipsyWolf]

im new at access, so i've never split db before. prob. need to go ahead and try
who ever new noobies will read this topic i suggest to watch this youtube video

 

[Gasman]

DB need to be split. That splits data from code.
The BE (Back end/data) exists somewhere where everyone can get to it.
The FE (Front End/code) exists on each users PC. They get their *OWN* copy, they DO NOT share a FE.

The only time I would not split, when it is just for me. Like my Diabetes DB. It is just for me, so I have not split it.

 

[TipsyWolf]

DB need to be split. That splits data from code.
The BE (Back end/data) exists somewhere where everyone can get to it.
The FE (Front End/code) exists on each users PC. They get their *OWN* copy, they DO NOT share a FE.

The only time I would not split, when it is just for me. Like my Diabetes DB. It is just for me, so I have not split it.

well explained !
thank you very much Gasman for helping noobies like me to explore access.

 

[gemma-the-husky]

You can see who has the file open by looking in the computer admin for users who have a session open to the access database or locking file. If they can't close the database, there should be a way to kill the session. Failing that restart the pc, then delete the locking file.

I may have the wrong system terminology above. You can look at the locking file with notepad, but it's not really that helpful.

 

[TipsyWolf]

Have you looked in the file?
Open it with Notepad.

I hope it is split and you are not sharing the FE or the unsplit DB?

i found this PC (IT helped me) and i closed db. then i waited like 1-2 hours - its still in session. then i restarted that PC - and even after restart its still shows that this PC is using db... damn.. i wasn't expect that ...
maybe it needs some cooldown ?

 

[Gasman]

i found this PC (IT helped me) and i closed db. then i waited like 1-2 hours - its still in session. then i restarted that PC - and even after restart its still shows that this PC is using db... damn.. i wasn't expect that ...
maybe it needs some cooldown ?

Perhaps that is what Dave meant by 'but it's not really that helpful'
I had a logged in flag, so I could see who was still logged in, and the ability to clear the entry, if their computer crashed etc.

 

[GPGeorge]

No, once the accdb is closed, it should release the laccdb immediately. This probably means that someone--perhaps you-- still has the accdb open. Make sure ALL users, including yourself, close the accdb. Then, if the laccdb does not get deleted, do so yourself.

 

[gemma-the-husky]

i found this PC (IT helped me) and i closed db. then i waited like 1-2 hours - its still in session. then i restarted that PC - and even after restart its still shows that this PC is using db... damn.. i wasn't expect that ...
maybe it needs some cooldown ?

It's not the pc that's the issue. The server has a connection to the shared database designated as pc1. Pc1 has to explicitly release the connection I think, and just restarting pc1 won't do that. You can use the windows administrator on the server to force close any active session. You can also restart the server which will terminate any sessions, and then manually delete the .accde file.

The database developer may not have administrator rights on the server though.

If you try to delete the .accde file (not the accdb file) when it is actually in use, windows won't let you. Try it and see.

Eg. If you have to force close a database on pc1 with task manager, that won't terminate the session on the server. (Or restart the pc,case you gave tried)

That's what I meant, and the .accde file on the server doesn't explain what it contains. I'm pretty sure MS never explained what the records actually contain in the .accde file, so it's all conjecture.

 

[The_Doc_Man]

When you split a database, the data-side is the Back End and there is where you need to check for the lock file to see which connections are still active. They will be readable and will (usually) tell you the IP address of the culprit. To help with this, I had a user history table in which I stored a record of each user's startup, to include the date/time, username, and PC's IP address. I archived that table once a month or so, but having that list made it possible for me to look up the IP address found in the .LACCDB or .LDB file to see who was still "in."

If your DB is secured well enough, you can even build a table of "who's in now" if you have a "lurking" dispatcher or switchboard form that removes an entry when you exercise its application shutdown function.

oh... prob. so it is updatable even if someone opens a db , correct ?

As long as you never stepped into any of the queries or forms to make them use pessimistic locking, every update either doesn't lock at all or merely does a lock, update, unlock in very rapid succession, and the locks by default are for specific areas within the DB, further minimizing the odds of a "collision." If you ever get a "record locked" error, you just had a lock collision - two people acting on the same piece of the back end at the same time. That should be a very rare occurrence.