Helen,

> At 09:37 PM 25/03/2003 +1100, you wrote:
> >I'm worried too if I've been doing the wrong thing.. but I think that after
> >5 years with no unpredicatble results, I need some more convincing that I'm
> >doing something wrong.
>
> If you have been *updating* blobs by passing them as parameters to SPs for
> 5 years, I think that takes us back to IB 5.1, where (I'm told) the
> documentation was changed to say that you couldn't pass blobs as SP
> parameters. This was because of a bug -- that I believe is still present
> in IB 6.0 -- where the blob_id's could get scrambled in record versions and
> the same blob_id could end up referring to two different blobs.
>
> I'm pretty sure the fix for this happened very early in the Firebird betas.
>
> FYI, there is no such thing as "updating a blob". What really happens is
> that an entirely new blob is created --- with a new blob_id --- and the
> original disappears.
>
> And, Thomas S., I'm aware that the UFB duplicates the documentation error
> from the IB 6 docs. It fell off my "fix list" for v.1.1 but it has gone in
> for the next review.

If my previous quote sounded rude or offending, then I apologize,
because this wasn't my intention ;-). I simply wasn't sure whether
there was someting fixed in Firebird or not, and took the quote
from the UFB.

> I'm pretty sure that it's still invalid to use comparison operators on
> pairs of blobs, i.e. if blob_a <> blob_b, etc. I think you still need to
> use a BlobCompare UDF.

What a pitty that I can't find the message from AFAIR Ivan or
Pavel, which states that it should work.

Though, I first test shows that the trigger compiles, and changes
in a BLOB sub_type 1 column are detected (haven't tried binary
data). As I rely on an UDF since years, I will not investigate this
further (for now).


Regards,
Thomas.