I am kind of beginning to believe that you are right to some degree.

>>So I changed my sql that it returns the description as cutted >>varchar(255) instead of blobs:

This problem I resolved simply by changing the field type explicitly to string (a pain but...), to remove that error which was driving me crazy, to use for example as a filepath/directory which is no way a memo field. 255 characters does not equal a memo field. The problem is I cant do that in a blob field handling the extracted IPTC/EXIF information of the file.

I made a change to the charset of the blob field as you sugested and you are right incredibly the error dissapeared. I am not about to go digging why in the source code as I really dont have time to do it, but I am going to continue testing it to see if it is consitent.

I appreciate very much your help,
thanks, pedro

--- In IBObjects@yahoogroups.com, "mayerherbert" <mayerherbert@...> wrote:
>
> Hi,
>
> I had this randomly "Invalid blob id" Error by accessing the Descriptions of the SystemTables
>
> select rdb$relation_name, rdb$description
> from rdb$relations
>
> as soon there is a value in the rdb$description the method MyTIBOQuery.fieldbyname('rdb$description').asString
> can randomly brings the "invalid blob id" error. ...so I asked "why only here and not all over my project?"
>
> Then I checked the fields definition of the rdb$relations.rdb$description.
> It is a BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET UNICODE_FSS.
> And there is the difference. The Charset is set to UNICODE_FSS, while my default database charset and all charset for all other text blobs
> is ISO8859_1.
>
> Then I found the interesting Firebird Bug-Tracker http://tracker.firebirdsql.org/browse/CORE-2086
> It says that When BLOB charset is different from attachment charset, an temporary blob is created. Temporary blobs lifecycle is bound to
> transaction.
>
> Then I remembered that jason did a lot of changes in the transaction handling.
> So I changed my sql that it returns the description as cutted varchar(255) instead of blobs:
>
> select rdb$relation_name, cast(left(rdb$description,250) as varchar(250)) rdb$description
> from rdb$relations
>
> And the "invalid blob id error" was gone!
>
> -------------
> so my assumption is:
>
> When a BLOB charset is different from your attachment charset,
> an temporary blob is created. Temporary blobs lifecycle is bound to transaction.
> Maybe because of a bug in IBO transaction handling the error "invalid blob id" can
> occure when the blob is touched outside the transaction cause of random timing problems.
>
> As said this is only my assumption. Maybe others can bring more light behind
> But maybe it is worth to take a look if the charset of the text blob you try to access is different to your other?
> -------------
>
>
> --- In IBObjects@yahoogroups.com, "pb.software" <pb.software@> wrote:
> >
> > Just anothe detail as I follow the source code the blob field is reaching its point of destruction in a state of nil when the field is declared as ftwidememo and you try to post and edit or an insert operation.
> >
> > --- In IBObjects@yahoogroups.com, "pb.software" <pb.software@> wrote:
> > >
> > > Jason,
> > >
> > > I every bit aware what each subtype does and what it is used for, been doing this for a very long time. I don't think you understood me.
> > >
> > > I am declaring a blob field in firebird as a text blob field because I am going to save large amounts of text in that field. Inside delphi when I create the field, persitent, it is created as a widememo and when you connect a dbmemo to it the invalid blob id happens, text blob field to a db memo with ftwidememo. Now if I change the subtype of the persistent blob field to ftblob as if it was linked to a "binary blob", which it is not, it displays the text perfectly and can be modified. If I try to modify the text on a field declared as ftwidememo linked to a text blob field I get an invalid blob id.
> > >
> > > The ftBlob field as far as I can remember works with both subtypes of blobs, to get rid of this invalid blob id error I had to change the field type to ftBlob for text blob fields. If I use ftwidememo it crashes the application, more of Invalid Blob ID ISC error 335544...
> > >
> > > Pedro
> > >
> > >
> > > --- In IBObjects@yahoogroups.com, "IBO Support List" <supportlist@> wrote:
> > > >
> > > > Sub-type 1 means text.
> > > > Sub-type 0 means binary.
> > > >
> > > > If you wish to store binary data in a blob, do not use sub-type 1. If IBO
> > > > allowed this in the past, it was not intentional on my part.
> > > >
> > > > Jason
> > > >
> > > > -----Original Message-----
> > > > From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On Behalf
> > > > Of pb.software
> > > > Sent: 08 March 2012 10:12 AM
> > > > To: IBObjects@yahoogroups.com
> > > > Subject: [IBO] Invalid Blob ID's with IBOQuery
> > > >
> > > > There is a problem with the TIBOQuery and blob fields. I have spend two days
> > > > dealing with this problem at all levels until I finally discovered the
> > > > problem.
> > > >
> > > > I dont understand why a blob field declared as "BLOB SUB_TYPE 1 SEGMENT SIZE
> > > > 80 CHARACTER SET NONE COLLATE NONE" is created in IBO as a widememo field.
> > > > It should be created as a TBlobFiled with blobtype of ftwidememo but better
> > > > yet just a plain ftblobtype which can read any blob format.
> > > >
> > > > If I declare a blob field as "BLOB SUB_TYPE 0 SEGMENT SIZE 80" to save
> > > > binary files, pictures, etc. I can still save text in it and display it. I
> > > > have never had problems with a plain ftblob type field. This was not the
> > > > behavior of IBO before, more specific TIBO Class.
> > > >
> > > > The ftwidememo implementation is not very compatible with some components
> > > > which will throw an invalid BLOB ID saving a text memo into a blob field of
> > > > "BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET NONE COLLATE NONE" while as I
> > > > discovered after two days if I change the field type manually or create the
> > > > in code as:
> > > >
> > > > qFilesFILE_COMMENTS := TBlobField.Create(Self);
> > > >
> > > > It works as expected. Can someone shed some light on this and why are
> > > > persistent fields being created as widememo instead of regular ftblob?
> > > >
> > > > Thanks in advance, Pedro.
> > > >
> > >
> >
>