Many, many years ago I had a problem with data corruption. I eventually traced it back the static electricity between the person and the keyboard. rich
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of MDRD Sent: Tuesday, July 05, 2011 8:14 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Strange data corruption error Hi all I have this office that is a real pain, they keep getting data corruption and it is always in the TravCard table that has a Varchar. Their hardware tech can not find anything wrong with the network, which is what I keep blaming. They seem to be able to enter several hundred of rows without a problem then out of the blue the problem hits. At first we thought it was a new worker at this office then when that person left the problem followed the new employee to their other location but now they have it too. Autochk Full showed this ....I am not sure what that means. They push a button that looks up canned Varchar text from another table, then we run a series of SRPL on the text then we Update this TravCard table. Since it is so random, (maybe once every month or so) I wonder if they could have some corrupt data or something in the look up table for a button that they only use once every so often? Then pack 2x a month and they usually pack when this happens and just accept the lost rows. I would think is my code can work for several hundreds of rows in a row that my code is OK, but I am not sure about that or what to look for. Any suggestions would be appreciated Thanks Marc Examining LOB data in TravCard -WARNING- Column Subjx at rowid 196657153, has data length 0, expected 538976288 Examining LOB data in ptsoap Database statistics: Table entries allocated: 175 Table entries in use: 175 Table entry utilization 100.% Column entries allocated: 916 Column entries in use: 916 Column entry utilization 100.% Index entries allocated: 147 Index entries in use: 147 Index entry utilization 100.% File #2 active space: 196665072 File #2 unusable space: 272 File #2 utilization 99.9998616939851% No errors found.
