> But if you cache the blobs for *every* row in a ResultSet that would
> eat sooo much memory... If transaction for a ResultSet is valid only
> while the connection or the statment is valid, and no other queries
> were executed against the statement, then blobs will be read only
> when the current row is being fetched.

That's how it is and probably will be in auto-commit mode. Firebird
has no direct support of auto-commit, and we should not invent too
much to implement the specs. For me, it is better not to have auto-
commit mode, then not to have transactions.

> What is your opinion about those solutions I suggested?

The problem was in another place. Yesterday I was in a hurry and
forgot about one more place to look. Your solution has problem in the
transaction management: you retrieve blob in another transaction than
the statement was executed. It would be correct implementation only
in case of 1 and only 1 connection to the database when your
execution is serial by nature. In case of concurent reads and updates
it would produce inconsistent results. Anyway, try to avoid using
auto-commit. You save resuorces and simplify your life.

Best regards,
Roman Rokytskyy