faq.txt

TCompress Component Set For Delphi Kylix BCB v9.0

See the question above. Some files have data which is already so complex that
they won't compress significantly, or at all. If you have coLZH5 set as your
CompressionMethod, you should get roughly the same level of compression as
common compression utilities will give you -- sometimes better.

* Why don't "protected" Paradox tables compress well with TCompress?
When you protect a Paradox table, the entropy or "randomness" of its data
increases significantly -- so much so that all compression algorithms become
much less efficient. You'll encounter this whether you use TCompress or any
other common compression utility.

* Is there a routine or component to auto-compress entire records within a
  database?
No. TCompress provides file-level compression (e.g. the entire set of
database files into a single archive) and TCDBMemo etc. provide blob-level
compression (e.g. autocompressing memo, image or binary fields in your
database). There isn't a way to compress entire database records and still
provide the kind of fast indexed random access which most databases require.

* Is TCompress thread-safe?
Yes, the code can be used in multi-threaded applications. To use it effectively, you need to create an instance of the component within each
new thread -- as per the example code in the CompDemo sample application.

* Is TCompress Year-2000 compliant
Yes. No date-based calculations are performed, and all date storage formats
used are compliant with Windows definitions, which support four year digits.

**** How To:

* Can I seek into the middle of a compressed file and decompress just part of
  it?
Generally speaking, no compression method will permit this. However, it can
be "faked" in either of the following ways:
1. Decompress the entire file into a temporary TMemorystream, then use the
TStream seek and read methods to access any part of it. This is not useful if
the file is huge of course, but decompressing to a temporary TFilestream
instead might be viable for some situations.
2. Instead of compressing it as a single file, compress it as a series of
"chunks" or file segments, all stored in a multi-file archive (each chunk can
be given a name in the archive which is its number, e.g. "1", "2" etc). With
this approach you can randomly select any chunk and decompress it
individually. For performance-critical applications, also see the question
below on speeding up access to multi-file archives.

* Does TCompress handle updates and deletions from an archive nicely, or does
  it leave "holes"?
If the standard CompressFile(s)/DeleteFiles/ExpandFile(s) methods are used,
archives are rewritten to eliminate holes and remove old files. You can
bypass or delay this archive rewriting process if you want by using routines
like CompressStreamToArchive.

* How do I use TCompress/TCDBMemo etc. if I have a Data Module in my
  project?
Put the TCompress object on your Data Module with your tables. Any CDBMemo
etc. objects should still  be on the appropriate form(s) of course.

* How can I speed up access to files in an archive?
For small archives, this is hardly necessary --- finding and decompressing
any file is generally very fast. But if your archive gets very large, the
sequential search needed to find a given file to decompress it can be a time-
waster. A solution to this is to use ScanCompressedFile once when you
first access your archive (as the Compdemo example application does). This
process also creates a TCompressedFileInfo object for each file containing
its position in the archive. With that information, you can open the archive
as a TFileStream, seek directly to the appropriate place and use the DoExpand
method to expand just that file. Time savings on large archives by using this
method can be very significant indeed.

* How can I compress a string in memory?
Use the CompressString and ExpandString methods.

* How can I read string data and compress it into a blob field?
The simplest possible way is to use CompressString, then store that in the blob as binary data. However, this means you'll have to take care of the reading and expansion process yourself as well.

A better way might be to use the visual CDBMemo component and simply use its LoadFromFile method to load the strings. If its compression properties are correctly set, it will auto-compress the data when the record is posted.

If you want to do it non-visually (e.g. on a data module), do as follows:

a) Create a non-visual TCBlobfield component on-the-fly and point it at your existing memo field (see BLOBMAIN.PAS for an example of this).

b) Set its CompressSource and CompressionMethod properties appropriately

c) Then step through each record of the table doing this:
edit;
OurBlobField.LoadFromFile(yourExternalFilename);
post; { write back, forcing it to compress as it is written }

Note that other handy assignment methods are available, including LoadFromStrings. If you want to compress existing uncompressed data in the memo, just assign the field to itself so that it is marked for updating, e.g. OurBlobField.asString := OurBlobField.AsString (good in Delphi 2 and 3 -- in Delphi 1 you'll have to SaveToStrings into a TStringList, then LoadFromStrings back again).

**** Problems (also see the Troubleshooting section of Compress.hlp):

* I compressed a file using TCompress, but I can't seem to decompress it. Why
  not?
There are two likely reasons:
1. You have your parameters round the wrong way when calling the ExpandFile
method. Sensible parameter naming will help you avoid this, e.g.
ExpandFile(StoredFilename, ArchiveFilename).
2. You are not specifying the correct StoredFileName. It should match the
filepath which is stored in the archive -- which can be double-checked by
using the Compdemo program. Review the Compress.hlp help sections on
TargetPath and "Filename Handling in Compressed Archives" to see some
examples of how to control what filenames and paths are stored in the
archive.

* I compressed something into a stream, but I can't seem to expand it.
  Why not?
Don't forget to either close and reopen the stream or (more commonly)
seek back to the beginning of the stream before trying to expand from it!
Also check that the stream FROM which you compressed the data had been
positioned to the start before you compressed it. The Compress and Expand
methods both work from the CURRENT stream location...

* How do I eliminate the registration popup message? Is any other
functionality affected in an unregistered copy of TCompress?
When you register TCompress, you will be given values to set into the RegName
and RegNumber properties of your TCompress components. If you set these
exactly as provided to you, they will eliminate the popup. Apart from the
popup message, unregistered copies of TCompress behave exactly the same as
registered ones.

* My application says "Requires BDE" when I run it on another machine. Does
  TCompress require the Borland Database Engine?
No. If you are not using the database blob compression components (CDBMemo etc),
then you don't need the BDE. Just be sure that your project units
don't have any unintentional references to "DB" or "DBTables" etc. in their
Uses clauses. Also make sure you have the "comp" package rather than the compdb package installed, as the latter "requires" the BDE package.

* Do you have any demo programs written specifically for C++ Builder, or are
  they all Delphi?
At this point, all the demonstrations are in Delphi but we've provided C++ compatible project header files so they can be checked under C++ Builder.

* What should I do if I get an "Out of Memory" message using TCompress?
This is exceptionally rare and will only arise if physical or swapfile memory is limited -- free up more disk space on your Windows swap drive.

* My application's memory use seems to increase every time I decompress
  files. Why?
If you are using the ScanCompressedFile or ScanCompressedStream methods,
see the notes in their section of Compress.hlp about the TCompressedFileInfo
information and the FreeFileList method, which will allow you to eliminate
memory loss.

* What should I do if I see an "EUnableToCompress" exception?
Nothing, unless you are directly calling the DoCompress method (see the help). All other methods handle this exception internally, meaning that the only time you'll see this exception is if you have "Break On Exception" turned on in the IDE.

* How do I fix a "transliterate error" with TCDBMemo and Interbase blobs
This error is caused by the usual Interbase memo field SQL definition
that sets the blob's data sub-type to "1", which can only be used
for text. Consequently, the highly varied characters used in a
compressed file are rejected. The fix is to amend your SQL to
create a blob field with sub-type of zero, which is a binary blob, e.g.
ALTER TABLE TEST_ONE
  ADD TEST_TEXT BLOB SUB_TYPE 0 SEGMENT SIZE 80;
Thanks to Charlie Savage of Atkinson-Baker for this report.


</pre>
<P>Return to <A HREF="http://www.spis.co.nz/compress.htm">TCompress</A>