>Hi there,
>
>some of our customers are getting a lot of index-errors 2066. To most of them it happens always
>in the same routine/module, always the same dbf, but to each customer it happens in another routine.
>The error happens when it comes to querying a dbf and I can reproduce in the command window.
>It is strange how it appears, for example I have a simple query which goes like that:
>
>

>select * from galtrans where nummer = "1111111111111"
>

>
>This works fine, but trying it with the identified "troublemaker" causes the error
>
>

>select * from galtrans where nummer = "2222222222222"
>

>
>This causes error 2066 to happen
>
>But funny enough, if I set the order to "nummer" (there is an index on this field) and start a seek on this number, everything
>works fine.
>If I reindex, the problem is solved, but it happens with another record in thsi table.
>
>All Customers which encountered this problem habe one thing in common. They use Win7-PCs,
>mostly in combination with XP-PCs. What we already did, is to deactivate the smb2-protocol on the Win7-PCs and
>deactivate the write-cache to.
>
>I am at the point where I do not know what to do next, so here are two questions:
>
>1) Has anybody encountered the same and has some hints for me?
>
>2) How can I check, if the index is corrupted. I tried the needreindex-function from my Stonefield
>Database Toolkit but this function does not detect the corrupted index.

There are some kinds of index corruption that can't be fixed with REINDEX. Programmatically, what you would need to do is DELETE TAG ALL, then INDEX ON ... TAG ... to restore the index file and tags.

Another way to achieve the same thing is to keep a "known good" .CDX index file somewhere, even if it has zero records. You can then restore that known good file over top of the corrupted one, then issue REINDEX. I believe certain features of .DBCs rely on index tags, which would be affected by DELETE TAG ALL, so this method avoids that.

I have also seen cases where, due to networking or workstation problems, data files accumulate unexpected CHR( 0 )s, especially in Character columns. These can cause index tags to be corrupted. You could scan data tables for the presence of CHR( 0 )s.

Antivirus is evil, so it's always worth testing with any real-time scanning component disabled, or configured to exclude VFP data, index, and temp files. Also, if there is any other software running that interacts directly with the file system (e.g. so-called "real-time" backup), try disabling that.

If multiple users are sharing .DBFs/.CDXs on a server or shared workstation, be sure that the network hardware and software are solid and properly configured, to reduce corruption.

This is a guess, but if users on Win7 are running with less than administrative privileges, maybe they are missing permissions to some required folders such as temp files folder. You could test by running your app "as an Administrator".