Good day Helen
--=-00-==-00-==-0

Thanks for the Response

The interesting thing is that we do use Cached updates here and still run into this problem.

We will try and see if there is any way that two updates can be done on the same blob record at the same
time.

Will let you know.

have a good day

Johannes


At 07:57 AM 03/11/2006, Helen Borrie wrote:

>Johannes,
>
>At 03:35 PM 3/11/2006, you wrote:
>>Good day all
>>-=00=-=-0=-0=-0
>>We have had problems in the past with invalid blob ID's. WE thought
>>that moving the interbase version higher than 5.6 will fix
>>it , but this seems is not the case.
>>
>>Then today I found some comments ins
>>
>>procedure TIB_ColumnArray.PutVarSlice( const Values: variant );
>>
>>Where it states near the end
>>
>> SysSetIsNull( false );
>>// Need to finish the auto re-fetch of the new ARRAY ID after this
>>call is made.
>>// Otherwise, an Invalid BLOB ID error is generated if a call to get_slice
>>// is performed using the temporary Array ID that put slice creates.
>> SysAfterModify;
>>end;
>>
>>Now what I want to know if there is a possibility that this is the
>>reason for the Invalid blob Id's that we get every now and again.
>
>Are you talking about invalid blob id's on array slices or on
>blobs? Array slices are a particular problem on the client side and
>errors associated with regular blobs don't have anything to do with "slices".
>
>However, it's in the nature of the way blobs are stored and updated
>that your client code or stored procedure code can cause a
>mess. When you post a record containing a new blob - which applies
>both to a insert or an update - the engine creates a temporary blob
>id which it associates with that data in the uncommitted record. All
>is well if you do nothing more to that record before committing or
>rolling back the work.
>
>However, if you allow it so that the user can update the record more
>than once in the same transaction, or can update a record that s/he
>has inserted but not committed, then you will mess up the blob id's
>and cause the Invalid Blob ID execption.
>
>I haven't *known* the problem to occur under the conditions where the
>*only* update that is done before modifying the blob is the "dummy
>update" that is performed when you use IBO's PessimisticLocking. I
>recall some years ago writing an application to test it (probably
>during Firebird 1.0 days) and it seemed OK.
>
>But it has *never* been a healthy thing with MGA to make multiple
>hits on the same record in the same transaction. I have no idea
>where IB 7.5 is "at" in this regard. However, in Firebird 2.0, you
>will get an exception if you try to double-hit the same record. This
>should pre-empt these Invalid Blob ID errors (along with Too Many
>Savepoints error) in DSQL at least, although I think it is still
>possible to get them in a carelessly designed trigger or SP.
>
>I mentioned the PessimisticLocking thing because I think it is at
>least *possible* that the new restriction in Fb 2.0 will break IBO's
>implementation of this. It would be interesting to hear from anyone
>who is using PL with Firebird 2.0.
>
>>It is very hard for us to emulate the problems as it is intermittent
>>at clients, thus we cannot get to the exact line of code that is the problem.
>
>Assuming we ARE talking about blobs here, and not fields of type
>ARRAY, check out any places where you have open-ended tasks that
>don't take care to commit work after a new blob has been posted...I'm
>not the world's biggest fan of cached updates, but this is one place
>where a carefully managed dataset cache would be of benefit.
>
>Helen
>
>
>
>___________________________________________________________________________
>IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
>___________________________________________________________________________
>http://www.ibobjects.com - your IBO community resource for Tech Info papers,
>keyword-searchable FAQ, community code contributions and more !
>Yahoo! Groups Links
>
>
>