By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,659 Members | 1,957 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,659 IT Pros & Developers. It's quick & easy.

Kill file, how to find out it it's available yet?

P: n/a
On each workstation there's a front end, when the front end opens it checks
a 'version number' held in a table of properties against the version number
in a copy of the front end held on the server. If it's the same it opens
normally. If not it shells out to an UpdateClient.mdb and quits. The
UpdateClient.mdb overwrites the FE on the workstation with the one on the
server. But I was getting an access error (70, I think). Presuming that the
FE hadn't actually closed fully when UpdateClient.mdb was trying to
overwrite it I did this:

Dim intTime As Single
350 intTime = Timer
360 Do While Timer < intTime + 10
370 DoEvents
380 Loop

390 Kill sLocalClientPath

400 FileCopy sNetworkClientPath, sLocalClientPath

It works fine, but is there a more elegant way? 10 seconds should be enough,
but most of the time will be too long, leaving the users sat at their
machines, and sometime might be too long.

I thought about trapping for error 70 and trying again, but then thought
that if there really is a 'genuine' access error, like the FE won't close or
something, then there will be an endless loop.

TIA, Mike MacSween
Nov 12 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Try michka's TSOON utility (Trigeminal Shut-One, Open-Next) from:
www.trigeminal.com

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@pubnews.gradwell.ne t...
On each workstation there's a front end, when the front end opens it checks a 'version number' held in a table of properties against the version number in a copy of the front end held on the server. If it's the same it opens
normally. If not it shells out to an UpdateClient.mdb and quits. The
UpdateClient.mdb overwrites the FE on the workstation with the one on the
server. But I was getting an access error (70, I think). Presuming that the FE hadn't actually closed fully when UpdateClient.mdb was trying to
overwrite it I did this:

Dim intTime As Single
350 intTime = Timer
360 Do While Timer < intTime + 10
370 DoEvents
380 Loop

390 Kill sLocalClientPath

400 FileCopy sNetworkClientPath, sLocalClientPath

It works fine, but is there a more elegant way? 10 seconds should be enough, but most of the time will be too long, leaving the users sat at their
machines, and sometime might be too long.

I thought about trapping for error 70 and trying again, but then thought
that if there really is a 'genuine' access error, like the FE won't close or something, then there will be an endless loop.

TIA, Mike MacSween

Nov 12 '05 #2

P: n/a
"Allen Browne" <al*********@SeeSig.invalid> wrote in message
news:Si*********************@news-server.bigpond.net.au...
Try michka's TSOON utility (Trigeminal Shut-One, Open-Next) from:
www.trigeminal.com


Yes, thanks Allen. I actually tried that, and Tony's FE updater too, but
couldn't get either of them to work. Thanks to both of those for providing
those, but in the end I thought I'd just do it myself. A bit of a 'learn
through experience' approach.

I do actually like the idea of doing this completely in Access too. I know
msaccess.exe will be on the machines, so there's no need to think about
whether the VB run time is there, or registering dlls.

Of course there's no reason to think that anything I write will be any
better than either of those (quite the opposite, in fact!), but as both of
them are unsupported (I think) I didn't want to hassle the writers.

Cheers, Mike
Nov 12 '05 #3

P: n/a
Check to see whether the LDB file exists.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@pubnews.gradwell.ne t...
On each workstation there's a front end, when the front end opens it checks a 'version number' held in a table of properties against the version number in a copy of the front end held on the server. If it's the same it opens
normally. If not it shells out to an UpdateClient.mdb and quits. The
UpdateClient.mdb overwrites the FE on the workstation with the one on the
server. But I was getting an access error (70, I think). Presuming that the FE hadn't actually closed fully when UpdateClient.mdb was trying to
overwrite it I did this:

Dim intTime As Single
350 intTime = Timer
360 Do While Timer < intTime + 10
370 DoEvents
380 Loop

390 Kill sLocalClientPath

400 FileCopy sNetworkClientPath, sLocalClientPath

It works fine, but is there a more elegant way? 10 seconds should be enough, but most of the time will be too long, leaving the users sat at their
machines, and sometime might be too long.

I thought about trapping for error 70 and trying again, but then thought
that if there really is a 'genuine' access error, like the FE won't close or something, then there will be an endless loop.

