I'm supporting a commercial product that happens to use Firebird SQL. As part of new vendor updates, the Firebird installation was upgraded from 18.104.22.168540 to 22.214.171.124778.
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: https://github.com/ilopez/Firebird.TestBlobs
Binaries are available here: https://github.com/ilopez/Firebird.TestBlobs/releases/download/0.1/Debug.zip
Arguments are TestFirebirdBlobs.exe   
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 126.96.36.199778 I receive a BLOB not found when using the second connection, on 188.8.131.52540 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 184.108.40.206540.