Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Table has become corrupted
Message
 
 
À
12/10/2011 10:35:58
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Divers
Thread ID:
01526139
Message ID:
01526472
Vues:
63
Which tool are you using for reparing tables? I have used FoxFix and there is a command that let's you check if a table has become corrupted.

What we did (we had a similar problem many years ago) we made a procedure to check each table if it has become corrupted. We called this function at startup of the program, and it goes quite fast. If one table was found that was corrupted, the program opened a form where the user get's informed of the corrupted table and a button on the form to fix the table(s).

Since you need exclusive access to the table for fixing them, you have to put some messaging on the form like "You need exlcusive access t the database, make sure all users are logged off before reparing the tables."

I just found the old code, it worked something like this (as you see we used some messages here but you can change that):
*NAME:			.Filefix()
*CALLED BY:		.oFileDict.CheckOrRepair() and other places.
*FUNCTION:		To check for file corruption and repair.	
*DATE:			06/12/2001.
*
LPARAMETERS	tnRepair, tlShowMessage
*
LOCAL	llRetVal, ;
		lnFixRetVal, ;
		lnCheckRetVal
*
llRetVal = .T.
*
*-- Load library if not loaded already.
IF !"FFIX4_50.FLL" $ UPPER(SET("LIBRARY")) 
	SET LIBRARY TO FFix4_50.FLL ADDITIVE
ENDIF
*
WITH THIS
	*-- First we always check.
	lnCheckRetVal = FIXDBF(.TablePath + .TableName + ".DBF", 0)
	*
	DO CASE
		CASE lnCheckRetVal = 0
			*-- No problem with the file, no message.
		CASE lnCheckRetVal < 0
			IF tlShowMessage = .T.
				*-- File could not even be opened.
				.oUtils.DoMessage(.TableName + ;
					CHR(13) + TRANSFORM(lnCheckRetVal) + " " + L("File could not be checked."), ;
						"*OK*", "X")
			ENDIF
			*
			llRetVal = .F.
		CASE lnCheckRetVal > 0 AND tnRepair = 0 
			IF tlShowMessage = .T.
				*-- Corrupted, and just checking.
				.oUtils.DoMessage(.TableName + ;
					CHR(13) +  L("Corrupted file, corruption code: #") + ALLTR(STR(lnCheckRetVal)), ;
					"*OK*", "X")
			ENDIF
		CASE lnCheckRetVal > 0 AND tnRepair = 1 
			*-- Corrupted, and to be repaired.
			lnFixRetVal = FIXDBF(.TablePath + .TableName + ".DBF", 1)
			*
			IF lnFixRetVal = 0
				IF tlShowMessage = .T.
					*-- So it has been repaired.				
					.oUtils.DoMessage(.TableName + ;
						CHR(13) + L("Corrupted file, corruption code: #") + ALLTR(STR(lnCheckRetVal)) + ;
						CHR(13) + L("File has been repaired."), ;
							"*OK*", "!")
				ENDIF			
			ELSE				
				IF tlShowMessage = .T.
					*-- So it has not been repaired.				
					.oUtils.DoMessage(.TableName + ;
						CHR(13) + TRANSFORM(lnFixRetVal) + " " + L("File could not be repaired, code: #") + ALLTR(STR(lnFixRetVal)), ;
						"*OK*", "X")
					*-- Failed.
					llRetVal = .F.
				ENDIF
			ENDIF
	ENDCASE
ENDWITH
*
RETURN llRetVal
>Hi friends:
>
>I have a client who has a single net (XP) and from time to time system "jumps" (quit violently) and the most common problem is a corrupted CDX. Today was a table. As it is a movement table they hadn't been able to continue working if I hadn't been here...
>
>If the problem is a CDX I can solve it with VFP commands and functions. For tables I bought a "third-party repair utility " as VFP's help says. That's how I could repair it today.
>
>I think I'll be able to sleep tonight but I don't want to say "You can't make any sale note before I arrive by steping the red carpet you must deploy for me..."
>
>Repairing tables using the "third-party repair utility" is quite easy and I know there are several Apostles of "Universal User Instructions Church" but most of my clients has a different religion. One of their Commandments is "I don't pay you for arranging system problems by myself"
>
>Among so much marvelous low level functions you can find here, do you know one which is able to solve this kind of problem? (I mean corrupted tables, not religious clients)
>
>Thank you.
>
> Héctor
Christian Isberner
Software Consultant
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform