Hi,
I've a table containing a Image-Field. Some records are stored compressed (TMSQuery.CompressedBlobMode=cbServer) and others not (CompressedBlobMode=cbNone) according to the extensions of the files (.zip, .tif, .. are not compressed, .doc.rtf... are compressed). For backup-purposes I would like to write the contents of the image to files (read the table into a virtualtable and save the virtualtable to disk, creating more file). The restore will be done with TMSLoader-component. Now my question: can I read and write the contents of the image-field as it is stored in the table of the database, without decompressing or recompressing it? Would be like reading / writing it with a TADOQuery which doesn't know anything about SDAC-Compression? But I wouldn't like to create a ADOConnection/ADOQuery.
I hope my request is not to confused.
best regards.
Toni
Compressed and uncompressed data
Hi Dimon,
This would be a workaround but not a solution for my "problem". The disadvantages are severals: first for every record it creates a "insert into field1..fieldn values (val1, .. valn)" and this is a large overhead, second when I tried it with very large Image-fields (a mix of compressed and not compressed in the same table) sometimes it enters in and endless loop and other times I receive an Access violation. And last, if you have a varchar-field containing a #13, the created sql-line goes ahead (see bottom sample). Therefor at this moment the TMSDump is useless for me.
If there is no way from part of SDAC to access the compressed stream of a blobfield I will look to resolve it reading the data through an adoQuery.
best regards
Toni
--there is a break between 'legale' and 'cartolina'
INSERT INTO attributo(ID, PROP_SOGG, PROP_PRATICA, NOME, PROP_LIBRO, PROP_DOCUMENTO, PROP_OPERA, PROP_EVENTO, PROP_F23) VALUES (144, 1, 0, 'Legale
cartolina', 0, 0, 0, 0, 0);
This would be a workaround but not a solution for my "problem". The disadvantages are severals: first for every record it creates a "insert into field1..fieldn values (val1, .. valn)" and this is a large overhead, second when I tried it with very large Image-fields (a mix of compressed and not compressed in the same table) sometimes it enters in and endless loop and other times I receive an Access violation. And last, if you have a varchar-field containing a #13, the created sql-line goes ahead (see bottom sample). Therefor at this moment the TMSDump is useless for me.
If there is no way from part of SDAC to access the compressed stream of a blobfield I will look to resolve it reading the data through an adoQuery.
best regards
Toni
--there is a break between 'legale' and 'cartolina'
INSERT INTO attributo(ID, PROP_SOGG, PROP_PRATICA, NOME, PROP_LIBRO, PROP_DOCUMENTO, PROP_OPERA, PROP_EVENTO, PROP_F23) VALUES (144, 1, 0, 'Legale
cartolina', 0, 0, 0, 0, 0);
The CompressBlobMode property is used to store values of BLOB fields in compressed form. When CompressBlobMode = cbServer, values are compressed before passing to the server and stored on the server side in compressed form.
On using cbServer or cbClientServer data on the server side is stored as compressed. Other applications can add records in uncompressed format but can't read and write already compressed data. If compressed BLOB is partially changed by another application (if signature was not changed), SDAC will consider its value as NULL.
SDAC doesn't return data in compressed form.
On using cbServer or cbClientServer data on the server side is stored as compressed. Other applications can add records in uncompressed format but can't read and write already compressed data. If compressed BLOB is partially changed by another application (if signature was not changed), SDAC will consider its value as NULL.
SDAC doesn't return data in compressed form.