|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
OT: Can cause VB6 an error of this kind?corrupt a file so that Windows gives the error "Access denied. In use by another person or program, etc" when you try to either copy, rename move or delete it. I had a user who experienced this problem when using my application. The file in question was a MS Access database, placed in Documents & Settings\Application data\AppName\DB (softcoded). The problem occured when I programmatically tried to compact the file, I could see it from the log file when I drove to the customer. I first thought that we file might still be locked, but there was no ldb when I went to the directory in which the file was. I rebooted, but nothing changed. I could not rename, remove or copy the file. But when I told Windows to correct/ repair the drive on the next restart, the file was GONE. Windows deleted it on his own. Can somebody tell me what might have been going on and if it could have been my fault? I experienced the Murphy law before, but this made my alarm bells ring... I am deeply scared now. Thank you for a reply, Tim "Tim Pauly" <t.pa***@gmx.net> wrote in message Sounds like a messed up HD. Compact and Repair does re-write the file tonews:Oj6tgnnqJHA.4116@TK2MSFTNGP04.phx.gbl... > > But when I told Windows to correct/ repair the drive on the next > restart, the file was GONE. > Windows deleted it on his own. > > Can somebody tell me what might have been going on and if it could have > been my fault? > disk. If the HD is a bad state - anything is possible. In any case, I doubt very much there is anything your program is doing to cause this problem. Or just as important anything you can do to prevent this from happening again. Advise the customer on the importance of performing periodic maintenance and clean-up of his system. Make sure the customer is doing frequent back-ups. Also (as you are likely already aware) users seldom report everything that has been going on with their system. Ralph wrote:
Show quoteHide quote > "Tim Pauly" <t.pa***@gmx.net> wrote in message One possible cause of such a symptom is a power failure during the > news:Oj6tgnnqJHA.4116@TK2MSFTNGP04.phx.gbl... >> But when I told Windows to correct/ repair the drive on the next >> restart, the file was GONE. >> Windows deleted it on his own. >> >> Can somebody tell me what might have been going on and if it could have >> been my fault? >> > > Sounds like a messed up HD. Compact and Repair does re-write the file to > disk. If the HD is a bad state - anything is possible. > > In any case, I doubt very much there is anything your program is doing to > cause this problem. Or just as important anything you can do to prevent this > from happening again. Advise the customer on the importance of performing > periodic maintenance and clean-up of his system. Make sure the customer is > doing frequent back-ups. > > Also (as you are likely already aware) users seldom report everything that > has been going on with their system. process. Again, not programmatic. Whether there's a software problem is indeterminate at this point--it's always possible somewhere deep in the bowels of the compaction routine there's a bug but that isn't the question I think you're asking. At the VB level of interaction I'd say "no"--although again it's always possible to have a coding error it's very unlikely that VB code itself did the damage. Now if you're mucking around w/ the disk/file attributes at a very low level... -- And what would you say about the following?
I first backup the database before compacting it to have a "last good" database in case of a failure. I copy it bitwise, but I don't think that could be the "low level" as dpb was talking of. In my copy routine I always try to create the path first. For example when the destination is "C:\foo1\foo2\foo3", I try to create the directories C:\ C:\foo1 C:\foo1\foo2 C:\foo1\foo2\foo3 by this routine: Public Function CreateDirectory(ByVal uString As String) If Len(uString) = 0 Then Debug.Assert False ElseIf Right(uString, 1) <> "\" Then uString = uString & "\" End If Dim sTemp$ sTemp = uString Dim lPos& lPos = 0 On Error Resume Next ' This is a must because folders may be locked and there is no easy way to determine if they are locked Do lPos = InStr(lPos + 1, sTemp, "\", vbBinaryCompare) If lPos > 0 Then Dim sDir$ sDir = Mid(sTemp, 1, lPos) MkDir sDir Else Exit Do End If Loop End Function Could that be a risk?? On error resume next is a problem in most cases. You should handle the error
for you don't know what they error is and it may not write the file. Check the error to see if it is an expected error like "Dir already exists" for if your app attempts to create a folder and for some reason other than it already exists you are then screwed and your file will not be created. Did you step thr the code to make sure everything happens just as it should? -- Show quoteHide quoteRandem Systems Your Installation Specialist The Top Inno Setup Script Generator http://www.randem.com/innoscript.html Disk Read Error Press Ctl+Alt+Del to Restart http://www.randem.com/discus/messages/9402/9406.html?1236319938 "Tim Pauly" <t.pa***@gmx.net> wrote in message news:upXS2FyqJHA.3964@TK2MSFTNGP05.phx.gbl... > > And what would you say about the following? > I first backup the database before compacting it to have a "last good" > database in case of a failure. > I copy it bitwise, but I don't think that could be the "low level" as dpb > was talking of. > In my copy routine I always try to create the path first. For example when > the destination is "C:\foo1\foo2\foo3", I try to create the directories > > C:\ > C:\foo1 > C:\foo1\foo2 > C:\foo1\foo2\foo3 > > by this routine: > > Public Function CreateDirectory(ByVal uString As String) > > If Len(uString) = 0 Then > Debug.Assert False > ElseIf Right(uString, 1) <> "\" Then > uString = uString & "\" > End If > > Dim sTemp$ > sTemp = uString > > Dim lPos& > lPos = 0 > > On Error Resume Next ' This is a must because folders may be locked > and there is no easy way to determine if they are locked > > Do > lPos = InStr(lPos + 1, sTemp, "\", vbBinaryCompare) > If lPos > 0 Then > Dim sDir$ > sDir = Mid(sTemp, 1, lPos) > MkDir sDir > Else > Exit Do > End If > Loop > > End Function > > Could that be a risk?? > Tim,
> I first thought that we file might still be locked, but there was no ldb That only means that it is not locked by the Jet DB Engine. It can still be locked by the operating system, typically due to a hung application or one that did not shut down gracefully. > But when I told Windows to correct/ repair the drive on the next restart, Probably not... This is typical of a "pending delete" i.e. you have ask for > the file was GONE. Windows deleted it on his own. a file to be deleted, Windows has tried and failed due to a lock so waits until the file is freed. Next time, try a tool like "WhoLockMe" to see what actually has the file open. How big is the database file? If it is more than 50% of the RAM on the computer a copy operation can appear to hang while the data is flushed to disk (something about this creating huge numbers of page faults and slowing down the task). "Tim Pauly" <t.pa***@gmx.net> a écrit dans le message de news: Oj6tgnnqJHA.4***@TK2MSFTNGP04.phx.gbl...Show quoteHide quote >I would like to ask if you have ever experienced that VB6 was able to >corrupt a file so that Windows gives the error "Access denied. In use by >another person or program, etc" when you try to either copy, rename move or >delete it. > > I had a user who experienced this problem when using my application. The > file in question was a MS Access database, placed in Documents & > Settings\Application data\AppName\DB (softcoded). > > The problem occured when I programmatically tried to compact the file, I > could see it from the log file when I drove to the customer. > > I first thought that we file might still be locked, but there was no ldb > when I went to the directory in which the file was. > I rebooted, but nothing changed. I could not rename, remove or copy the > file. > > But when I told Windows to correct/ repair the drive on the next restart, > the file was GONE. > Windows deleted it on his own. > > Can somebody tell me what might have been going on and if it could have > been my fault? > > I experienced the Murphy law before, but this made my alarm bells ring... > I am deeply scared now. > > Thank you for a reply, > Tim I have experienced this. Only a reboot will fix the problem.
Show quoteHide quote "Clive Lumb" <clumb2@gratuit_en_anglais.fr.invalid> wrote in message news:OTbOUG5qJHA.1240@TK2MSFTNGP02.phx.gbl... > Tim, > >> I first thought that we file might still be locked, but there was no ldb > That only means that it is not locked by the Jet DB Engine. It can still > be locked by the operating system, typically due to a hung application or > one that did not shut down gracefully. > >> But when I told Windows to correct/ repair the drive on the next >> restart, the file was GONE. Windows deleted it on his own. > Probably not... This is typical of a "pending delete" i.e. you have ask > for a file to be deleted, Windows has tried and failed due to a lock so > waits until the file is freed. > > Next time, try a tool like "WhoLockMe" to see what actually has the file > open. > > How big is the database file? If it is more than 50% of the RAM on the > computer a copy operation can appear to hang while the data is flushed to > disk (something about this creating huge numbers of page faults and > slowing down the task). > > > > > "Tim Pauly" <t.pa***@gmx.net> a écrit dans le message de news: > Oj6tgnnqJHA.4***@TK2MSFTNGP04.phx.gbl... >>I would like to ask if you have ever experienced that VB6 was able to >>corrupt a file so that Windows gives the error "Access denied. In use by >>another person or program, etc" when you try to either copy, rename move >>or delete it. >> >> I had a user who experienced this problem when using my application. The >> file in question was a MS Access database, placed in Documents & >> Settings\Application data\AppName\DB (softcoded). >> >> The problem occured when I programmatically tried to compact the file, I >> could see it from the log file when I drove to the customer. >> >> I first thought that we file might still be locked, but there was no ldb >> when I went to the directory in which the file was. >> I rebooted, but nothing changed. I could not rename, remove or copy the >> file. >> >> But when I told Windows to correct/ repair the drive on the next restart, >> the file was GONE. >> Windows deleted it on his own. >> >> Can somebody tell me what might have been going on and if it could have >> been my fault? >> >> I experienced the Murphy law before, but this made my alarm bells ring... >> I am deeply scared now. >> >> Thank you for a reply, >> Tim > > |
|||||||||||||||||||||||
Other interesting topics