How Do I Kill A Session

E

EarlCPhillips

Some unknown person has an Access program open, preventing me from installing
new changes. How can I kill their session so I can install something?

EarlCPhillips
Volunteer Ex-Mainframe Programmer
Learning Access To Help Feed the Hungry
Harvesters Food Network
 
E

EarlCPhillips

Further clarification: The split data does not have a .ldb file open but the
split program file DOES have a .ldb file open. I cannot find anyone who is
signed on to the database.

Earl Phillips
Volunteer Ex-mainframer Learning Access
Harvesters Community Food Bank
 
J

John Spencer

Can you just delete the LDB file? If so, it was left over from someone
crashing while using the database or otherwise not normally exiting the
database.

Also, if you are talking about the front end when you say the split program
file, you should have a copy of that on each computer and not on a central
file server.

--
John Spencer
Access MVP 2002-2005, 2007-2008
Center for Health Program Development and Management
University of Maryland Baltimore County
..
 
E

EarlCPhillips

Yes, I am talking about the front end when I refer to the split program. The
Director of Technology, now departed for another job, insisted that the front
end and back end be located on a system drive and that all traffic go across
the network. I tried to convince him otherwise, but I held no sway as a
volunteer.

I tried to delete the .ldb file for the front end and it tells me it is in
use by the Administrator, which is me, but I am not signed on to the .mdb
file and not even to Access. Help please. In the mainframe world the
computer operator had total control and could just force someone off the
system. Do we have to take the network down?

Earl Phillips
 
J

John Spencer

If you can't delete the ldb file, you may have to reboot the server. Once
the server has been rebooted you should be able to delete the ldb file.

Beyond that, good luck.

--
John Spencer
Access MVP 2002-2005, 2007-2008
Center for Health Program Development and Management
University of Maryland Baltimore County
..
 
A

Albert D. Kallal

Help please. In the mainframe world the
computer operator had total control and could just force someone off the
system. Do we have to take the network down?

Yes but you have to find out "who" on that mainframe system...would you not?

You can go into the server admin tools and view/see who has what file(s)
open...I would suggest doing that....

I want to stress EXTREME caution here in simply blowing out users that have
a file open. Remember, if you wring a word document, and you hit the re-set
key, then the changes in ram to that document are lost. With word, this not
such a big deal, however, with ms-access it can blow out the whole database,
and you be going back to yesterdays backup (you have one of
those...right!!!!).

For example, with all those disk frames in the mainframe...if we pull the
plug, then all that data in memory NEVER will get written back to disk.

You have to think of EACH copy of ms-access like a single instance of tat
mainframe (because EACH copy of ms-access has its OWN ram...and if that ram
is compromised due to a re-set...you can damage the file).

Read the following article VERY carefully as to why you can blow out..and
damage your file when you don't shut down each ms-access user correctly.

You can start reading at:
"Why a does JET file share corrupt when the connection breaks?"
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

I just want to give you a conceptual understanding that in a file share,
parts of the file actually reside on EACH pc...and if you compromise the
ability of a pc to write data back...you can not only loose data...but,
damage the mdb file. This is the fundamental difference between using a file
share for the back end, or sql server (client/server) for the back end. In
both setups you can continue to use ms-access as front end...but in some
cases, if you can't ensure reliability connections...you need to move from a
file share to a true client-server setup.
 
E

EarlCPhillips

The organization's system administrator could not delete the .ldb file
either. Ultimately she had to reboot the system. When she did so, the .ldb
file no longer existed and we could do anything we choose to do. I did read
the paper by Albert D. Kallal and it proved quite interesting and
informative. Thank you all for your help in fixing my problem. We now can
get back to feeding the hungry.

EarlCPhillips
Ex-mainframer Learning Access
Harvesters Community Food Network
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top