Windows 7 file problem

Question

I am using VB6 SP6 This code has work correctly for years but I am now having a problem on a WIN7 to WIN7 network. It also works correctly on an XP to Win7 network.

Open file for random as ChannelNum LEN =90
 'the file is on the other computer on the network

RecNum = (LOF(ChannelNum) \ 90) + 2

Put ChannelNum, RecNum, MyAcFile 
'(MyAcFile is UDT that is less than 90 long)

.......... other code that does not reference file or RecNum - then

RecNum = (LOF(ChannelNum) \ 90) + 2
Put ChannelNum, RecNum, MyAcFile
Close ChannelNum

The second record overwrites the first.

We had a similar problem in the past with OpportunisticLocking so we turn that off at install - along with some other keys that cause errors in data in Windows networks.

However we have had no problems like this for years, so I think MS have some new "better" option that they think will "improve" networking.

Thanks for your help

Answer 1

Hmmm... is file (as per in the open statement at the top of the code sample) UNC filename or similar to x:\ where x is the mapped drive? Are you not incrementing RecNum? Judging by the code, the RecNum is unchanged and hence appears to overwrite the first record...Sorry for sounding ummm no pun intended... basic...It would be of help to show some more code here...

Hope this helps, Best regards, Tom.

Answer 2

It can be just timing issue. In some runs your LOF() function returns more updated information than in other runs. The file system API is asynchronous, for example when some write function is called it will not be immediately reflected as the increazed size.

In short: you code have shown an old bug, which is just easier to reproduce on Windows 7.

To fix the bug the cheapest way: you may decide to add a delay (it can be significant delay of say 5 seconds).

More elaborate fix is to force the size update by closing and reopening file.

Answer 3

I doubt there is any "bug" here except in your approach. The file metadata that LOF() interrogates is not meant to be updated immediately by simple writes. A delay seems like a silly idea, prone to occasional failure unless a very long delay is used and sapping performance at best. Even close/reopen can be iffy: VB6's Close statement is an async operation. That's why the Reset statement exists.

This is also why things like FlushFileBuffers() and SetEndOfFile() exist at the API level. They are also relatively expensive operations from a performance standpoint.

Track your records yourself. Only rely on LOF() if necessary after you first open the file.