Jan Wieck writes:
> I'm not that familiar with the C level of Oracle connections.
> But I used oratcl from Tom Poindexter sometimes and that has
> a AUTOCOMMIT ON/OFF statement that sets the autocommit flag
> in the library routines somewhere. Doesn't embedded SQL use
> the same libraries to connect to oracle that oratcl uses?
Don't know.
> Anyway - ecpg could work around. It can manage an autocommit
> flag and an in_trans status by itself. When autocommit is OFF
> and in_trans is false, it sends down a 'BEGIN TRANSACTION'
> right before the next query and sets in_trans to true.
> Later, when PostgreSQL responds 'COMMIT' from a query, it
> sets in_trans back to false and we have the behaviour of the
> AUTOCOMMIT. This way, a program that doesn't explicitly set
> autocommit to off might sometimes issue a COMMIT that results
> in an empty BEGIN/COMMIT sequence sent down to the backend -
> not too bad IMHO. As soon as a program requires real
Wait a moment. This is almost as it is handled currently. ecpg issues a
'BEGIN TRANSACTION' before the next statement if commited (as the variable
is called) is set to TRUE. Then it sets commited back to FALSE. Issuing a
COMMIT sets it back to TRUE.
> transactions, it sets autocommit to false and has (from the
> embedded SQL programmers point of view) total Oracle
> compatibility. And as long as autocommit is ON, there are no
Oracle compatibility means exactly the behaviour we currently have. BEGIN
TRANSACTION is issued automatically. COMMIT has to be called by hand. But
what we were talking about is forcing both to be called by the programmer.
> open locks laying around since ecpg doesn't send 'BEGIN
> TRANSACTION' and PostgreSQL's default is somewhat like
> autocommit too.
> ...
> Isn't EOF information enough? Must a client say BYE?
No, it need not. But it would be nice if it does, wouldn't it?
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10