Automated replacement of a corrupt table

[isaiah25]

I have an app which works GREAT when it's running, but occasionally gets interrupted, and invariably one or more tables get broken as a result. I want to set up a routine that can just go in and "delete, remove, select master, copy stru" these six vulnerable tables and THEN run the regular app.

Could someone PLEASE review my logic and help me fix it.

Apparently my brain is as broken as my code.

********

CLOSE TABLES
CLOSE DATABASES
SET PATH TO "C:\lib\DATA" && Sets path to database
OPEN DATABASE LIBERTY EXCLUSIVE && Open production database
SET DATABASE TO LIBERTY

CLEAR
IF FILE('dlibpcf2.dbf')
WAIT WINDOW 'Target FILE (dlibpcf2.dbf) is present.'
SET SAFETY OFF
REMOVE TABLE dlibpcf2 DELETE
DELETE FILE dlibpcf2.*
SET SAFETY ON
ELSE
WAIT WINDOW 'Target FILE (dlibpcf2.dbf) is not found.'
ENDIF

IF !USED("dlibpcfM")
USE dlibpcfM IN 0
SELECT dlibpcfM
ELSE
SELECT dlibpcfM
ENDIF
CLEAR
DISPLAY STRUCTURE
WAIT 'Structure of the Master table' WINDOW AT 20,20 NOWAIT CLEAR TIMEOUT 10

COPY STRUCTURE TO C:\lib\DATA\dlibpcf2.DBF WITH CDX
SET DATABASE TO LIBERTY
ADD TABLE dlibpcf2

SELECT dlibpcfM
USE

IF !USED("dlibpcf2")
USE dlibpcf2 IN 0
SELECT dlibpcf2
ELSE
SELECT dlibpcf2
ENDIF
CLEAR
DISPLAY STRUCTURE
WAIT 'Structure of the REPAIRED table' WINDOW AT 20,20 NOWAIT CLEAR TIMEOUT 10

SELECT dlibpcf2
USE

CLEAR
?? CHR(7)
MESSAGEBOX("Table dlibpcf2 should be good now.",0,"Dev. Msg.")

CLOSE TABLES
CLOSE DATABASES

 

[Mike Lewis]

At a quick glance, the only minor point I can make is that you don't need REMOVE TABLE .... DELETE and DELETE. The first of those commands should delete all the files asssociated with the table, so the second one is superfluous (but does no harm).

However, a more important point is: why are you doing this? If an interruption in your app causes data to be corrupted, you should be focusing on the reasons for the corruption - and fixing them.

It could be that you need to use transaction processing to protect your data. Or there might be other issues to be resolved. Either way, it's better to remove the problem at the outset.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Besides Mikes answer, which I second, you can also use DROP TABLE, which also removes the files. Also you can use COPY STRUCTURE with it's DATABASE clause, not needing an ADD TABLE. Otherwise you only can work with short field names, as you create a free table only in the first place.

Also it doesn't help much to have a new empty table, does it? Data is lost, so a simple normal backup of an earlier stage of the data would help better than replacing the corrupt with an empty table.

Bye, Olaf.