compressor error

[Bernard Devlin]

On Fri, Jan 15, 2010 at 2:08 PM, Ruslan Zasukhin
<ruslan_zasukhin at valentina-db.com> wrote:
> If you use MODE of db with 4 disk files,
> Then you can not put into ZIP archive the .ind file.
> It will be created automatically on open of db here.

Hi Ruslan,

I've identified the file that corresponds to the record identified in
the bug report.  It is the largest of the files (around 15mb).
However, even in a zipped db with just that record, and the .ind file
deleted, the zip file is 8mb.  So I cannot submit this db to mantis.

Eliminating the records where the records came from files > 8.2mb in
size there are no compressor errors. Creating the most simple test
database to demonstrate the problem (containing the text from 1x9mb
file plus the text of 1 small file that causes no problem) still
results in a zip file of 4.3mb (even excluding the .ind file).

Thus it seems that submitting to you a database that exhibits the
error is not possible, given the limitation of Mantis to 500kb and
your lack of a ftp server.

I have at least identified for you what seems to be the blob size
limit where your compression mechanism is failing.  Is there a
document specifiying the limitations of Valentina?  I would assume
that as part of your automated testing you would try inserting blobs
of various sizes.

Another bug I've found is that VStudio in Data Editor mode will
display incorrect values when there is a document which has a
compressed text field whose length > 8.2mb.  With just 2 files in the
database (one that will cause the compressor error, one that won't),
the Data Editor is showing the same details e.g.same ID, same title
for both documents, and no 'compressor error' is registered.  If I
then switch to the SQL Editor and run 'Select id,title from documents'
I get two distinct rows with id and title.  Somehow VStudio in Data
Editor mode is simply ignoring the 'compressor error' and returning
the wrong results.

It's worrying that within a few days of using Valentina I managed to
find bugs in the compression mechanism, and VStudio's Data Editor and
in the 'diagnose' process.   My usage of Valentina in this time has
been very simple:  1 table with a few columns, with inserts and
selects using the SQL API.  I have to hope that other areas of
Valentina have been more thoroughly tested.

That the 'diagnose' process fails in a situation like this is very
bad, requiring a lot of manual trial and error on the part of someone
like me.  If one feature of Valentina absolutely must be robust, it
must be the 'diagnose' process.

It has taken hours of my time to report and isolate these things.  It
would have saved me a whole day if you had been able to accept the
large but simple database that exhibited the problem.  Considering
that I've transferred gigabytes of data across the internet today, I
find it unprofessional that you have no mechanism to accept a 200mb
database, or even a 2mb database.

The cost in my time wasted on this issue greatly exceeds the price I
paid for my Valentina licenses.

Bernard