Marc- Grab a copy and do the 'Razzak routine' to verify data integrity. Unload, Load and watch for errors! Do this on a copy. Also RScope your local copy bakup from them and see what the results are, or simply start with a Autochk full review the results.
If all is good, it is most likely a hiccup as you say. Most likely packet loss etc..... But would get you started in looking in the right direction. Data secure and no issues - Packet loss and you are lucky (client is real lucky one) Data/rows bad no see what happened on reload, issues might be from code (eep, cmd, etc...) or packet loss. Depends on the problem. A lot of new sniffers out there, I ran across a real neat one and if I locate it I will let you know. Paul -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of MDRD Sent: Thursday, March 17, 2011 12:01 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Data corruption Paul No RScope at that location. I wonder if this is a computer hiccup, Thanks Marc -----Original Message----- From: Paul Sent: Thursday, March 17, 2011 10:54 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Data corruption Does not look like RScope: " Anyway, their tech found this degug file and thought it might help. " location=5 idprev=140053707 to_ptr=140058625 rputrow_rowid=140083201 location=5 idprev=140774603 to_ptr=140779521 rputrow_rowid=140812289 location=5 idprev=142175435 to_ptr=142180353 rputrow_rowid=142196737 location=5 idprev=148008139 to_ptr=148013057 rputrow_rowid=148086785 location=5 idprev=154881227 to_ptr=154902529 rputrow_rowid=154918913 location=5 idprev=153980107 to_ptr=153985025 rputrow_rowid=154001409 location=5 idprev=164162763 to_ptr=164167681 rputrow_rowid=164192257 location=5 idprev=181005515 to_ptr=181010433 rputrow_rowid=181026817 However row pointers are most likely wrong, do you have RScope for this location? Paul -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of MDRD Sent: Thursday, March 17, 2011 10:19 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Data corruption Well its back, this one office that was corruption free for about a year just had it again. It is always the same table for some strange reason. It makes me wonder if there is some atypical data in one of the look up tables for some code that is only used once in a great while, when that lookup code is entered the “atypical” data corrupts the table. Just trying to think out of the box. If it was my code or RBase I would think it would happen more often, unless it is a combination of things. I also wondered it it could be when they use that form to enter 50+ rows of data at once, if some sort of limit or cache fills up the corruption hits? Anyway, their tech found this degug file and thought it might help. I am not sure when this file was generated, I am not doing anything that I know of to create it. This is an important office, they belong to a group of about 20 users I have. They are using a 7.6 compiled app, they never had this problem using 7.5 but I updated this form and changed a Note field to Varchar, if that gives a clue, also I changed some code. But if my code was bad I would expect this error daily. Either way, unless I can nail this down it will be hard to get them to update again. Thanks Marc location=5 idprev=140053707 to_ptr=140058625 rputrow_rowid=140083201 location=5 idprev=140774603 to_ptr=140779521 rputrow_rowid=140812289 location=5 idprev=142175435 to_ptr=142180353 rputrow_rowid=142196737 location=5 idprev=148008139 to_ptr=148013057 rputrow_rowid=148086785 location=5 idprev=154881227 to_ptr=154902529 rputrow_rowid=154918913 location=5 idprev=153980107 to_ptr=153985025 rputrow_rowid=154001409 location=5 idprev=164162763 to_ptr=164167681 rputrow_rowid=164192257 location=5 idprev=181005515 to_ptr=181010433 rputrow_rowid=181026817
