Thanks for looking into this for us.

I am slightly concerned that, even though this definitely seems to be
a bug in Quickdesk (Sorry, IB Manager as it likes to be called now!),
this has happend without the aid of Quickdesk. Unfortunately, I
cannot reproduce this as easily as I can with Quickdesk, but the same
problem happened a couple of times after a backup/restore, but not
with any regularity.

Is there anyway of silently handling the exception within the driver?
This problem seems to be handled in Interclient and other Database
connectivity drivers we use (e.g Easysoft Interbase ODBC Driver).

Cheers,

Jonathan Handford

--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:

> > Yes! the programmer was using IB Manager. We couldn't use that

table

> > updating the blobs fields to a empty string, even rebooting the
> > server. We had to drop the table and recreate it.
>
> I did some tests with a sample database provided by Jonathan. IB
> Manager (aka Quickdesk) sets the blob ID to 0, but does not set a

null

> flag of that field (which does not happen if they use "UPDATE

my_table

> SET blob_field = NULL WHERE CURRENT OF my_cursor").
>
> I checked engine sources whether blob ID 0 is valid. ID of the blob
> that is being read from the valid database cannot be 0x00000000.

First

> 4 bytes (in whatever endian) are relation ID and cannot be 0x0000.
> This means that Quickdesk corrupts database by setting the blob ID

to

> 0 and not setting the null flag (XSQLVAR.sqlind field).
>
> I do not know what component set they use and if this is a bug in
> Quickdesk or component set, but you can try to report them about

this bug.

>
> Best regards,
> Roman Rokytskyy