TIA, Mike MacSween

Nov 12 '05 #4

P: n/a
"Mike MacSween" <mi******************@btinternet.com> wrote in
news:3f***********************@pubnews.gradwell.ne t:
On each workstation there's a front end, when the front end
opens it checks a 'version number' held in a table of
properties against the version number in a copy of the front
end held on the server. If it's the same it opens normally. If
not it shells out to an UpdateClient.mdb and quits. The
UpdateClient.mdb overwrites the FE on the workstation with the
one on the server. But I was getting an access error (70, I
think). Presuming that the FE hadn't actually closed fully
when UpdateClient.mdb was trying to overwrite it I did this:

Dim intTime As Single
350 intTime = Timer
360 Do While Timer < intTime + 10
370 DoEvents
380 Loop

390 Kill sLocalClientPath

400 FileCopy sNetworkClientPath, sLocalClientPath

It works fine, but is there a more elegant way? 10 seconds
should be enough, but most of the time will be too long,
leaving the users sat at their machines, and sometime might be
too long.

I thought about trapping for error 70 and trying again, but
then thought that if there really is a 'genuine' access error,
like the FE won't close or something, then there will be an
endless loop.

TIA, Mike MacSween
I use error trapping within a loop with a counter

Dim iRetries as integer
iRetries = 0
390 Kill sLocalClientPath

On Error goto HandleMyError70
400 FileCopy sNetworkClientPath, sLocalClientPath
On Error goto GenericErrorHandler

HandleMyError70:
if .errNo = 70 then
iRetries = iRetries+1
intTime = timer
do while Timer <intTime+ 100 ' 100 ms
DoEvents
loop
If iRetries >99 '10 seconds + a litle
MessageBox "TimeOut Error"
'bail out however you want.
else
Resume 're-execute the line where error occurred
end if
end if

Bob Q
Nov 12 '05 #5

P: n/a
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:nq********************@news02.bloor.is.net.ca ble.rogers.com...
Check to see whether the LDB file exists.


Yes, that's a thought. As a matter of fact I seem to have a problem (?) with
the back end of this app where the ldb file is being left open, after all
the users are out. It seems to be happening consistently now since I... ah!
I've just changed permissions on the back end folder. To read write only, I
think. Would that do that? Do I need read write and modify?

Cheers, Mike
Nov 12 '05 #6

P: n/a
Thanks Bob. Yes, I was thinking something along those lines myself. I'll
give it a go.

Only awkward thing is I've written this superb updater (!) to update the FE
from the server. Unfortunately this code is in the actual updating mdb,
which can't be updated remotely. Doh!

Mike

"Bob Quintal" <bq******@generation.net> wrote in message
news:db******************************@news.teranew s.com...
"Mike MacSween" <mi******************@btinternet.com> wrote in
news:3f***********************@pubnews.gradwell.ne t:
On each workstation there's a front end, when the front end
opens it checks a 'version number' held in a table of
properties against the version number in a copy of the front
end held on the server. If it's the same it opens normally. If
not it shells out to an UpdateClient.mdb and quits. The
UpdateClient.mdb overwrites the FE on the workstation with the
one on the server. But I was getting an access error (70, I
think). Presuming that the FE hadn't actually closed fully
when UpdateClient.mdb was trying to overwrite it I did this:

Dim intTime As Single
350 intTime = Timer
360 Do While Timer < intTime + 10
370 DoEvents
380 Loop

390 Kill sLocalClientPath

400 FileCopy sNetworkClientPath, sLocalClientPath

It works fine, but is there a more elegant way? 10 seconds
should be enough, but most of the time will be too long,
leaving the users sat at their machines, and sometime might be
too long.

I thought about trapping for error 70 and trying again, but
then thought that if there really is a 'genuine' access error,
like the FE won't close or something, then there will be an
endless loop.

TIA, Mike MacSween


I use error trapping within a loop with a counter

Dim iRetries as integer
iRetries = 0
390 Kill sLocalClientPath

On Error goto HandleMyError70
400 FileCopy sNetworkClientPath, sLocalClientPath
On Error goto GenericErrorHandler

