Issue Details (XML | Word | Printable)

Key: CORE-4678
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Israel Lopez
Votes: 0
Watchers: 3

If you were logged in you would be able to see more operations.
Firebird Core

BLOB not found in SuperClassic and Classic on Uncommitted Transactions

Created: 29/Jan/15 10:37 PM   Updated: 21/Dec/15 12:36 PM
Component/s: None
Affects Version/s: 2.5.3 Update 1
Fix Version/s: 2.5.4

Windows Server 2008/2012 and Windows 7
Firebird: and
Issue Links:

QA Status: Done successfully
Test Details:
Confirmed on WI-V2.5.2.26540 (official release):
exception on ROLLBACK raises with text:
Statement failed, SQLSTATE = HY000
BLOB not found
No reconnect is required, all can be done in one ISQL attachment.

 Description  « Hide
I'm supporting a commercial product that happens to use Firebird SQL. As part of new vendor updates, the Firebird installation was upgraded from to

The customer who uses the commercial product uses a feature in the database schema known as a "memo" which is stored as a BLOB datatype. Specifically: BLOB SUB_TYPE 1 SEGMENT SIZE 100 CHARACTER SET ASCII

The users started reporting errors in the application, which upon inspection was a Stacktrace message through JayBird, through Hibernate, and through the application code. They were receiving the following error message "BLOB not found." Because no other changes were made, and no other customers reported the issue on the same new version, we had believed it was hardware. While waiting for the hardware specialists to respond I created a test application to confirm.

The test code is hosted here:
Binaries are available here:

Arguments are TestFirebirdBlobs.exe [1] [2] [3]
1 - Path to DB
2 - Username
3 - Password

The application drops the DB, and creates a new DB, then applies the selected schema I was testing.

For testing; two connections are created, one for inserting, and another for selecting. For the first connection, I insert records, but do not commit and close the connection. Then I create a new second connection and do a simple count on the table. Using this code, and switching the MEMO type field from VARCHAR(256) to the BLOB type, I can confirm and replicate the results the users were seeing.

On SuperClassic and Classic for I receive a BLOB not found when using the second connection, on I receive no errors for both VARCHAR and BLOB types.

Command Example output and testing results:

It appears there has been some kind of regression that exposes the first connection's inserts, to the second connections reads, and therefore we receive BLOB not found errors. Writing this separate code, confirms that it was not the commercial software's code OR the customer's hardware causing this issue.

My workaround is going to be to revert back to

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 29/Jan/15 10:59 PM
Have you reached out to the commercial product vendor for support?

That would seem to be the best place to start.

Certainly, no equivalent error has been reported by other Firebird installs, so it would seem that the problem is in the application layer, not Firebird engine.

Israel Lopez added a comment - 29/Jan/15 11:17 PM
Hi Sean,
I did reach out, no comment yet. That is why wrote the C# code to confirm while we were waiting on a response. Later today when the system is not as busy I'll roll back to 2.5.2 and see what happens.

The commercial product is written in Java and uses the JayBird driver. My testing application is in C# .NET using the ADO .NET driver.


Israel Lopez added a comment - 30/Jan/15 06:21 PM - edited
I have an update.

From the Commercial Vendor they consider this not their issue. I can see why. I narrowed down the problem to me creating an index on a BLOB using a CAST and SUBSTRING.

If I remove the following index declaration from the Schema.


The test process works on all versions, and Firebird modes. I'm looking for any other JIRA #s that may relate to this issue. I believe CORE-4673 may be related to this. Similar situation, using computed indices.

Sean Leyne added a comment - 30/Jan/15 10:26 PM

Please post the exact error message reported by the engine, and include the database page size and charset used for the database.

Sean Leyne added a comment - 30/Jan/15 10:28 PM
Are you trying to define the MEMO column and the INDEX with a transaction commit in between each command?

Israel Lopez added a comment - 31/Jan/15 12:01 AM
Hi Sean,
I create the database each time using this DDL

So the table, column, and the INDEX are created before I start my test. In a separate connection I perform the insert, and in another connection I perform the select.

If I use ISQL this is what I get when the database is in the failed state, in regards to the exact error message reported by the engine.

C:\Program Files\Firebird\database\bin>isql -user sysdba -p masterkey Z:\temp\TESTDB.fdb
Database: Z:\temp\TESTDB.fdb, User: sysdba
SQL> select count(*) from memo;

Statement failed, SQLSTATE = HY000
BLOB not found

The database was created using the "NONE" charset, and a page size of 4096.

GSTAT header

Database header page information:
        Flags 0
        Checksum 12345
        Generation 49
        Page size 4096
        ODS version 11.2
        Oldest transaction 7
        Oldest active 39
        Oldest snapshot 39
        Next transaction 41
        Bumped transaction 1
        Sequence number 0
        Next attachment ID 6
        Implementation ID 26
        Shadow count 0
        Page buffers 0
        Next header page 0
        Database dialect 3
        Creation date Jan 29, 2015 16:53:47
        Attributes force write

    Variable header data:

Dmitry Yemanov added a comment - 31/Jan/15 08:02 AM
Please try the v2.5.4 snapshot build and report back. It has one reason of the "BLOB not found" error fixed. Your description looks unrelated at the first glance, but who knows.

Israel Lopez added a comment - 31/Jan/15 10:58 PM
It appears fixed in the build. I ran my tests, and there seems to be no error in all Firebird server modes.