Table corrupted

[Sithu]

Hi all,

Let's say I have a table named "my_table.dbf".
While my application runs, the table is in use.
At this moment, system shuts down because of power failure.
When I restart my application, I got an error message "my_table.dbf
has been corrupted".

How can I avoid this error ?
Any idea?

With regards,
Sithu

[tom knauf]

Hi,

to be sure , use an usv (add. power supply, for example from APC) which with
a battery covers your power failure or (if too long) gracefully shuts down
the computer .
As far as I know on a quit of a foxpro app all used tables are closed
automatically.

Repairing a dbf ,exspecially with memofields, can be a real pain.

HTH
Tom

"Sithu" <cith...@gmail.com> schrieb im Newsbeitrag
news:827b9446-51f5-451d...@12g2000pri.googlegroups.com...

[Sithu]

Thank your for your advice.

The problem is not for my side; it is for user side.
I cannot handle the user side : user's hardware.
What I want to know is to handle the problem by the application
( program ).

I have a feature "Backup and Restore" in my system.
When the above problem occurred, re-install the application and
restore the old data which are backup last time.

Is there any better solution than "Backup and Restore" ?

With Regards
Sithu.

[tom knauf]

Hello,

no, to my opinion there is no better solution in case its a commercial
project.
Because if you try to solve it (just reindexing, use a repair tool,..) its
YOUR responsibility that everything is ok again.
In case that the user uses his backups & restore , its his responsibility to
have a proper and working backup stored on an EXTERNAL device.

Regards
Tom

Because for backup

"Sithu" <cith...@gmail.com> schrieb im Newsbeitrag

news:504db6e5-07cf-4e12...@v15g2000prn.googlegroups.com...

[Sithu]

Thank you, Tom

[Jürgen Wondzinski]

Hi Sithu,

> How can I avoid this error ?

Best for avoiding is: Do not interupt your application ;) Of course we all
know that you can't be responsible for hardware or power failures, thus the
question should be: How to gracefully correct that problem.

In VFP8 and VFP9, there's the new SET TABLEVALIDATE setting, which defaults
to a basic tablecheck at the opening of a table. It compares the stored
recordcounter-value with the physical size of the table on disk. If that
doesn't match, it raises this error. This mismatch is normally 99% of all
table-problems and you can easily fix this:

*------------------------------------
FUNCTION RepairTable( cTableName )
*------------------------------------
LOCAL nOldSet
nOldSet = SET("TableValidate")
SET TABLEVALIDATE TO 0
TRY
USE cTableName EXCLUSIVE
APPEND BLANK
USE
USE cTableName EXCLUSIVE
GO BOTTOM
DELETE
PACK
USE
CATCH
MESSAGEBOX("Cannot repair table "+ cTableName,64)
ENDTRY
SET TABLEVALIDATE TO nOldSet
ENDFUNC
*------------------------------------

Notice the PACK, which ensures that all memos and indices are also
rewritten. This is a MUST-HAVE after any table corruption, since you can't
be sure what part of information was already written to disk when the
failure happened

--

wOOdy
Visual FoxPro Evangelist
Microsoft "Most Valuable Professional" 1996 to 2009

"*��)
�.���.�*��) �.�*�)
(�.��. (�.�` *
..�`.Visual FoxPro: It's magic !
(�.�``��*

[Sithu]

Thank you Wondzinski.

I didn't test your solution. I'm sure that it will be useful.
But, your solution can cause auto-increment value changes after APPEND
BLANK and PACK.

Is there VFP command to handle auto-increment start value of a table ?

With Regards,
Sithu.