Question

我正在使用VB6 SP6 此代码已正常工作多年，但我现在遇到WIN7到WIN7网络的问题。它也适用于XP到Win7网络。

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

第二条记录会覆盖第一条记录。

过去我们在使用OpportunisticLocking时遇到了类似的问题，所以我们在安装时将其关闭 - 以及导致Windows网络中数据出错的其他一些键。

然而，多年来我们一直没有这样的问题，所以我认为MS有一些他们认为会“改善”网络的新的“更好”的选择。

感谢您的帮助

Answer 1

我怀疑除了你的方法之外，这里有任何“错误”。 LOF（）询问的文件元数据并不意味着通过简单的写入立即更新。延迟似乎是一个愚蠢的想法，除非使用非常长的延迟并且充其量地降低性能，否则偶尔会出现故障。即使关闭/重新打开也可能是不确定的：VB6的Close语句是异步操作。这就是Reset statement存在的原因。

这也是API级别存在FlushFileBuffers()和SetEndOfFile()等内容的原因。从性能角度来看，它们也是相对昂贵的操作。

自己跟踪您的记录。首次打开文件后，只有在必要时才依赖LOF（）。

Answer 2

嗯...是文件（在代码示例顶部的open语句中）UNC文件名或类似于x：\其中x是映射驱动器？你不是在增加RecNum吗？从代码判断，RecNum没有变化，因此似乎覆盖了第一条记录......对不起，听起来没有任何双关语......基本......这里显示更多代码会有所帮助......

希望这有帮助，最好的祝福，汤姆。

Answer 3

这可能只是时间问题。在某些运行中，LOF（）函数返回比其他运行更多的更新信息。文件系统API是异步的，例如，当调用某个写入函数时，它不会立即反映为增加的大小。

简而言之：您的代码显示了一个旧的错误，在Windows 7上更容易重现。

以最便宜的方式修复错误：您可能决定添加延迟（可能是5秒的显着延迟）。

更精细的修复是通过关闭并重新打开文件来强制更新大小。

Windows 7文件问题

3 个答案: