|
|
We have a split multi-user DB, BE on server, FE on each user's PC. (Access
2003 running on Windows XP.) From time to time we have to pull a copy of the
BE off-line, tinker with it, then write it back to the server. We have a
timer event built into the FE so we can throw everybody out by creating a
trigger file on the server; the FE "pulses" the server every 10 seconds or
so, and if it finds the trigger it notifies all active users, then shuts them
down and won't let them back in until we remove the trigger file.
The last couple times we did this, though, we couldn't push the modified BE
because the BE on the server was showing as still in use by somebody. We had
to work around it be renaming our modified BE and resetting the FE links.
Can't understand for the life of me how that could be, since our triggered
eject process doesn't negotiate, just throws them out and locks them out of
logging back in until we remove the trigger file.
Anybody have any ideas what's going on here? We're all scratching our heads
trying to figure it out.
|
|
> work around it be renaming our modified BE and
> resetting the FE links.
Nothing wrong with that, you should re-link after
tinkering around with the BE, but next time, get
a network admin to look at the server and tell you
which user still has the BE locked, and to
disconnect any users.
If you are old enough, you may remember "never
turn your PC off at the power, always shut down"
You don't have to tell users that now, because
turning the power off is no longer the usual way
of shutting down a PC. That advice was for users
who used a client-server networked file system...
If the client exits abnormally without a proper
shut down, the server doesn't know.
This can happen without user intervention if the
power to the workstation goes off, or if there
is a network bug or failure.
Delayed shut down can also happen because of
network optimisations: servers always keep files
open and cached for a little while in case the
client wants to use them again.
Delayed shut down can also happen because of
client bugs, the client looses track and forgets
to notify the server. Servers normally automatically
shut connections a little while after the client
disconnects - the server keeps track and checks
on a schedule for orphaned connections - so you
can normally fix this without involving network
IT just by getting the users to turn off their
computers for 15-20 minutes (do your users turn
off their computers at night or just leave them
running?)
Clients like Access try to close all connections
before shutting, but refusing to close is also
a bug, so for network connections applications
always just quit after notification - if the
notification has failed, it's too late.
Look first for user ignorance, then for network
failures, then see if there is any sequence of
actions in your application that cause the problem.
(david)
LarryP wrote:
[Quoted Text] > We have a split multi-user DB, BE on server, FE on each user's PC. (Access
> 2003 running on Windows XP.) From time to time we have to pull a copy of the
> BE off-line, tinker with it, then write it back to the server. We have a
> timer event built into the FE so we can throw everybody out by creating a
> trigger file on the server; the FE "pulses" the server every 10 seconds or
> so, and if it finds the trigger it notifies all active users, then shuts them
> down and won't let them back in until we remove the trigger file.
>
> The last couple times we did this, though, we couldn't push the modified BE
> because the BE on the server was showing as still in use by somebody. We had
> to work around it be renaming our modified BE and resetting the FE links.
> Can't understand for the life of me how that could be, since our triggered
> eject process doesn't negotiate, just throws them out and locks them out of
> logging back in until we remove the trigger file.
>
> Anybody have any ideas what's going on here? We're all scratching our heads
> trying to figure it out.
|
|
"LarryP" <LarryP[ at ]discussions.microsoft.com> wrote in message
news:5D61CBA0-3FDF-4571-AC32-790876871749[ at ]microsoft.com...
[Quoted Text] > We have a split multi-user DB, BE on server, FE on each user's PC.
> (Access
> 2003 running on Windows XP.) From time to time we have to pull a copy of
> the
> BE off-line, tinker with it, then write it back to the server. We have a
> timer event built into the FE so we can throw everybody out by creating a
> trigger file on the server; the FE "pulses" the server every 10 seconds or
> so, and if it finds the trigger it notifies all active users, then shuts
> them
> down and won't let them back in until we remove the trigger file.
>
> The last couple times we did this, though, we couldn't push the modified
> BE
> because the BE on the server was showing as still in use by somebody. We
> had
> to work around it be renaming our modified BE and resetting the FE links.
> Can't understand for the life of me how that could be, since our triggered
> eject process doesn't negotiate, just throws them out and locks them out
> of
> logging back in until we remove the trigger file.
>
> Anybody have any ideas what's going on here? We're all scratching our
> heads
> trying to figure it out.
Instead of using a "trigger file" why not use a table? Your timer event can
check the contents of that table for a certain value and then take
appropriate action. That way you can target a time (all users), a specific
PC or a specific user. Here's an example which works reliably for me (note
"fOSUserName()" is a function available here
http://www.mvps.org/access/api/api0008.htm).
Keith.
www.keithwilby.com
On Error Resume Next
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim dtmTimeOut As Date
Dim varType As Variant
Dim varValue As Variant
Set db = CurrentDb()
Set rs = db.OpenRecordset("qtblShutdown")
Do While Not rs.EOF
varValue = rs!Value
If Not IsNull(varValue) Then
Select Case rs!Type
Case "User"
If varValue = fOSUserName() Then
DoCmd.OpenForm "fdlgShutdown", , , , , acDialog
mfTimedOut = True
DoCmd.Close acForm, Me.Name
End If
Case "Computer":
If varValue = fOSMachineName Then
DoCmd.OpenForm "fdlgShutdown", , , , , acDialog
mfTimedOut = True
DoCmd.Close acForm, Me.Name
End If
Case "Time"
dtmTimeOut = varValue
If mdtmTime < dtmTimeOut And Time > dtmTimeOut Then
DoCmd.OpenForm "fdlgShutdown", , , , , acDialog
mfTimedOut = True
DoCmd.Close acForm, Me.Name
End If
End Select
End If
rs.MoveNext
Loop
End If
|
|
Thanks, gives me a better grasp of the whole subject of shutdowns.
"DAVID" wrote:
[Quoted Text] > > work around it be renaming our modified BE and
> > resetting the FE links.
>
> Nothing wrong with that, you should re-link after
> tinkering around with the BE, but next time, get
> a network admin to look at the server and tell you
> which user still has the BE locked, and to
> disconnect any users.
>
> If you are old enough, you may remember "never
> turn your PC off at the power, always shut down"
> You don't have to tell users that now, because
> turning the power off is no longer the usual way
> of shutting down a PC. That advice was for users
> who used a client-server networked file system...
> If the client exits abnormally without a proper
> shut down, the server doesn't know.
>
> This can happen without user intervention if the
> power to the workstation goes off, or if there
> is a network bug or failure.
>
> Delayed shut down can also happen because of
> network optimisations: servers always keep files
> open and cached for a little while in case the
> client wants to use them again.
>
> Delayed shut down can also happen because of
> client bugs, the client looses track and forgets
> to notify the server. Servers normally automatically
> shut connections a little while after the client
> disconnects - the server keeps track and checks
> on a schedule for orphaned connections - so you
> can normally fix this without involving network
> IT just by getting the users to turn off their
> computers for 15-20 minutes (do your users turn
> off their computers at night or just leave them
> running?)
>
> Clients like Access try to close all connections
> before shutting, but refusing to close is also
> a bug, so for network connections applications
> always just quit after notification - if the
> notification has failed, it's too late.
>
> Look first for user ignorance, then for network
> failures, then see if there is any sequence of
> actions in your application that cause the problem.
>
> (david)
>
> LarryP wrote:
> > We have a split multi-user DB, BE on server, FE on each user's PC. (Access
> > 2003 running on Windows XP.) From time to time we have to pull a copy of the
> > BE off-line, tinker with it, then write it back to the server. We have a
> > timer event built into the FE so we can throw everybody out by creating a
> > trigger file on the server; the FE "pulses" the server every 10 seconds or
> > so, and if it finds the trigger it notifies all active users, then shuts them
> > down and won't let them back in until we remove the trigger file.
> >
> > The last couple times we did this, though, we couldn't push the modified BE
> > because the BE on the server was showing as still in use by somebody. We had
> > to work around it be renaming our modified BE and resetting the FE links.
> > Can't understand for the life of me how that could be, since our triggered
> > eject process doesn't negotiate, just throws them out and locks them out of
> > logging back in until we remove the trigger file.
> >
> > Anybody have any ideas what's going on here? We're all scratching our heads
> > trying to figure it out.
>
|
|
Thanks, may try that in some form.
"Keith Wilby" wrote:
[Quoted Text] > "LarryP" <LarryP[ at ]discussions.microsoft.com> wrote in message > news:5D61CBA0-3FDF-4571-AC32-790876871749[ at ]microsoft.com... > > We have a split multi-user DB, BE on server, FE on each user's PC. > > (Access > > 2003 running on Windows XP.) From time to time we have to pull a copy of > > the > > BE off-line, tinker with it, then write it back to the server. We have a > > timer event built into the FE so we can throw everybody out by creating a > > trigger file on the server; the FE "pulses" the server every 10 seconds or > > so, and if it finds the trigger it notifies all active users, then shuts > > them > > down and won't let them back in until we remove the trigger file. > > > > The last couple times we did this, though, we couldn't push the modified > > BE > > because the BE on the server was showing as still in use by somebody. We > > had > > to work around it be renaming our modified BE and resetting the FE links. > > Can't understand for the life of me how that could be, since our triggered > > eject process doesn't negotiate, just throws them out and locks them out > > of > > logging back in until we remove the trigger file. > > > > Anybody have any ideas what's going on here? We're all scratching our > > heads > > trying to figure it out. > > Instead of using a "trigger file" why not use a table? Your timer event can > check the contents of that table for a certain value and then take > appropriate action. That way you can target a time (all users), a specific > PC or a specific user. Here's an example which works reliably for me (note > "fOSUserName()" is a function available here > http://www.mvps.org/access/api/api0008.htm).> > Keith. > www.keithwilby.com > > On Error Resume Next > Dim db As DAO.Database > Dim rs As DAO.Recordset > Dim dtmTimeOut As Date > Dim varType As Variant > Dim varValue As Variant > > Set db = CurrentDb() > Set rs = db.OpenRecordset("qtblShutdown") > Do While Not rs.EOF > varValue = rs!Value > If Not IsNull(varValue) Then > Select Case rs!Type > Case "User" > If varValue = fOSUserName() Then > DoCmd.OpenForm "fdlgShutdown", , , , , acDialog > mfTimedOut = True > DoCmd.Close acForm, Me.Name > End If > Case "Computer": > If varValue = fOSMachineName Then > DoCmd.OpenForm "fdlgShutdown", , , , , acDialog > mfTimedOut = True > DoCmd.Close acForm, Me.Name > End If > Case "Time" > dtmTimeOut = varValue > If mdtmTime < dtmTimeOut And Time > dtmTimeOut Then > DoCmd.OpenForm "fdlgShutdown", , , , , acDialog > mfTimedOut = True > DoCmd.Close acForm, Me.Name > End If > End Select > End If > rs.MoveNext > Loop > > End If > > > |
|
|