> Alan,
>
> > In my case, the error received is happening on a read only
> transaction
>
> Read only read committed one?

In IBO it's ReadOnly, Isolation tiCommitted. Unless someone else can
disagree, that's what I take as read only read committed. And that's what
the component says.

>
> > blobs are being returned via a view which substrings the blob to the
> first
> > 250 characters. It never posts any data and there (I think) is never
> a round
> > trip to retrieve the blob contents using the ID since the blob is
> sent as a
> > varchar in the first instance anyway.
>
> Prior to v2.1, SUBSTRING(BLOB) returned a varchar, but now it returns a
> temporary blob. So I believe the blob contents is actually fetched by
> the client via the blob ID. Could it be possible that it's done after a
> transaction commit, for example?

oh, I didn't realise that. So this means I've lost the performance
enhancement I thought I had with subtring. I'll have to look in the monitor
again to see what the process is.
It could well be after a commit. But/and it's a commit of another
transaction and refresh of the read committed transaction. That may explain
it. The operator searches for a job, locates it, in the read commited trans,
then double clicks the job in the grid and opens the job in edit mode with
dummy update for locking. Then saves the edits (commits) including the blob
in question and this calls a refresh of the read committed transaction -
perhaps with the old ID? I'll check this because I think it happened also
without necessarily editing the job details and committing, i.e. just the
search location operation raised the exception.

thanks for your comments Dmitry

>
>
> Dmitry