Page 1 of 1
How to avoid encoded blob parameters
Posted: 27.09.2012, 22:39
by tarnschaf
I think (hope) that I have a rather simple question for ZEOS experts: We defined a table for uploading files to a Postgres 8.3 database, currently still with Zeos 6.6.6 stable, protocol "postgresql-8".
Definition of the table looks like this:
Code: Select all
CREATE TABLE files
(
"ID" serial NOT NULL,
"Customer" integer,
"Filename" character varying(60),
"Data" bytea,
CONSTRAINT files_pkey PRIMARY KEY ("ID" )
)
For uploading files, I tried two possibilities:
1. Create ZQuery with am INSERT SQL and named parameters. Load the blob parameter with:
Code: Select all
qryInsert.ParamByName('data').LoadFromFile(filename, ftBlob);
qryInsert.ExecSQL;
2. Create a IZPreparedStatement with an INSERT SQL command, position-based parameters (?). Load the blob parameter into a stream and then:
Code: Select all
PreparedStatement.SetBinaryStream(3, FileStream);
Both approaches work fine - however they encode the binary data into a string like this:
Code: Select all
'\\\\377\\\\330\\\\377\\\\340\\\\000\\\\020JFIF....
This would not be critical if our 10MB images wouldn't be increased about four times when encoded. I searched the forums and found that others manage to send unencoded data - but how?
Posted: 28.09.2012, 01:11
by EgonHugeist
tarnschaf,
Do you use OID Blobs or bytea fields?
You need Zeos7 to get what you want.
Oid-Blobs can be sended in chunks(TZDataSet.Properties.Values['chunk_size'] := xxx) Also can you set TZQuery/TZTable.Options := [coPreferePrepared] and you can access real C-API lightning fast Prepared Statements which can send binary data as is...
No way with 6.6.6 except you use OID blobs. (I hope...)
For both versions: To get OID support add 'oidasblob=true' to the TZConnection.Properties.
Hope this will help you.
Posted: 28.09.2012, 20:22
by tarnschaf
Hi EgonHugeist,
I somehow aniticipated that YOU would reply. Thanks a lot!
The app is using bytea fields and I will have to read into OID blobs. It appeared to me that with the activated options all blob transfers are behaving differently which I didn't want.
Will get back to you as soon as I figured it out! The fast C-Api sounds very promising...
Tarnschaf
Posted: 30.09.2012, 21:11
by tarnschaf
Hi again,
I am experimenting with Zeos 7 to achieve better performance uploading those files. I checked out the trunk/ version from Sourceforge and installed it. Luckily, my application (on first sight) still works as before.
Changing the upload method back to use a TZQuery again and setting the option to soPreferdBla seems to solve the problem - the file is now uploaded as binary which is indeed a lot faster!
However, after upgrading to the new Zeos version I get an EInvalidPointer exception each time I call "inherited Destroy" in the main data view TFrame. The result is that the frame is not destroyed which causes a lot of other exceptions. The frame contains no Zeos components, but a lot of data aware stuff, DataSources that are linked to Zeos in a data module..
Is it neccesary to do some cleanup before destroying data-boudnd components? Is checking out trunk a bad idea?
Thanks for your help,
tarnschaf
Posted: 01.10.2012, 06:16
by EgonHugeist
tarnschaf,
You got Exceptions now? Which revision do you use? Older then 1840?
Can you explain me waht are you doing?
Posted: 01.10.2012, 12:39
by tarnschaf
Hi,
I checked out the latest revision of the trunk. The exception occurs when Free/Destroying a TFrame component. It did not occur with ZEOS 6.6. However, I am not able to reproduce it in a smaller application. The exception is NOT occuring when I remove an (empty) groupbox from the frame.
Thus, it looks to me like a memory corruption that happens on another place (earlier). I will further try to build a small application that reproduces this behaviour and then get back to you.
Posted: 01.10.2012, 14:36
by EgonHugeist
tarnschaf,
I will further try to build a small application that reproduces this behaviour and then get back to you.
Well that's a deal! I must admit i've no clue what could be going wrong....