You are way early in the help sequence, IMHO. You haven't reached the
point where you have determined whether it is systemic or if it is one
machine, AFAICT. No one on this end could foster a decent opinion above a
guess if they don't have at least a point of beginning.
----- Original Message -----
From: "MDRD" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Thursday, March 17, 2011 1:32 PM
Subject: [RBASE-L] - RE: Data corruption
Jan
I will check the Var’s, I never really thought of that since they stay in a
Loop
Dialog ... Custnum
Edit Using Form
click a few buttons, maybe type in the Varchar field
Exit to the Dialog box and then do the next Custnum
Worth taking a second look, but if I have to do over 10 rows to find the
problem it may make it hard.
Marc
From: jan johansen
Sent: Thursday, March 17, 2011 12:25 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: Data corruption
Marc,
I'm currently running the V91 compiler. I have had intermittant reports from
a couple of users
that they get an error message after they do about 60 items. Currently I'm
leaning towards
a variable or something that I am failing to clear or something but haven't
had time to chase it
yet.
Jan
Note to Razzak:
I am in no way implying that there is a problem with your product.
-----Original Message-----
From: "MDRD" <[email protected]>
To: [email protected] (RBASE-L Mailing List)
Date: Thu, 17 Mar 2011 12:19:04 -0500
Subject: [RBASE-L] - RE: Data corruption
Paul
They do a full Unload all at least monthly w/o errors. So the hiccup and
corrupt packets seems to be the most likely cause. But their computer
tech
installed new computers and network stuff and says it checks out. I know
just because it looks OK when they check it does not mean it is not
causing
hiccups every few weeks.
Another office had this same problem, we not have them enter 10 rows at a
time then run Autochk to check for errors to try to narrow down what is
going on. Since they started only doing 10 rows at a time they have not
had
the problem, not yet at least. Either they are lucky or I was thinking
that
doing 50+ rows was maxing something out? Not sure what that could be.
Thanks, I would to find a packet sniffer that is easy to use, once in a
blue moon we have an office with different "corrupt" data in another
table.
They get custnums like 349,545,112 which they do not have any that big.
We
have PK and FK on the custnum field and you can not enter a bogus custnum
without RBase stopping you. So, I always them them it is a computer
hiccup
that is scrambling the data.
Marc
-----Original Message-----
From: Paul
Sent: Thursday, March 17, 2011 12:01 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: Data corruption
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
