插入故障通过网络后立即选择 [英] immediate select after insert failing over network

问题描述

我最近遇到的问题是，使用SELECT命令无法立即读取INSERTed数据。 我关闭了SQLBUFFERING，并且在插入后尝试使用FLUSH，但它没有什么区别。 我可以在循环中查询数据
，它会在500毫秒左右后显示，并且所有内容都正确写入。 我认为这是服务器硬盘驱动器上的某种缓冲问题，但到目前为止还没有找到解决方法而不是查询
循环。 任何处理此问题的建议都表示赞赏。

I've been having a problem lately that data which is INSERTed cannot be immediately read using the SELECT command.  I have SQLBUFFERING off and also have tried using FLUSH after the insert, but it doesn't make a difference.  I can query the data in a loop and it will appear after 500 milliseconds or so, and everything is being written properly.  I assume this is some kind of buffering issue on the server hard drive, but so far have not been able to find a way around this other than the query loop.  Any suggestions to deal with this are appreciated.

Kevin Clark

Kevin Clark

推荐答案

我只知道你可能没有做错任何事情而且只是缓存的受害者。

I can only tell you you're likely not doing anything wrong and are only a victim of caching.

不是VFP缓存，所以FLUSH没有帮助。相反，网络/文件系统/操作系统缓存没有正确地使其无效。

Not VFPs caching, so FLUSH doesn't help. Rather network/filesystem/OS caches not correctly invalidating.

它可能有助于在网络中找到问题，它发生的地方和不存在的地方。然后，您可能会在网络中找到配置错误的交换机或集线器，这将分离有问题和无问题的网段。

It may help to locate the problem in the network, where it happens and where not. You may then find a badly configured switch or hub in the network, which is separating the problematic and unproblematic network segments.

如果我想到您的其他线程有关空白autoinc的问题通过处理临时本地DBF解决了这个问题，这可能是相关的，并指向相同的网络问题。

If I think of your other thread about the problem you had with blank autoinc and you solved by working on temporal local DBFs, this might be related and point to the same network problems.

详细说明机制：任何级别的缓存都必须写入，所以更改即将发生从任何地方立即命中后端文件，然后还必须导致一系列无效的任何操作系统/文件系统/客户端缓​​存现在更改的文件块的先前
状态。如果某个交换机或集线器未在规则中播放，那么对于一个网段，该无效可能会失败。它甚至可能从没有配置写入延迟开始，延迟写入，这延迟了整个
进程，包括当其他客户端缓存开始失效时，当然。

To elaborate on the mechanism: Caching at any level must be writethrough, so changes coming from anywhere are immediatly hitting the backend file, then also that must cause a cascade of invalidating what any OS/filesystem/client is caching about the previous state of the now changed file blocks. And that invalidating might fail for one network segment, if some switch or hub isn't playing along within the rules. It might even start in them not configured for writethrough, delaying writes, which delays the whole process including when invalidation of other client caches begins, of course.

最后缓存然后仍然认为他们存储的先前状态仍然有效并提供它。这可能导致双重autoinc值，然后导致写入冲突和更多错误，因为他们不知道他们提供的
块文件是错误的。

In the end caches then still think the previous state they store is still valid and provide it. That can lead to double autoinc values which then later cause conflicts in writing and many more errors, because they don't know they are wrong about the file blocks they provide.

再见，奥拉夫。

这篇关于插入故障通过网络后立即选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！