dbase 3 corruption? 1

[klopez]

We've just experienced a problem with dbase crashing, apparently as a result of some sort of corrupted data. We've since replaced thefile witha backed up version from the previous day,re-indexed it, and it crashed again. All our other files seem to be OK, and this one is OK if we USE it but not if we try to INDEX it and use it as an indexed file.

At one point in one of the crashes, we got an error message indicating we had an Illegal Op Code 158. However, without the dbase manual -- which has been missing from here for some years now, we can't determine what that's trying to tell us. The Dbase books we do have on hand don't deal with error codes at all.

Does anyone have any info about that Op Code, or about what kind of corruption we could be dealing with (we created an entirely new index file to INDEX the restored database, so we weren't relying on the old index, but we still get the same kind of failure and inability to use the file as an indexed file). Symptoms: When we BROWSE we can only see a portion of the database, which becomes clear as we page down, but only upto a point -- where it disappears, with the last record shown repeating several times before the program crashes.

Any thoughts or help will be much appreciated. Thanks

klopez

 

[MiggyD]

Geezzzz, sounds like a virus. Did you check for that?
My DB3+ handbook doesn't reference Error codes.

Since you've USEd it..did you try SORT TO NEWNAME and then index NEWNAME?

I'd also have to guess that your PRG <if you're using one> may be at fault. Double check your code and make sure the module pertaining to the USE <DBF> and INDEX <NDX> statements are proper. Could be that someone went in and changed something. Slim chance, I know, but it wouldn't hurt to at least look at it.

How large is the overall DATAFILE itself?
Any other symptoms you can share?
-MiggyD

 

[MiggyD]

One other thing I just thought of...did you try dumping the datafile to your printer? maybe there's a ascii character that is/was written into a field and is causing this loop.

 

[GEMS]

Most DBIII+ manuals only give a selection of error messages. To complicate it further, Ashton Tate for some reason didn't number all the error codes. In desperation, I once managed to extract an almost complete list from the innards of the DBIII files.(I've led a sad life!) Sadly, no. 150 is the highest.(If anyone is interested in having these error codes however, then let me know and I'll talk to the forum controller about how to post the list so it's available to all!)
Somehow I strongly suspect that knowing what the illegal op code means may not be very useful in this case. I agree with MiggyD - we need more data. Can you list the structure of the file and what keys are used to index it? How many records are there? What were the last commands the program or operator performed just prior to the crash? Were any relationships involved? Are any complex filters being used? What is the secret of the Spider Woman? Confess darn you!
Ooops!
Like MiggyD, I suspect that a single character has gone astray in the table - the usual suspects is are date fields. Recreating the table by copying (COPY TO NEWFILEN1,N2 etc) all but the suspect record(s) and then joining the subsequent tables and recreating the lost records might be a possible solution.

gems - Hope this helps.

 

[MiggyD]

GEMS,

I would LOVE to see ANY and ALL ERROR CODES you may have. My pittifull handbook is a &quot;How to write&quot; programs not even a good &quot;Reference&quot; source.

You could post them in the FAQ for this forum for ALL to see and for future use as well. Members, or you, could also direct new postings to the FAQ at the top of the forum's home page to get their answer(s).

The only other thing is that her name, as only I could understand it, was Ms. R. O. Tive. That's Ms. Raedi O'ack Tive--But I could be wrong so don't quote me on her name.

I look forward to your post!!
-MiggyD

 

[klopez]

Thanks for the various suggestions.

We developed something of a work-around by installing Dbase IV 1.5 and using it on the files. Where Dbase III would crash on the bad index (presumably), Dbase IV would allow us to REINDEX and continue. We still don't know the source of the problem, and Dbase IV is now gagging on a different index than the one that gave us a problem using Dbase III.

With regard to the various suggestions and questions: the file is a pretty simple mailing list database -- names (first and last), company, street address, city, state, zip, phone, fax, source (of the name), a field for their credit card info, and one miscellanous field for any text notes we want to keep. We index it on lastname, firstname and company (a pretty standard alphabetization). That's pretty much it.

The file that was crashing in Dbase III was about 1500 records. The file that's crashing in Dbase IV is about 130 records. We also have a file that's about 11,000 records that has (so far) never crashed, although we use it less than we use the others.

MiggyD's suggestion of an ascii code somehow getting written into a field strikes me as plausible although I'm not sure how this may have happened. However, we are using Dbase III (now IV) in a networked environment and although there is typically only one user of it, her machine is not the machine the database is stored on, which makes me think that some sort of incomplete or mis-communication across the network may have resulted in an improper character being written to the database. I suppose I could check that, but I'm not sure I want to take the time to figure out where to look and, once there, how to identify a character that shouldn't be there -- especially since it could be one character in a database that's hundreds of thousands of characters long. (If it were in the index file, it would be shorter and perhaps easier to recognize as well, but the fact that different indices have failed leads me to think it's an index choking on a data character, and the placement of that incorrect character was &quot;altered&quot; relative to the good data when we started using Dbase IV. At this point, I'm way over my head in imagining what Dbase III or IV wants to see and where they want to look, how they set up any internal pointers, etc.)

The only PRG files we're using are one-line programs to invoke the desired database with its index (or indices). All the rest of our manipulations are done at the dot prompt by hand.

Again, thanks for the thoughtful responses.

klopez

 

[GEMS]

Dear klopez &amp; MiggyD
I've posted a list of error codes and messages in the FAQ area. Hope these prove helpful to whomever.
I've lot's more error data which I'll publish as &amp; when I unearth it in my system and tidy it for better understanding.
Meanwhile back at klopez's problem, thanks for the extra data but it doesn't yield an answer as yet. I'll chew on the matter some more.
As for how incorrect ASCII codes get into a file....
A colleague of mine once believed that switching on a nearby fluorescent tube whilst saving a file to disc ran the risk and a piece of code being scrambled as it was written. He set up an experiment whereby many saves to disc were made whilst a fluoro was switched on and off. Sure enough when he checked, he had some scrambled files - but then he realised he had proved what? You see the percentage of scrambled files was exactly as predicted.
GEMs

 

[MiggyD]

GEMS,

Very impressive list. I gave it a rating of 10 wish it could have been 100 instead. But, anyway, I've downloaded the text to my system for future reference as well as added it to my DBase zipped file incase my system crashes again. <fingers crossed>.

Also, your observation about external influences is true. There may be a power serge/browout causing the problem. So, I'm giving you a TipMaster Vote. Unfortunately, after reading KLOPEZ's last statement, I'm leaning more towards a bad cylinder (CRC).

klopez,
Since the error is now moving to another index, you may want to run &quot;ScanDisk&quot; or other drive verification program and make sure your hard drive isn't failing..just in case.

 

[MiggyD]

klopez

You may want to check--

thread290-40892

--for some help in having DB do the searching for the &quot;possible&quot; asci code bug for you. If there's one at all.

Obviously, it would take some time, but it would definitely be better than you searching for one character.

--MiggyD