VB6 Strange Error 70
Can anyone explain why I am sometimes getting "error 70 bad file name or number" with the following code?
FileNum = FreeFile
Open "C:\MyPath\DataNew.dat" For Output As #FileNum
Print #FileNum, "Test String" '<<<< this line errors
Close #FileNum
As I said it works perfectly most of the time but I cannot see why it should ever fail.
It happens in Windows XP and Windows 7
Thanks for you help
FileNum = FreeFile
Open "C:\MyPath\DataNew.dat" For Output As #FileNum
Print #FileNum, "Test String" '<<<< this line errors
Close #FileNum
As I said it works perfectly most of the time but I cannot see why it should ever fail.
It happens in Windows XP and Windows 7
Thanks for you help
ASKER
The thing is it work perfectly most of the time on hundreds of computers.
Re file handles - this is unlikely as the code is only called during startup and I close files after use so there is never more than 30 files open and that is only in one routine - the rest of the time no more than 12.
Re file handles - this is unlikely as the code is only called during startup and I close files after use so there is never more than 30 files open and that is only in one routine - the rest of the time no more than 12.
Maybe the script is executed twice at the same time?
ASKER
Not possible I have code to prevent more than one instance of the program running on one computer.
The code is in a routine that only can run once as the program is starting.
The code is in a routine that only can run once as the program is starting.
Is the file name actually "DataNew.dat" or is there code that generates the name? If it's the latter then it might be generating an invalid file name.
I would have to agree with ste5an, specifically regarding "permissions". If the error only occurs on, for example, PC1, but not on the other PCs, then you might have to verify that C:\MyPath has "write" permission for the user that's running your program. Also, avoid using system folders, such as C:\Program Files or C:\Windows as standard users can't write to this folders under the default Windows XP/7 security policy.
Another thing might be the Anti-Virus software on the PC in question deleting OR locking the file right after it was created.
To ensure your program always has exclusive access to the file, you should use the "lock" keyword as follows:
Open "C:\MyPath\DataNew.dat" For Output Lock Write As #FileNum
Another thing might be the Anti-Virus software on the PC in question deleting OR locking the file right after it was created.
To ensure your program always has exclusive access to the file, you should use the "lock" keyword as follows:
Open "C:\MyPath\DataNew.dat" For Output Lock Write As #FileNum
ASKER
The filename is hard coded
As the code works most of the time on all computers and then happens on one I cannot see how it can be a permissions problem,
Also rerunning the code works correctly.
If it was a system folder I would have said so.
There is no reason to use lock write and this error would be different if the file was locked.
The reason I asked the question is because it only happens sometimes and there appears to be no reason.
As the code works most of the time on all computers and then happens on one I cannot see how it can be a permissions problem,
Also rerunning the code works correctly.
If it was a system folder I would have said so.
There is no reason to use lock write and this error would be different if the file was locked.
The reason I asked the question is because it only happens sometimes and there appears to be no reason.
Could more than one person be trying to write to the file? (That is one reason for error 70).
There is no reason to use lock write and this error would be different if the file was locked.
This is completely misleading and an incorrect assumption.
Error 70 generally means "Permission denied" per the MSDN Help Library. Please note that the term "permission denied" may not be necessarily related to "read/write permission" on the file. And since the issue happens sporadically on just one machine, that particular machine may be running something or configured differently than the others. Also, since the file is NOT exclusively locked when created, it is absolutely possible that some other processes can lock it thereafter, such as an Anti-virus software. By the way, it is NOT always required to lock a file open for output or append - my suggestion to "use the lock method" was merely to see if that takes care of the issue in question.
Error 70 is quite general and has multiple meanings per the MSDN Help as follows:
You tried to open a write-protected file for sequential Output or Append.
Open the file for Input or change the write-protection attribute of the file.
Open the file for Input or change the write-protection attribute of the file.
You tried to open a file on a disk that is write-protected for sequential Output or Append.
Remove the write-protection device from the disk or open the file for Input.
Remove the write-protection device from the disk or open the file for Input.
You tried to write to a file that another process locked.
Wait to open the file until the other process releases it.
Wait to open the file until the other process releases it.
ASKER
We did have a problem some years ago where there was an HP printer driver that locked files for no reason - updating the driver fixed this.
I do find it strange that the file is one that works perfectly most of the time and is one that no other process opens and is only opened once during the program starting.
I do not see anything in the suggestions that explains why the error should happen in this case but I was hoping that someone might know of some strange thing that can cause this error.
I know that Vb's error trapping is a Microsoft thing and therefore is not 100% accurate.
I was testing some code the other day and having opened a file for random access I got the error 70 after inputting many records - I found that the input was way past the EOF but it did not give the error until it had input hundreds of records past the EOF. I did have and EOF trap but that failed to trap!
I still think VB6 is one of the great programming languages and I see it is still number 3 in the world!
Thanks for your help - I will just have to wear the problem as re-running the program runs without the error.
It's just I would like to find some way to prevent the error ever happening as it's annoying when any error happens!
I do find it strange that the file is one that works perfectly most of the time and is one that no other process opens and is only opened once during the program starting.
I do not see anything in the suggestions that explains why the error should happen in this case but I was hoping that someone might know of some strange thing that can cause this error.
I know that Vb's error trapping is a Microsoft thing and therefore is not 100% accurate.
I was testing some code the other day and having opened a file for random access I got the error 70 after inputting many records - I found that the input was way past the EOF but it did not give the error until it had input hundreds of records past the EOF. I did have and EOF trap but that failed to trap!
I still think VB6 is one of the great programming languages and I see it is still number 3 in the world!
Thanks for your help - I will just have to wear the problem as re-running the program runs without the error.
It's just I would like to find some way to prevent the error ever happening as it's annoying when any error happens!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
A normal use does not have write permissions to this path under normal circumstances. Another problem maybe that there is no more file handle available. This may occure when your program is making masive use of the FreeFile function or it is a long running application.