Hi All,

I am a newbie to the Btrieve file architecture and looking for help on
how to retrieve the blob data stored in the BTR files. I did some
Google search regarding this and didn’t find articles that point me in
the right direction. I learned a lot regarding the btrieve structures
and pervasive. Below is the information of the current system i am
working on.

Using Pervasive.SQL 8.x work group edition.

Scanned Documents (Images) are uploaded into a BTR (don’t have the
source code to look at)

Looked at the DDR for table definition - only the filename and file
length columns were there.
The file statistics say that the version is 6.x.

Exported the data into SDF - Got a file with filename and file length

Exported the data into UNF - Got a file with File length, filename-
entire binary data of the record

Split the UNF file for the first record and tried to convert it back
to image. This is where I am having issue with. The image is not being
converted properly.

I am not sure if this is the right way of doing this. I would
appreciate if anyone can guide me in the right direction to retrieve
the documents back to the original format. Can anyone provide me with
a sample code?

Thanks in Advance for you help.

The UNF file contains the UNF header (the record length and comma),
followed by the remaining bytes from the record structure, followed by a
CR/LF pair.

So, export your first record this way, strip off the UNF header (up
through the comma), then remove the filename and length columns, and
then truncate the CR/LF pair at the end. Note that you MUST use a hex
editor (like Hex Workshop) to avoid making major changes to the data
structure.

You may also be able to read the data directly via the Btrieve
interface. However, this is only simple for records up through 64K in
size. Beyond that, you'll have to use "chunking" operations, which are
a bit more complicated.

Of course, it is ALSO possible that the application that stores the data
modifies it in some way, making it unusable. Some applications store
data in OLE format, which is quite different from a simple JPG memory
dump or PDF.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


golisatish (AT) gmail (DOT) com wrote:

The UNF file contains the UNF header (the record length and comma),
followed by the remaining bytes from the record structure, followed by a
CR/LF pair.

So, export your first record this way, strip off the UNF header (up
through the comma), then remove the filename and length columns, and
then truncate the CR/LF pair at the end. Note that you MUST use a hex
editor (like Hex Workshop) to avoid making major changes to the data
structure.

You may also be able to read the data directly via the Btrieve
interface. However, this is only simple for records up through 64K in
size. Beyond that, you'll have to use "chunking" operations, which are
a bit more complicated.

Of course, it is ALSO possible that the application that stores the data
modifies it in some way, making it unusable. Some applications store
data in OLE format, which is quite different from a simple JPG memory
dump or PDF.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


golisatish (AT) gmail (DOT) com wrote:

The UNF file contains the UNF header (the record length and comma),
followed by the remaining bytes from the record structure, followed by a
CR/LF pair.

So, export your first record this way, strip off the UNF header (up
through the comma), then remove the filename and length columns, and
then truncate the CR/LF pair at the end. Note that you MUST use a hex
editor (like Hex Workshop) to avoid making major changes to the data
structure.

You may also be able to read the data directly via the Btrieve
interface. However, this is only simple for records up through 64K in
size. Beyond that, you'll have to use "chunking" operations, which are
a bit more complicated.

Of course, it is ALSO possible that the application that stores the data
modifies it in some way, making it unusable. Some applications store
data in OLE format, which is quite different from a simple JPG memory
dump or PDF.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


golisatish (AT) gmail (DOT) com wrote:

Bill,

Thank you for the quick response and pointing me to use the HEX
editor. I was able to retrive the BOLB images. There is a lot of
Manual work involved to clean up the files using HEX editor but No
Complains.


once again THANKS A TON.

Bill,

Thank you for the quick response and pointing me to use the HEX
editor. I was able to retrive the BOLB images. There is a lot of
Manual work involved to clean up the files using HEX editor but No
Complains.


once again THANKS A TON.

Bill,

Thank you for the quick response and pointing me to use the HEX
editor. I was able to retrive the BOLB images. There is a lot of
Manual work involved to clean up the files using HEX editor but No
Complains.


once again THANKS A TON.

If you're a programmer, then it should be easy: Read in the record
length first (up to the comma). Then, read THAT number of bytes for the
record image. Write out the data that you just read in, skipping the
first set of bytes that comprise the data header (filename, etc.) to the
target file. Finally, read the next two bytes (the CR/LF pair).
Loop until you hit EOF.

golisatish (AT) gmail (DOT) com wrote:

If you're a programmer, then it should be easy: Read in the record
length first (up to the comma). Then, read THAT number of bytes for the
record image. Write out the data that you just read in, skipping the
first set of bytes that comprise the data header (filename, etc.) to the
target file. Finally, read the next two bytes (the CR/LF pair).
Loop until you hit EOF.

golisatish (AT) gmail (DOT) com wrote:

If you're a programmer, then it should be easy: Read in the record
length first (up to the comma). Then, read THAT number of bytes for the
record image. Write out the data that you just read in, skipping the
first set of bytes that comprise the data header (filename, etc.) to the
target file. Finally, read the next two bytes (the CR/LF pair).
Loop until you hit EOF.

golisatish (AT) gmail (DOT) com wrote: