I have recently (after over 18 months of testing) upgraded a client from
1.5.5 to 2.1.2. During this upgrade no client application upgrades were
done. There were 4 servers involved each approximately 1 week apart. They
replicate 2 way between all servers. It was not until the last server was
upgraded (week 4) that I received this error "invalid BLOB ID - 335544329"
from the 3rd server in my nightly gbak. This error was fatal for gbak.
I rectified this corruption with the help of the gbak log by updating the
blob in question from another server. It appeared to be fixed.
Now (yesterday) I have received 4 errors from the client app (Eurekalog)
with this same error from the application running against the last of the
servers. The application freezes.

I have been doing some research and noticed this issue beeing raised off and
on over the years both here and in the IBOBjects group.
There are arguments that it is associated with the double posting of a blob
without intermediate refresh of the ID back to the client before the final
commit.
There are also arguments that FB should no be so sensitive.
There are also postings declaring that this issue should never happen now
since FB2 rejects the duplicate posting within the same transaction context.

In my case, the error received is happening on a read only transaction where
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. Given the initial gbak error which is
associated with data reading only, it appears that this error not associated
with previous discussions on this matter. I do not know if gbak handles
blobs by first retrieving IDs then retrieving the blob but this suggests
that the blob ID on the record is not found on the blob page for that
record.

I can’t find anything else that might assist me within these groups - can
anyone shed some more comment on this?
I will be forced to issue an application update which logs and swallows this
exception until I can work it out. It appears to be associated with data
retrieval and not data sending or writing. (other than the gbak error
mentioned above)
But it is still of significant concern for me. 4 years of running this
particular application against 1.5.5 has never given me this level of
concern.


 regards
 Alan McDonald