VFP9 - 索引文件已损坏。 [英] VFP9 - Index file is corrupted.

查看:120
本文介绍了VFP9 - 索引文件已损坏。的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述


我有一张桌子,它有一些索引。我有多个进程可以插入和选择。因此,某些进程因选择查询错误而失败


索引文件已损坏。请重建它。


如果重新运行失败的进程(避免其他进程插入),这将成功完成。此外,我能够打开表和查询,显示文件实际上没有损坏。只有在插入时选择记录才会出现错误。 


所以我理解的是,当某些进程将记录插入db时,cdx也会发生变化。同时,其他进程也在尝试读取可以从修改索引记录中读取数据的数据。如何避免阅读修改记录
或索引记录以避免此问题。


我正在使用  Provider = vfpoledb.1; Deleted = Yes; Null = Yes; Exclusive = No ; BackgroundFetch =无;作为连接属性


用于插入记录 -   adOpenStatic,adLockOptimistic


用于选择记录 -   adOpenStatic,adLockReadOnly



解决方案

听起来像是操作系统机会锁定机制的受害者。你无法通过OLEDB提供商设置关闭但需要在操作系统级别关闭的东西,而这只能在从3转换到SMB版本2时才能完成。


微软声称已经修复了这个问题,但你只是在一长串人群中再加上一个,这仍然会报告经常发生文件损坏。


你最好google机会锁定或oplocks找到一些解决方案,我不会在这里重复任何关于这个问题的解释,而是让​​我们澄清为什么你的解决方案向量无法完成:


你不能只是更新DBF并排除CDX文件的索引更新,这也将违背所有理智,因为CDX优化查询而不更新索引而不添加新记录将意味着在使用索引优化查询时找不到它们。
在这种情况下,索引中没有关于sql的不在DBF中,所以你的目标必须是更新CDX,好的是你不需要关心它, OLEDB提供商将这样做。只是操作系统以一种不幸的方式进行干预。
OpLocks可以正常使用单个文件,但不能正常使用文件对或三元组,因为VFP DBF确实如此。这就是MS无法理解的。我只能猜测MS确实测试了他们的修复,但没有在他们想解决现实世界问题的情况下解决
修复。


再见,奥拉夫。


Hi,

I have a table and it got some indexes. I have multiple processes which will do insert as well as select. So some process fails with error for select query

Index file is corrupted. Please rebuild it.

If the failed process is rerun( avoiding any insert by other process), this will complete success. Also i am able to open the table and query which shows the file is not corrupted actually. The error comes only when selecting records while inserting. 

So what i understand is while some process is inserting records into db, cdx is also changed. At the same time, other process is trying to read data which it can be reading the data from modifying index record as well. How can avoid reading modifying records or index records to avoid this issue.

I am using Provider=vfpoledb.1;Deleted=Yes;Null=Yes;Exclusive=No;BackgroundFetch=No; as connection property

For inserting records - adOpenStatic, adLockOptimistic

For selecting records - adOpenStatic, adLockReadOnly

解决方案

Sounds like your victim of the OS opportunistic locking mechanism. Something you can't turn off by means of OLEDB provider settings but which needs to be switched off on the OS level, and that can only be done when switching to SMB version 2 from 3.

Microsoft claims to have fixed the issue but you're just one more in a long list of people, whic still report such often file corruptions.

You best google for opportunistic locking or oplocks to find some solutions, I won't repeat any explanations about the issue here, instead lets also clarify why your solution vectors are not able to be done:

You can't just update the DBF and exclude index updates of the CDX file, that would also be against all sanity, as CDX optimises queries not updating indexes and not adding new records will mean they are not found when the index is used to optimize a query. In that case, what's not in the index is not in the DBF in regard of sql, so your goal must be to get the CDX updated too, and the good thing is you don't need to care for that, the OLEDB provider will do so. Just the OS is intervening in an unfortunate way. OpLocks work fine with single files, but not with the nature of file pairs or triples as VFP DBFs are really. And that's what MS doesn't understand. I can only guess MS did test their fix but not in a scenario having the real world problem they want to solve with a fix.

Bye, Olaf.


这篇关于VFP9 - 索引文件已损坏。的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