Uplifted from http://tracker.firebirdsql.org/browse/CORE-6119
As of now the infamous "Invalid BLOB id" error means "s..t happened, hope you're lucky to guess which specific one".
Reliable reproduction of bugs is not always possible.
And even in lucky cases when it is, it is not always possible to dispatch a developer with full sources and full development environment to the customer site.
Even in double-lucky case when it was possible, it is straining to narrow down the case to simple demo exe and then demand someone from FB core team to debug Firebird server w.r.t. that demo project.
So it would be nice if Firebird reported three different typical cases w.r.t. temporary blobs:
- this blob is real but is not accessible from this transaction, isolation violation between transactions A and B
- this blob likely did existed but does no more, too late
- this blob id is total lunacy, makes no any sense
Such an error, reported immediately by firebird to application, application to user and user to vendor, will give much more information to app developers than "s..t happened, you did not learn some of your lessons" reported now.
What prevents distinguishing and reporting different errors by engine is overlapping of blob ids - "blob_id 1 at txA is not the same as temporary blob with blob_id 1 at txB"
Making them non-overlapping would provide for better instant diagnostics and for moving this class of errors from "Those are just things that routinely happen with Firebird" into "clear cause is known and what code to fix in application can be easily found" domain.
For two easy examples of de-overlapping, a temporary blob_id can be taken form in-memory GENERATOR, or can be constructed as transaction id hash in high digits with linear per-transaction counter in lower digits, counter overflows would be quite OK in these cases, so no limits upon continuous uptime of database connections would be imposed. Extra burden on the server, accounting for all other works for BLOB transfers, should not be significant either.