At 03:18 PM 5/31/00 -0700, Brett Bandy wrote:

>
>Jim Starkey wrote:
>>
>> Like Jdbc, there is not explicit support for multiple transactions
>> per process. To get them, multiple attachments are required. There
>> is a temptation to add a clone() method to Connection simplify the
>> coding and allow sharing is the InterBase database attachment.
>
>How do you set a transaction's attributes? (ie wait vs nowait, ...)
>

virtual void setAutoCommit (bool setting) = 0;
virtual bool getAutoCommit() = 0;
virtual void setTransactionIsolation (int level) = 0;
virtual int getTransactionIsolation() = 0;

(OK, I did forget them. I don't approve of autocommit and left
it out of Netfrastructure from which I swiped the code. It's
now in).

>Is the default trans mode autocommit :)
>

JDBC says default is auto commit. So be it. Yuckola.

>Since InterBase supports multiple transactions against a single database
>as well as a single trans against multiple databases, was there thought
>given to creating a transaction class?
>

Yes, but I though following the standard was more important.
Connection::clone() will accomplish almost the same thing. Actually,
in my implementation, it will accompish exactly the same thing.

I'm going to think about the multi-database commit until after I
get something out. I don't think an InterBase only solution is
worth the trouble. I need to re-examine XA and Microsoft's transaction
controller before I propose something.

>>
>> resultSet->release();
>> statement->release();
>> connection->close();
>
>Could you explain the difference between release and close?
>

Objects have use counts, born at 1, incremented by addRef() and
decremented by release(). When the use count goes to zero, the
object disappears (with appropriate cleanup). Like COM, the
idea is that everyone who copies a pointer initially calls addRef()
then release() when he's done with it. JDBC doesn't need to track
object life times, hence doesn't need addRef/release, and uses
close() to dissociate resources held by an object. I've kept
close() for compatibility (perhap a bad idea?). Close() overrides
the use count and deletes the object forthwith and directly. I'm
not happy with the overlapping mechanisms. What do you think?

>> catch (SQLException *exception)
>> {
>> printf ("Query failed: %s\n", exception->getText());
>> delete exception;
>> return 1;
>> }
>
>What about a SQLWarning class for new 6.0 warnings?
>

JDBC (surprise!) has a SQLWarning class, with Connection::getWarnings()
and Connection::clearWarnings(). Ever the slave to a standard, I'll
add them.

Thanks for comments.

Jim Starkey