A way to protect index files?

[culleoka]

I have a simple VFP5 app, running on about thirty machines, that is continually failing because of a corrupt .cdx file.
It has single record, one C(9) field, table to enter the info to look up, which is linked to two others tables by that field.
After entering one part number, I have to 'shake' it a little to get the proper results to show in their respective grids. Which I do by reindexing the single entry table.
This works fine until a power spike, brownout or power failure occurs. Since most users have this app running 90% of the time, the index file associated with the single entry table is corrupted(filesize 0 bytes) when anything happens to the power.
Is there a way to stabilize FoxPro, or do I need the overwrite that file each time the program is started?
Stabilizing the index file would be the preferred long-term fix.

Thanks in advance.

Pat

 

[DSummZZZ]

Unfortunately, there is no real way to 'protect' index files.
You can reduce the corruption by ensuring any writes are flushed to disk and records are unlocked as often as possible. That would reduce the number of times the file is kept open.
Short of that, you really need to address the issue at hand. The loss of power. You need to make sure the computers are connected to a constant clean source of power, at least a short term battery backup. You're going to have trouble with a lot more than index (and most likely data) files unless you get that issue resolved.

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[darrellblackhawk]

As Dave says, you really need to deal with the power problem first!

You'd have the same problem no matter which database platform you use.

Darrell

 

[audiopro]

Is flushing to disk, a simple case of issuing FLUSH() after every data edit routine?
Keith

 

[Mike Lewis]

Keith,

Is flushing to disk, a simple case of issuing FLUSH() after every data edit routine?

Not in my experience. I last used it back in FoxBase (or might even have been dBASE). I can't recall seeing it in anyone else's code recently.

Mike

Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[Mike Lewis]

Pat,

Although I completely agree with Dave and Darrell that you need to sort out the power problems, I am curious about your statement:

After entering one part number, I have to 'shake' it a little to get the proper results to show in their respective grids. Which I do by reindexing the single entry table.

I can't imagine a situation where you need to re-index a table in order for results to appear correctly in a grid. Also, it's rare that you need to index a single-record table.

Regardless of the problem of power failures, it sounds like you need to look a bit more closely at this issue. If you could explain the grid problem in more detail, we might be able to suggest some alternative approach.

Mike



Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[audiopro]

Mike
What is the standard way of ensuring all updated data is written to disk. Are there different issues depending on the type of table buffering being used?
Keith

 

[Mike Lewis]

Keith,

What is the standard way of ensuring all updated data is written to disk. Are there different issues depending on the type of table buffering being used?

This is a bit off-topic. I would suggest you check out the FLUSH() function (although this is not often used and not usually necessary). Buffering is a separate issue. When buffering is in force, nothing is physically written to disk until the buffer is committed.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[culleoka]

Mike,
By 'shake it a little', I mean 'move the pointer in the table' to get the grids linked to the single entry table to refresh. I imagine there are other ways to do it, but since the whole table amounts to one row, 9 characters wide, and the grids never get focus, it was simplest to reindex the single entry table.
Pat

 

[Mike Lewis]

Pat,

By 'shake it a little', I mean 'move the pointer in the table' to get the grids linked to the single entry table to refresh.

It's probably better to do LOCATE RECORD RECNO() or GO RECNO(). That way, you can probably dispense with the index completely.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[culleoka]

Thank you, everyone for your replies to this question.

Guess I'll just copy the .dbf and .cdx files from archive at each startup of the app.

Pat

 

[GriffMG]

There is no need to copy the table and index, simply create it anew for each start-up - treat it as a temporary table.



Regards

Griff
Keep [Smile]ing

 

[Dan Freeman]

The problem here isn't index corruption. It's a power problem.

If the power is flaky enough to commonly cause index corruption, sooner or later it'll get the data too.

Fix the power problem.

 

[culleoka]

Thank you, Mike Lewis!

Go Recno() did the trick. I can now get rid of the troublesome index file. The app will now be much stabler.

Also thanks to everyone who responded to this question.