Help! Extracting Images from Paradox 1

[campc]

Hello everyone - I'm an entry level engineer working on a Data Conversion. My source database is Paradox ver 11. I have been able to get all tables over to SQL Server quite easily and have written my scripts and things have been all good & happy... exxxxcceeeepppt for one table.

This table is one that has BLOBs (binary large objects) stored in them. There are two BLOB fields - a BLOB Graphic field and BLOB binary. I am fairly unfamiliar with Paradox in general. But I have three files to work with in this table. Let's call the table "Image".
The actual table is Image.DB obviously.
From what I can see Image.MB is some sort of way to store the Images or to reference them. This is a large file of 220 MB - much bigger then the .DB.
And I also have Image.PX which has something to do with Merging records I believe. I could be wrong.

Anyway - I've been having great difficulty figuring out how to extract photos from this table... and was wondering if anyone has any insight. Thank you.

-C

 

[campc]

After further research...
I see that part of these binary memo fields are stored in the .DB file. The rest is referenced in the .MB file. How can I access this .MB file so I can export these images outside of Paradox?

 

[TonyMcGuire]

The .px file is the primary key info.

For the image field, use a script and a variable of 'graphic' type.

Send a tcursor scanning the table, and use the graphic variable to read the field data, and then to write to an external graphic file.

You can do the same with a binary variable; but you'd likely want to know what that binary data type is so you can write it with a proper extension.




Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[campc]

I'm not used to scripting under Paradox... what would the correct syntax be when using Tcursor?

 

[TonyMcGuire]

var
tc   tcursor
img  image
bn   binary
endvar

tc.open(":alias:images.db")
scan tc :
  img=tc."fieldname" ; field containing graphic
  img.writetofile("path\\imagename.ext") ; .ext likely .jpg/.gif/.etc
endscan
tc.close()

; same with bn
; not tested - off the top of my head




Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[jlockley]

Let us suppose that half of the records have graphic or binary records and the other half don't. Using this situation would it be possible to export rather than extract the fields for import into another database format?

 

[campc]

thanks for the start - I think this should help

 

[TonyMcGuire]

jlockley: You can't *export* graphic OR binary data. Manually, or with code is the only way.

A good point about not having data in a particular field/record though. You need to trap for that situation.


Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[campc]

In that script theres only one output file for the image. There are lots of records in the table. are they all being drawn out to that single .jpg/.gif file?

 

[TonyMcGuire]

Yes, you need to name them individually in the code - as they are being written.

I provided a framework, not a complete solution.




Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[jlockley]

One always hopes. Thanks. Locked into Paradox forever, I fear.

 

[campc]

Tony thanks for all your help. So now when I'm running my script I get the JPG's to output - all of them are of size 0 Kb and obviously contain no picture. Would this be something wrong with my script or a result of corrupt graphic data?

c

 

[TonyMcGuire]

Well, I'm going to guess your script. Which means it could be my fault, as well.

Can you open the table, and scroll through it looking at the graphics? You should be able to.

You have to be on the graphic field, and may need to double-click the field if you don't have 'Complete Display' checked in the field properties.




Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[campc]

Interesting...
No you can't see the graphics by scrolling through the table. When you double click on a record it is blank. When I check off complete display all the records are blank as well.

I know the database is not corrupt though because the source application can display these images fine. Unfortunately I do not have any access to the source code since I'm dealing with an out of date application - No one even wants to try and find the guy that originally wrote the thing.

I digress...
Maybe the images are just being constructed soley from the binary fields???

 

[TonyMcGuire]

Yes, that is possible.

In which case you do the same thing as in the code I sent, but use the binary variable.

Bad thing is, you probably don't know what TYPE of image.

I'd write to .bmp extension with the graphic var.

Then with binary var I'd probably try .bmp, then .jpg, then .gif.




Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[campc]

I'm starting to get somewhere with this. The files have some substance and size - If I open them up in wordpad i can see that something is being extracted...

With that said - I still can't view the images. I've tried every image format that I could think of off the top of my head and none seem to put together a valid image.

I'm not sure where else I should go with this - suggestions?

 

[TonyMcGuire]

Well, you MUST find out what format they are in when using the binary extraction. IF they are even graphic images; ANY type of binary info can be put into those fields.

You should be able to write the images to .bmp format from the graphic type, regardless. That is the format they are stored in, in the graphic field type.

Another option might be to copy/paste manually, one image at at time, from a form or tableview. If you have very many, though, this could be really tedious and tiresome.





Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.