Index Corruption

[ongoma]

Hi all,

I have quite a peculiar problem. Maybe somebody can help me out.

I have in my app compined both Buffering (5) and Transactions to help me either save everything or nothing
in the event that something goes wrong.

This works fine for other errors like locked records/files
etc.

But of late, somebody inadvertently unplugged the server's power while users were posting entries. This cleverly corrupted the index (CDX) of one file in a way that:

1. You can open the file without any error being generated

2. You can post entries (and the system tells you "Posted Okay", yet nothing goes to this file) without generating
any error

So in case of payment cheques, the General Ledger is updated with the nessecary entries, the creditors statements are updated correctly but the cashbook shows no
trace of those payments. They were simply not posted (courtesy of the corruption) TableUpdate(.t., .f.) does not report failure.

My question is: How do I trap this kind of anomaly to avoid orphan records and complains from users.

Specs (VFP6 Windows XP)

Ongoma

 

[GriffMG]

I *think* you would have to write code to verify that the data written was actually saved to the file.

In the first instance, I would rebuild the file and it's index from scratch and import the data from the original - to make sure there was no header file corruption.

I have one system, which was running on prety flakey h/w, and in an industrial environment (i.e. not very nice power) and that used to occasionally throw a duff record into the data base - but it was alway easy to find, it would usually be the last physical record (at least initially) and would be full of non-text characters. So I used to put a test in to check the last few physical records on the way in each day and look for odd characters - and alert the user if any were found.



Regards

Griff
Keep [Smile]ing

 

[ongoma]

Griff

Thanks for your suggestions. It's a really thorny issue.


Ongoma

 

[Mike Lewis]

Ongoma,

It sounds like you to need to use transaction processing. It won't prevent the corruption from occurring, but it will prevent anomolies such as the ones you described.

Check in the help re BEGIN TRANSACTION, END TRANSACTION and ROLLBACK.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[baltman]

You might find this helpful too.

http://winnersoft.coolfreepages.com/vfp/buildindex.htm

Brian

 

[ongoma]

MikeLewis

I am actually using transaction processing. That's my problem. All tables are buffered mode 5 then during saving I use BEGIN TRANSACTION then END TRANSACTION/ROLLBACK.

For all other errors this will return the appropriate messages for users intervention- it works and works well but with an index corruption on the cashbook table TABLEUPDATE(.t.,.f.) reports .t. while in actually sense the records never went there. I do not know Mike, but this seems so peculiar to me - a major nightmare to me.

I want to save all or nothing. TABLEUPDATE(.t.,.f.) should be faithful enough to capture update failure caused by kind of funny corruption that wont hawl on any form of table operation commands.

Please help me. Am ending up with orphan records with no parent records.

Ongoma

 

[ongoma]

Brian,

Thanks for the post. However, I have similar code but this comes last for my primary need at the moment is to have the system update failure when index corruption is detected.

Thanks nevertheless.

Ongoma

 

[Mike Lewis]

Ongoma,

TABLEUPDATE(.t.,.f.) should be faithful enough to capture update failure caused by kind of funny corruption

I don't think so. Calling TABLEUPDATE() with the second param set to .F. will trap for multi-user violations and failures of triggers, validation rule, etc. It's not meant to serve as a catch-all error trap.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[ongoma]

MikeLewis,

Well, that's what I thought. I was wrong. So how do I just make sure that sinister index corruption does not cause this scenario.

I'll appreciate any help.

Ongoma

 

[Dan Freeman]

When asked about this, Doug Hennig's usual response is that it would take so long to detect corruption you may as well just delete the tags and recreate them.

What you really have is a power problem at the server. You can't solve a hardware problem with software. ;-)

 

[ongoma]

All

Thanks for your responses. Ihave made up my mind on what to do with this situation based on your replies. Thanks

Bye