.cdx复杂索引文件，要把所有索引字段都重新索引一次。现在也不知道你那个索引涉及别的表的什么字段，保守的做法是把所有表的索引都reindex一次，在服务器上做，不要拷出来。修改服务器上的程序，用独占模式打开数据库，马上reindex，要确保此时没有别的人在使用系统，数据库能够独占打开，否则是无法重建索引的！只要能够成功做一次，就可以把程序改回原来那样。这个程序，你应该添加一个维护模块，适当时候重建索引，这是很重要的，在多用户共享环境，表的索引经常出问题，只要抓住空子就重建索引（能够独占数据库的机会无多，上班时第一个开启系统的那个人会启动重建索引机制），没有那么多烦恼，做索引是电脑做，好过你自己做，不争那一两分钟时间。

是只将这一个表reindex嘛，对吧？
服务器上的自由表都在一个文件夹A下，为了不影响正常使用，我把这个文件夹复制了一遍改了个名B，然后在运行程序的电脑上改了下代码路径都去找B，然后对B里的book.dbf和book.cdx进行reindex或者erase，重建，效果是一样的。也就是说这个server上的book表无论怎么该好像都没有实质性的变化。晕了。。

这样啊，所以说多用户会出现这种问题的偶尔啊？我在等等，协调好了等哪天所有程序都关掉对所有表reindex一次试试吧。另外，程序是24小时跑的，米有空子钻的说，除非他们通常一个月左右做一次reindex..
这个问题算不算VFP的一个弊端啊


[ 本帖最后由 Bunny008 于 2012-4-20 21:01 编辑 ]

直接让运行的程序自己重建，改服务器上运行着的程序，不要这样偷巧，因为我们没人知道这个系统到底如何处理其中数据库的，这方面没人能够解答你“为什么”。我只能想到的办法，是让实际运行着的程序自己去做，成功的机会较大，但也不确保。

VFP这种.dbf和.cdx分开不同文件储存的形式，是容易造成文件数据不同步，但这样也有比全部合并在一个文件中的数据库模式优越的地方，是速度更快、占空间也更少。其实，只要做好同步工作，问题不会很严重的。

你在自己的电脑上操作成功，是因为你处于独占状态，重建索引成功，但在服务器上，如果别人正在使用相应的文件，你是无法更新它的，必须要他们都关闭了才成。何况，你在自己电脑上改索引，拷回去的时候，服务器上的数据已经不是你当时拷走的那些了，你这样做会把旧数据覆盖新数据的，惹大乱子。

是这样的神哥哥，我上一条说的，我把表全部复制到服务器的另一个文件夹下，然后把程序找的路径改到这个文件夹下，然后对里面的book表进行reindex，独占状态，然后只运行这一个改过路径的程序。。
不行之后我又试过把这个表烤到我的电脑上，改了下运行成功又烤回去，反正都是测试用的覆盖就覆盖了呗，只要这个能好哪我再改原先的嘛。可是烤回去就出现“File is not open”


[ 本帖最后由 Bunny008 于 2012-4-20 21:13 编辑 ]

问题是你是否知道程序一直在读你改过的路径中的数据？那个程序代码有硬编码的盘符，你也未必知道吧？整个程序是你参与设计及自己写的，就清楚它到底如何处理数据，但看样子你并不了解，我们更不了解。

[ 本帖最后由 TonyDeng 于 2012-4-20 21:14 编辑 ]

硬编码盘符？
我在改过的数据表里新建了测试数据，正常运行的程序里看不到，改过路径的程序运行能看到。这个算不算？
接触这个程序的时候我都不知道VFP是什么。。。

你找出运行到“不能打开”那一句代码看看？

你这种问题，不知道系统的架构，是很难排查的。道理其实很简单，如果它是简单的错误，在程序投入前及初期都已经查出来了，而系统运行了这么长一段时间，说明它有相当的稳定性，错误隐藏的更深，现在叫我们隔山打牛地给你排错，几乎不可能，何况又要遮遮掩掩的。