Hello.

I'm sure I've seen this issue discussed before, but now I cannot find it. So
here is the question:

I have converted several Paradox tables to MS-SQL-tables, and use Paradox as
front-end tool, all with success, except with those tables having a graphic
field type in Paradox. In the SQL, I guess this field type correspond to
"image" type. I have written a test-script in Paradox to copy the graphic
from Pdox to SQL, using tcursors and graphic variables. There is no
errormessage running this, but the graphic will not stick in the SQL table,
or the cannot be retieved back to Paradox.

Anyone who knows a trick or two?

(I use Paradox 11)

Thanks,
Bjorn

Bjorn Sagbakken wrote:

How big is the graphic file? The BDE cannot transfer via ODBC BLOB
files larger than 1000000 bytes.

"Ed Nash" <name (AT) mail (DOT) com> wrote

Oh, the files are quite small. At least some of them, smaller than your
statement for limitation. I ran a tcursor scan that saved the graphics to
jpg-files just to check. But you set me on an idea; maybe there are options
in the BDE for the SQL connection?

Bjorn Sagbakken wrote:

Just to make sure you are using the correct type, have you tried loading
images into your SQL base from a command line, outside of Paradox?
Oracle has a loader program called SQL*Loader for that. I think it is
called "bulk loader" in MS-SQL.

Bjorn Sagbakken wrote:

- There are some things to tweak. I don't have the BDE in front of me
so I can't help much now.

- How are you attempting to post from Pdox to MS-SQL: tcursor directly,
tcursor.add(), table add(), etc? IIRC, I could never get an SQL INSERT
to work so I always did a table (not tcursor) add. Attach a table var
to the remote table and another to a local PRIV table, then add local to
remote.

- Are you first reading the source JPG, using readFromFile, into a BLOB
or GRAPHIC field before attempting to load to the server?

"Ed Nash" <name (AT) mail (DOT) com> wrote

I have tried to post from Pdox to MS-SQL directly with tcursors, one tcursor
pointing to the Pdox table and one pointing to the SQL table; using
insertrecord, copyrecord, and later also copying the imagefield alone, not
the whole record. Tried tcursor.add(), but it fails. I have also tried to
temporary write the graphic content to a file(both bmp and jpg) and read it
back into a graphic variable before inserting this to the SQL-field. Haven't
tried SQL INSERT or table add.
I will check out table add.

Basically the graphic content resides in a Paradox table with GRAPHIC as the
field type, and ideally this should go directly to the SQL, but yes, I have
also tried to readfromfile.

"Ed Nash" <name (AT) mail (DOT) com> wrote

No, haven't tried this yet. I searched some for "bulk loader" but I found no
easy program to do a quick test. Eventually I will use .NET for web-pages,
so I need to figure out how to store images into the SQL from that side
also. Maybe I should just jump into that....

Bjorn Sagbakken wrote:

How about readfromfile into a Paradox BLOB then add the Paradox table to
the MS-SQL table? I have done this before with both MS-SQL and Oracle.
I remember experimenting with the GRAPHIC type and not having luck.
Using a BLOB seems to make the most sense to be because a BLOB just
stores raw bits and all you want to do is move the bits to SQL.

Björn,

Try to use a binary variable instead of a graphic one.

I use readfromfile to get the image into a binary variable and then tCursors
to get it into the MSSQL table.

Anders

On Sun, 12 Nov 2006 10:39:31 +0100, Bjorn Sagbakken wrote:

At the risk of showing my ignorance of most of the topics discussed in this
thread -- are you trying to serve images into web pages? If you are, you
realize that the web page won't contain the bits and bytes of the actual
image, but only the path (URL) to where the image is stored as a jpg, png,
or gif. So maybe you only need to store the images's URLs in your SQL
table, and not the images themselves. All you need to do for the images is
save them as jpegs and load them into a subdirectory on your web site
server, then store the paths to these images in the table.


Jim Hargan