hi

glad to here my post helped you in any way :)

The cast as varchar was not thought as turnaround. It was more to show that when the server do the job of translating text-blobs as char it do not step into any invalid blob id errors. And from this aspect there was my assumption that this error is called by the IBO Component which have timing problems with the intern transaction handling by touching temporary created blobs outside its internal transaction. And because all my other text-blobs have no problems, my next assumption was that the different charset maybe can call the whole troubles because of temporary blobs.
In 100 loops I step the described query and touch the rdb$description field asString I get around 10 "invalid blob id" errors at absolute randomly records. That was the last aspects for my assumption that this maybe is a internal timing problem of the IBO internal transaction handling.

You told you canged your blob charset and it works now.
Was it also set to another charset then the default of your database? (as it was in my case)

--- In IBObjects@yahoogroups.com, "pb.software" <pb.software@...> wrote:
>
> 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.
> > > > >
> > > >
> > >
> >
>