William, Do you have UPSs on your machines and hubs? Corruption like this is caused from an update to the database getting interrupted before it finishes updating everything for that change. In this case it sounds like updating the index is getting inturrupted. My experience in the past when this type of problem starts popping up, it comes from electrical problems or hardware problems.
By removing the UNIQUE index constraint, you are creating less overhead, and therefore less processing is needed for each update, so the problem should get somewhat better. I don't think this will fix your problem, but just make it happen less often. The list table and select count numbers being different means you have mismatched #1 file info and #2 file info, but does indicate corruption. These counts will have nothing to do with and index being corrupted and you quite possably my have broken pointers in the #2 file. Here are a couple of more things you might want to try. If you have a table MYTABLE that has an indexed col MYCOL you might want to try: list tab mytable select count * from mytable select count * from mytable where mycol is not null -- uses index on mycol select count * from mytable where (mycol) is not null -- does not use index These 4 commands should give you the same # of rows. If you only have an index problem, 1 and 2 will match, and 3 & 4 may not match Troy Sosamon ---------- Original Message: Hoping for help and providing a warning: We have begun to encounter REPEATED index corruptions, resulting in a scenario in which rows seem to both exist and not exist at the same time. The usual tell-tale clue is if one were to compare the row counts returned by the LIST TABLE and SELECT COUNT(*) FROM they are different. And the data is NOT retrievable. The only common link seems, at this time, to be that the tables in question have UNIQUE indexes declared. We have begun to remove these indexes in an effort to contain this problem. Maybe a bit late, as it has already cost us substantial amount of money due to invoices not being calculated correctly because the details of the charges got "lost". Has anyone else experienced such behavior? Is this a noted issue? This issue has moved from table to table, so I am not considering it a coding issue, and I have way too many projects to debug index issues, so any help would be appreciated. Windows 2000 & NT 4.0; RBWin 6.5++ Also, this behavior has happened on databases that do not share hardware, so I have discounted the possibility of NIC or other hardware failures. William Mason ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
