 |
ashiyr
Level: Protégé
Registered: 05-04-2007
Posts: 5
|
Error in Restore
kindly help with this error. i try to restore my file but i encounter error in
"Set bckupfile = fsys.GetFile(File1.Path & File1.List(File1.ListIndex))"
Here's the error:
Runtime error '53':
File not found
Private Sub chmlRestore_Click()
Dim destination As String
Dim source As String
Dim curdate, curtime As String
Dim restorefile As File
Dim restorepath As File
ProgressBar1.Value = 1
Do
destination = File1.Path & "GRADINGSYS.mdb"
source = App.Path & "\GRADINGSYS.mdb"
Set bckupfile = fsys.GetFile(File1.Path & File1.List(File1.ListIndex))
fsys.CopyFile destination, source, True
fsys.DeleteFile destination
ProgressBar1.Value = ProgressBar1.Value + 1
DoEvents
If ProgressBar1.Value = 100 Then
MsgBox "Restore completed!!!", vbInformation, "Restore"
Exit Sub
End If
Loop Until (ProgressBar1.Value = 100)
ProgressBar1.Value = 0
End Sub
|
|
10-04-2007 at 01:31 PM |
|
|
yronium
Level: Moderator
Registered: 14-04-2002
Posts: 907
|
Re: Error in Restore
quote:
ashiyr wrote:
....
It's horrible!
Regardless to your #53 error (I agree to admin's tip: you probably missed a backslash in path building), you can't go on this way:
- before copying the .mdb you got to be sure nobody's using the database. Yes, in the other post I said that you can barely copy the mdb file to backup it and overwrite it with the old copy to restore it, but you got to check if the database is in use, as you get an error whenever you try to replace an open file. Luckily, you can easily know if the .mdb is open by checking for the correspondant .ldb file existance in the same dir, but this tell you only if the .mdb file is in use by MSAccess, not if something else (an external app, an antiviral scan, a size comparision, etc...) keeps it in use without opening it by Access.
A simple way is trying to rename the file by the Name function: if you get the #75 error this way it means the file is in use, so you can messagebox user for trying later (... didn't I already tell you something like this before?...).
- what is the sense of the Do-Loop you are doing? You start the loop before copying the file, but in fact your progressbar is totally disconnected from the copy operation. Even its speed is not due to any effective cpu work, as each loop starts at once the VB compiler has read the block instructions, and reading speed depends on cpu clock, while copy speed depends on disk speed, fragmentation, buffer, filling percentage, ram amount, more than cpu. It's only an additional task you have given the cpu to do. If you'd mind the performances it'd be better if you even get rid of the loop, and of course the file copy won't be affected at all. And however, your progressbar could take one second or one hundred, depending on the machine it's running on: would you really add to your program something you can't control?
- (the worst of all)If ProgressBar1.Value = 100 Then
MsgBox "Restore completed!!!", vbInformation, "Restore" |
What??... You proudly claim, with three exclamation marks, that the db is successfully restored because the progressbar is finished?? And what about some errors? Or simply, what about the copy is not finished at all? Maybe because it simply took longer? Try executing the copy of a 90 Mb .mdb file (I got one of 96 Mb) and you'll see: the progressbar will finish in two seconds and the copy - though it'd encounter no errors - ten or fifteen seconds later. So, after your glorious msgbox, user tries to do something in the mdb... but he can't, as the copy is still in progress (and he's not blocked to try, as you put a DoEvents in the code), and the risk is even to crash the pc. Mind also that usually we backup old - say, big - databases, not new - say, small - ones: this risk grows while your db grows.
You wouldn't give a good show.
So my question is: have you got an idea of what the code you are using effectively does, and of how it works?
____________________________
Real Programmer can count up to 1024 on his fingers
|
|
10-04-2007 at 03:37 PM |
|
|
|
|
 |
|
Re: Error in Restore