HandleMyError70:
if .errNo = 70 then
iRetries = iRetries+1
intTime = timer
do while Timer <intTime+ 100 ' 100 ms
DoEvents
loop
If iRetries >99 '10 seconds + a litle
MessageBox "TimeOut Error"
'bail out however you want.
else
Resume 're-execute the line where error occurred
end if
end if

Bob Q

Nov 12 '05 #7

P: n/a
"Mike MacSween" <mi******************@btinternet.com> wrote:
Tony's FE updater too, but
couldn't get either of them to work.


What was the problem?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 12 '05 #8

P: n/a
"Tony Toews" <tt****@telusplanet.net> wrote in message
news:qa********************************@4ax.com...
"Mike MacSween" <mi******************@btinternet.com> wrote:
Tony's FE updater too, but
couldn't get either of them to work.


It's a bit late, but as far as I can remember lot's of 'file not found' type
messages. To tell the truth I was having trouble understanding what went
where. I'll have another go when I've got time and post if I have problems.

Cheers, Mike MacSween
Nov 12 '05 #9

P: n/a

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@pubnews.gradwell.ne t...
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:nq********************@news02.bloor.is.net.ca ble.rogers.com...
Check to see whether the LDB file exists.
Yes, that's a thought. As a matter of fact I seem to have a problem (?)

with the back end of this app where the ldb file is being left open, after all
the users are out. It seems to be happening consistently now since I... ah! I've just changed permissions on the back end folder. To read write only, I think. Would that do that? Do I need read write and modify?


Your users need Change (RWXD) on the folder where the MDB exists. The last
user to log out of the database needs to be able to delete the LDB.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)


Nov 12 '05 #10

P: n/a
I have a slightly different way to do this. It attempts to lock the
file for writing (the key line is "Open filename For Binary Lock Read
As #tmp"). If it can't open the file for writing, it will pop up a
messagebox.
'copy is too awful to attempt to claim
'feel free to copy, modify, and claim it's your own
Private Sub waitForSourceFileToClose(filename As String)
On Error GoTo sub_Error
Dim startTime As Date
Dim tmp As Long
Dim finished As Boolean
startTime = Now()

tmp = FreeFile
finished = False

Do While finished = False
finished = True
Open filename For Binary Lock Read As #tmp
Close #tmp

If finished = False And DateDiff("s", startTime, Now()) >= 15
Then
If MsgBox("Waiting for file '" & filename & "' to close.
" & _
"Wait another 15 seconds for it to free up? (check and
ensure all other " & _
"Access databases are closed at this time)", vbYesNo,
"Cannot Open File") = vbYes Then

startTime = Now()
Else
Err.Raise vbObjectError + 1, "Update Procedure", _
"The source MDB file is not available for copying at
this time. Filename: " & filename
End If
End If
Loop

sub_Exit:
Exit Sub

sub_Error:
If Err.Number = 70 Then
finished = False
Resume Next
Else
MsgBox Err.Number & " " & Err.Description
Resume sub_Exit
End If
End Sub
Nov 12 '05 #11

P: n/a
"Mike MacSween" <mi******************@btinternet.com> wrote:
>Tony's FE updater too, but
>couldn't get either of them to work.


It's a bit late, but as far as I can remember lot's of 'file not found' type
messages. To tell the truth I was having trouble understanding what went
where. I'll have another go when I've got time and post if I have problems.


There is one parameter in the INI file which, in hindsight, really doesn't make a lot
of sense. I will be renaming that one and splitting it up as soon as I possibly can.
As well as adding a forms based wizard.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 12 '05 #12

P: n/a
"Tony Toews" <tt****@telusplanet.net> wrote in message
news:88********************************@4ax.com...
"Mike MacSween" <mi******************@btinternet.com> wrote:
>Tony's FE updater too, but
>couldn't get either of them to work.
It's a bit late, but as far as I can remember lot's of 'file not found' typemessages. To tell the truth I was having trouble understanding what went
where. I'll have another go when I've got time and post if I have

problems.
There is one parameter in the INI file which, in hindsight, really doesn't make a lot of sense. I will be renaming that one and splitting it up as soon as I possibly can. As well as adding a forms based wizard.


That would be great. I'm sure it's good, but brains here couldn't work out
how to make it work.

Cheers, Mike
Nov 12 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.