|Subject||Re: serious problem with FBResultSet|
> But if you cache the blobs for *every* row in a ResultSet that wouldThat's how it is and probably will be in auto-commit mode. Firebird
> 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.
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.