unzap works with fp2.6 why not vfp7

[teering]

microsoft support has the following unzap function which i tried and tested on a fp2.6 database - it worked just fine to recover the zapped data, however on vfp7 it puts garbage in the data fields - anyone know what the difference would be here?

from

http://support.microsoft.com/kb/135905/en-us/

FUNCTION UNZAP
PARAMETER Y
IF Y>0 .AND. USED()
IF RECCOUNT()=0
FILENAME=DBF()
USE
HANDLE=FOPEN(FILENAME,2)
IF HANDLE>0
BYTE=FREAD(HANDLE,32)
BKUP_BYTE=BYTE
FIELD_SIZE=ASC(SUBSTR(BYTE,11,1))+(ASC(SUBSTR(BYTE,12,1))*256)
FILE_SIZE=FSEEK(HANDLE,0,2)
BYTE8=CHR(INT(Y/(256*256*256)))
BYTE7=CHR(INT(Y/(256*256)))
BYTE6=CHR(INT(Y/256)-IIF(Y/256>256,(INT(INT(Y/256)/256)*256),0))
BYTE5=CHR(MOD(Y,256))
BYTE=SUBSTR(BYTE,1,4)+BYTE5+BYTE6+BYTE7+BYTE8+SUBSTR(BYTE,9)
=FSEEK(HANDLE,0)
=FWRITE(HANDLE,BYTE)
=FCHSIZE(HANDLE,FILE_SIZE+(FIELD_SIZE*Y))
=FCLOSE(HANDLE)
ENDIF
USE &FILENAME
ENDIF
ENDIF
**to run type in the command window the following
set procedure to lowlevel.prg
set resource off
use databasename exclusive
=unzap(xx) **where xx is number of records to unzap




Teresa Pickering
Professional Computer Services

 

[mspratt]

Hi Teresa,

"Sometimes, Microsoft Visual FoxPro's ZAP command can be reversed and you can retrieve all the records by using a low-level file I/O. This method works only if the data was not overwritten by other files. The approximate number of records to retrieve is also important."

Doesn't take long for some disk write to overwrite your dbf.

Regards,

Mike

 

[mspratt]

BTW, Where was the dbf you are trying to recover located? If on a Novell server you may be able to use Novells' Salvage command.

Regards,

Mike

 

[teering]

the database was located on a stand alone workstation on the c: drive, after it was zapped i immediately put a 'do not use' sign on it so no one has written anything to the hard drive yet


Teresa Pickering
Professional Computer Services

 

[GriffMG]

Teresa,

Assuming that you don't have a back-up and the structure hasn't been changed lately...

You are going to have to use an 'undelete' program - but, you will need to extract the Hard Drive and put it in another machine - otherwise installing the new program (possibly even booting the PC) will risk overwriting the data.

Come to that, how did you run the code above?


Regards

Griff
Keep [Smile]ing

 

[Olaf Doschke]

Hi Griff,

I'd say the typical undelete software cannot work here, because the new zapped file has the same name as the old one. I might be wrong, but as far as I know that makes it somewhat impossible to find the old file.

Additional to this, I think microsofts unzap code already has done unrecoverable damage. Besides that, I think the structure of a database table header differs from a free table header. Information of the recordlength should better be retrieved by RECSIZE() and headersize by HEADER(), then you may be able to compute the filesize needed for Y records... The reccount information in the header can be repaired by APPEND BLANK, DELETE NEXT 1. To open the "damaged" table you should SET TABLEVALIDATE TO 0.

Bye, Olaf.

 

[mspratt]

Additionally, If the table was a large one it was spanning many clusters. FCHIZE() will allocate the first available clusters, which may not be the clusters needed.

Is the first portion of the data OK and then junk?

Regards,

Mike

 

[teering]

thanks everyone for your input
i believe the microsoft unzap function did probably damage the file itself when i ran it - as did creating and saving the function also probably changed the hard drive dynamics
it was a file of about 200 records - of course no one had backed it up, so lesson learned the hard way
thanks again


Teresa Pickering
Professional Computer Services