How to extract binary data from general field

[georg59]

If you store data in a general field vfp adds some data at the end of the file content. Does anybody have an idea how to get rid of this?

I have to extract some binary data from a table with a general field containing binary data from a cad program. The reason is, that general field content is version dependent and the program version this data is created with doesn't exists any more.

I've read the FAQ184-5314 - this was very useful - but it doesn't truncate the data which is stored at the end of the origin file.

Georg Nickel
Germany

 

[bborissov]

Do not use General Fields, never. They maybe looks good in DOS days, but now they are outdated.
Instead of keeping files in General fields just keep path to files in MEMO or other field types. If you insist to keep the files into a table use BLOB fields.

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.
Microsoft MVP VFP

 

[georg59]

Hello Borislav,
thank you for your tip. I know that general fields have many problems. This is the reason why I have to extract the data from the existing tables. My problem is, that hundreds of files are stored in this way and I have to extract this now to
save this existing data basis for future times.

Georg Nickel
Germany

 

[GriffMG]

Georg,

I think Boris means 'use binary memo fileds in future' you have to live with where you are now.

The extraction of files from general fields is a bit haphazard, but it they were all the same type of file originally - it's not beyond you.

Firstly copy each record out to a free table with just one record in it, then the memo field will only contain your single file, plus a few bits and bobs that VFP likes to put in there - in the first instance, use a hex editor to compare an original file with one in the fpt. The idea being to measure the size of the leading data that VFP suffixes the actual file with.

CraigsBoyd posted this code for extracting a bitmap file

LOCAL lcFileString
SELECT "MyTable"
COPY TO tmpTable FIELDS YourGeneralField NEXT 1
lcFileString=FILETOSTR("tmpTable.fpt")
ERASE "tmpTable.fpt"
ERASE "tmpTable.dbf"
lcFileString = RIGHT(lcFileString,LEN(lcFileString) - 599)
=STRTOFILE(lcFileString, "MyExport.bmp"

Note the 599 being deducted from the .fpt file contents, you may need to change this number dependant on your original file type - but it should be consistent across the same file type, I *think*

Regards

Griff
Keep [Smile]ing

 

[GriffMG]

That should have read 'prefixes' not 'suffixes'
B-)

Regards

Griff
Keep [Smile]ing

 

[georg59]

Hello Griff,

thanks a lot but this code does what you said, it read the prefix. The Code in FAQ184-5314 does this also in a good way. But my problem is, that i have to truncate the code behind the data. Foxpro adds a lot of meta information behind the original data. This is what i must truncate, because the application doesn't accept foreign data behind the expected end (of file). The difficulty is, that the end of the application data has no end marker. So how can i determine the end of the application data and the beginning of foxpro metadata?

Georg Nickel
Germany

 

[GriffMG]

Hi

You would need to use the hex editor to work that out, comparing a manually append general field with the original underlying file - to see what was added at the beginning, as shown and the end (which we haven't) it *should* be consistent for the same file type... so if you determined that 599 bytes were prefixing the actual data and (say) 480 were suffixed, you might do this:

LOCAL lcFileString
SELECT "MyTable"
COPY TO tmpTable FIELDS YourGeneralField NEXT 1
lcFileString=FILETOSTR("tmpTable.fpt")
ERASE "tmpTable.fpt"
ERASE "tmpTable.dbf"
lcFileString = RIGHT(lcFileString,LEN(lcFileString) - 599)
lcFileString = LEFT(lcFileString,LEN(lcFileString) - 480)
=STRTOFILE(lcFileString, "MyExport.bmp")

Good luck if you had dozens of file types and many different workstations appending the original files though, it could get messy.



Regards

Griff
Keep [Smile]ing