> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Martes 30 de Mayo de 2000 18:04

[snip]

> If I ever learn to like XML, I'll make a driver manager use it
> for something.

Probably you'll find some volunteers to do that job in this list...
:-)

[...]

> That said, a Connection is, more or less, a transaction. Adding
> Connection::clone() would give a perfectly serviceable transaction
> capable of sharing the database connection (for the one and only
> database that supports multiple transaction per process).

A connection is a transaction, hence do I need two connections for two
transactions even against the same db? Are we falling in the same infamous
limitation than some Borland unnamed technology or did I misunderstood your
idea? Maybe there's no much more that can be done to be in the limits of an
ODBC driver.

> Some thought definitely needs to be given for a two phase commit.
> Complicating the issue is that there are two competing standards
> to cross subsystem two phase commits. Even worse, the better of
> the two is Microsoft's.

Can you explain a bit more on this? DO you refer to technologies like
MTS/MQM in the MS side, for example?

> I did a little design work a year ago on the problem that I should
> dig up. I think it important that the hooks be good enough to
> plug into industry standard solutions that inventing something
> not quite good enough.

Of course, people want "pluggable" solutions even if they have to follow
the general limitations of the standard they adhere.

Some naive questions:
- Is resultSet->release() required even after next() returns false? Is there
a way a resultSet that reaches the end can be disposed automagically? Or the
same resultset can be shared internall among several connections?

- You already overloaded
Parameters.putValue, can't be the same be done with several (not all) of the
PreparedStatement.setXXX functions? AFAIK, ResultSet also could implement an
overloaded get(col_name, col_value) where col_value is a reference or
pointer type to a specific data type, so the variable passed as the second
argument gets the value and let C++ to select the appropriate overloaded
function.

- As I see things, the only way to set Parameters' values is through strings
in the putValue functions, is this the ODBC way? Is this practical?

- Why do all PreparedStatement.setXXX functions take an index? Probably it's
fast, by a field name would be clearer in several cases.

- What's ResultList and how is it used?

- I assume Clob maps to blob sub_type text, is this assumption ok?

- DatabaseMetadata seems powerful and a long needed and missed facility.
When do you implement the ODBC-to-ServicesAPI bridge? <grin>

- Is this C++? I'm not used to deleting exceptions inside a catch block in
typical code. Probably it depends on how you raise the exception... if from
a library, the only way to pass it to the program seems to be allocating
memory in the heap, then some part (the program) should free that exception
and this excerpt is totally ok. However, I'm still in doubt... at least in
Windoze, DLLs and the calling program share the same stack, so a local
exception could potencially cross the library/program barrier safely.
Refresh my foggy memory here, please.
catch (SQLException *exception)
{
printf ("Query failed: %s\n", exception->getText());
delete exception;
return 1;
}

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://members.tripod.com/cvalde