We have many indexes on datetime fields. None are primary keys, though. I don't remember the thread, but there was one here not too long ago describing how datetime values are put together. Suffice it to say that datetime values should never be used as a PK -- duplicate values are too great a possiblity.

If that doesn't solve your problem and you're having bad index problems often, you may want to revisit how you're working with that table. In the almost two years of our software being "live," we've had only two instances where an index became corrupted.

First, avoid using tables directly. Make sure you're using views. One of the reasons for switching to views instead of working directly with tables is the stabilizing factor regarding indexes. I don't know how long you've been working with Fox, but one of the pre-dbc container gripes was how often indexes would get blown.

If none of the above helped or was news to you, I would suggest hunting the blown index. I've always had luck by simply using the table, setting order to each index one at a time, and issuing a "GO BOTTOM" and then attempting a browse. When the offending index is found, an error message appears, or you won't be at the "bottom" of the index, or you'll be at EOF() -- something that won't make sense for your table. At that point, you can recreate the index or reinvent it, or maybe delete it if it's a recurring theme.

Good luck,
---J

>I tested the return value of the save method and it returns zero. In my opinion, this is almost certainly a VFP issue concerning a bad index. I am even using Stonefield to validate the table and the DBC with no results. It gets fixed when I delete the .cdx file for the table and re-create. I'm wondering if having an index on a datetime type of column could be a problem??