Subject | Re: Insert within a stored procedure not inserting records |
---|---|
Author | Adam |
Post date | 2007-09-20T23:54:52Z |
Hi Peter,
written for desktop database systems to somewhat work without having
to re-write the entire thing. There are many flaws to the autocommit
concept, which is to try and dumb down the whole concept of
transactions from databases. The problem is that transactions are used
to control isolation and concurrency.
In a MGA database such as Firebird, it controls which record versions
can be garbage collected. A soft commit (retaining) does not allow the
garbage collection to proceed, and when your transaction finally does
commit completely, a whole bunch of garbage could have banked up.
Explicitly start and commit each transaction and you get into far less
troubles (and weird untraceable performance drops) in the long term.
Adam
> Oh, and Rick, if you're reading this, thank you for hating to askI find it best to treat Autocommit as a nice hack to get legacy code
> about commits because that was indeed the problem with the Delphi
> code. It isn't enough to have Server Autocommit checked on the
> IB_Objects database object -- must ensure that the Transaction object
> is also configured - or explicitly committed in the code.
written for desktop database systems to somewhat work without having
to re-write the entire thing. There are many flaws to the autocommit
concept, which is to try and dumb down the whole concept of
transactions from databases. The problem is that transactions are used
to control isolation and concurrency.
In a MGA database such as Firebird, it controls which record versions
can be garbage collected. A soft commit (retaining) does not allow the
garbage collection to proceed, and when your transaction finally does
commit completely, a whole bunch of garbage could have banked up.
Explicitly start and commit each transaction and you get into far less
troubles (and weird untraceable performance drops) in the long term.
Adam