Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Error #2 : best solution needed

Status
Not open for further replies.

SyBorg

Programmer
Oct 23, 2001
6
IT
Hi all,

I am constantly facing some nasty error 2 with BTrieve 6.15 and Magic environment. I think I know what is the source of the problem, I think of unpredictable crashes of Windows 95/98 workstations and the current network environment(BTrieve is working local with no database server, only a Snap! file server).

What I need is an advice for the best solution for this problem, since I am trying many methods (export/import through BUTIL, export/import with a Magic program, reindex with a Magic program, etc) but I am not finding a good one till now.

A big puzzle I am having in these days is about a strange case, where some program found on Internet (I don't remember now the name, I didn't download it... could be BtrDataSafe but I'm not 100% sure) is giving me a worrying message : EOF marker found.

So, I have e.g. 1000 records, this EOF marker is at 990, I am losing 10 records with each method I ahve tried up to now. I can count the records correctly with BUTIL -STAT, but whenever I try to RECOVER or SAVE I get the wrong number of records, and it is VERY important for me to get the right number.

Anyone can help?

Thanks in advance
 
Hi,

We were also facing that problem of err #2. And we have noticed that ofen appens on our sites that encounter voltage variations. So we have put and UPS Low Voltage. If the number of records is less that the original one that meens that some reocrds were corrupted. Right ?!?

Hope it helps
 
I've gotten status 02 when using btrieve 6.x layout files with btrieve.exe. My notes indicate that I don't want to do that if avoidable, but I have and status 02 hasn't always occurred. I haven't used btrieve 6.15 very much however. Suggestion - actually look at the recovered file, use a text editor to tell you how many records are actually there and look at the key fields of each record to see if any of them are corrupt. If the record count is that low, you can do it and it may be a profitable venture. I've filtered thru a 150000 record btrieve file that way. Record counts: I've had the butil -stat command tell me one thing and actually recovered another amount, or "butil -load"ed another amount. I think butil -stat only reads the file header info, it doesn't count the records individually. Is there a high volume of I/O to the btrieve file, generally deletes, but rewrites, too, can lead to potential corruption. If I was getting an EOF message at record #989, what happens if, in a test environment, delete record #989 from the btrieve file, or in the recovered file (text version of btrieve file) can you see anything beyond record #989. Can you make a clone of the file in a btrieve 5.x mode? Is the record size really big? Not familiar with btrieve 6.15, but what are the value of the parameters, if it has them, is it loading with? Using btrieve.exe, there are certain parameters, such as page size, maybe a larger page size would help you if such a thing is applicable. Is the file using compression?
Even if you give us good answers to those questions, can't promise a solution, just things to look at.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top