Re: Corrupt Indexes

[Brent Skean]

Does autochk give you an error number?   I don't know if this relates, but straws are straws...   We maintain our own 6.5+ databases and have never experienced problems as you describe.    We also support a number of "outside our purview" 4.5++ installations   We will occasionally get a support call regarding "missing information".  The problem shows up readily... we have an F12 Balance key that shows code text instead of actual numbers.   Autochk reveals... everytime... an indexing issue (I think it is a 121 error in this case).  Reloading fixes the problem.   After many years of experiencing this, the only common denominator that I've come up with is...MS Excel is in the neighborhood.    Heck we built in a tool just to deal with this specific error... it's the only error we ever get... and since we must coexist with Excel, we offer a tool to take care of the indexes and the user is on their way.  The issue exists to this day.    Of course Magical/Wonderful v6 - v7 may already avert such issues (certainly we don't experience it onsite, but then we don't run Excel)   Straws are straws... in any regard, any kind of autochk error available?   Brent Skean Current Solutions   -----Original Message----- From: William Mason <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Tuesday, May 28, 2002 5:48 PM Subject: Corrupt Indexes 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