Dear All,

Just upgraded to V4 pretty successfully, very happy so far ...

Just noticed that V4 supports COMPRESSION of BLOB / MEMO fields.

I have a fairly large table (about 500 mb BLB file) most of which is text. I would love to
compress this, as the file has to be backed up every day for auditing purposes ... which
is time-consuming.

Are there any issues with Compression in terms of reduction of the transparency of the
data, or additional risks of data loss if the table is corrupted etc.

I am like to to maintain the transparency / openness of my data & to keep it easy for
migration / export /development.

I worry that using a compression mechanism that may be specific to DBISAM & might leave me
with data I can't retrieve in case of some sort of table corruption problem.

Adam

PS: Also, are there any performance implications with COMPRESSION ...

Adam

Sorry to be a pest of a poster ... but 1 more thing.

I have just test compressed 3 tables: 1 with 500mb of TEXT BLB, 1 with about 20mb of TEXT
& 1 with about 30mb of JPG images.

The 500mb table compressed down to about 210mb of compressed BLB.
The 20mb table "compressed" to 19.6mb (!!)
The 30mb of JPGs didn't change at all. (Actually I wasn't surprised by this as the JPG
format is pretty efficient to begin with).

--

Any clarification:

1. Does the compression only kick in for larger sizes of file?? (i.e. why was the smaller
TEXT BLB not very effected).

2. If so, would I see any improvement on a really massive JPG library (i.e. 100s of mb).

... Sorry to be a post-pest.

Adam

Adam,

<< Are there any issues with Compression in terms of reduction of the
transparency of the data, or additional risks of data loss if the table is
corrupted etc. >>

There is a slight additional risk of data loss if there is corruption due to
the fact that any missing/corrupted BLOB blocks will render the entire BLOB
unusable.  Other than that, however, there is no downside.

<< I worry that using a compression mechanism that may be specific to DBISAM
& might leave me with data I can't retrieve in case of some sort of table
corruption problem. >>

DBISAM uses standard ZLib compression.  However, having your data in DBISAM
format kind of prevents you from just "extracting" it at will.

--
Tim Young
Elevate Software
www.elevatesoft.com

Adam,

<< PS: Also, are there any performance implications with COMPRESSION ... >>

There's additional CPU consumption, but it is normally outweighed by the
time savings in terms of disk I/O.

--
Tim Young
Elevate Software
www.elevatesoft.com

Adam,

<< 1. Does the compression only kick in for larger sizes of file?? (i.e. why
was the smaller TEXT BLB not very effected). >>

Because DBISAM uses blocks for dividing up a BLOB file, and each record in
the table probably only used one block per BLOB anyways.  IOW, the minimum
size used for any BLOB is the block size, even with compression enabled.

<< 2. If so, would I see any improvement on a really massive JPG library
(i.e. 100s of mb). >>

JPEGs will never really compress particularly well using the BLOB
compression, so I wouldn't even try and would leave them uncompressed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

Thanks for these really useful comments. I have been testing my tables with BLB fields
compressed & am *really* impressed.

The app runs faster (!!) ... I guess because compressed data is being set down the wire
(??) & of course the foot-print of the table is smaller, meaning that various other
processes are easier for the user ... the tables that did not show improvements with
compression were ones where the BLB fields were only being used for short sections of text
... exactly as you said, compression only improves things if the fields are large to begin
with.

I finally took the plunge & installed V4 about 1 week back (having purchased it about 3
months back), expecting to have to work for a couple of weeks to generate something
useable out of a big old V3 app ... after 2 days work (mostly rewriting SQL to change
double-quotes to single-quotes) I have an app I can release for my customer ... & it runs
a good deal faster.

(

Adam

Adam,

<< Thanks for these really useful comments. I have been testing my tables
with BLB fields compressed & am *really* impressed. >>

Compression can certainly help, if it is used wisely.

<< I finally took the plunge & installed V4 about 1 week back (having
purchased it about 3 months back), expecting to have to work for a couple of
weeks to generate something useable out of a big old V3 app ... after 2 days
work (mostly rewriting SQL to change double-quotes to single-quotes) I have
an app I can release for my customer ... & it runs a good deal faster. >>

I'm glad that V4 is working well for you.  It should prove to be a big
improvement over V3.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

Tim,
   I guess if the table is encrypted then there is no savings in using
compression, correct?

TIA
Sam

Hi Sam,

Unless I am mistaken, the compression is done first, and then the encryption
so there will be savings with
encrypted tables as well.

--
Best regards

Steve

"Sam Davis" <sammyd432@yahoo.com> wrote in message
news:FC9B2FEC-9158-4379-A423-DB5F297BE3A5@news.elevatesoft.com...
> Tim Young [Elevate Software] wrote:
>
> Tim,
>    I guess if the table is encrypted then there is no savings in using
> compression, correct?
>
> TIA
> Sam