At 08:16 PM 5/31/00 -0400, Claudio Valderrama C. wrote:

>
> 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.
>

You would need two Connection objects. If the second were created by
Connection::clone(), there would be only one database attachment. In
my implementation, there are no limits.

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

The two are Microsoft Distributed Transaction Controller and XA. They
are similar in concept, differing only in details. DTC is definitely
real while XA seems a little vaporous. Borland's InterBase Division
General Manager (Acting) has agreed to let me publish a paper I did
on the issue about a year ago. Watch this space.

>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?
>

A release() or close() is absolutely required. Objects can disappear
automatically. Even an exhausted ResultSet can be useful.

>- 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.
>

Properties (abstract replacement for Parameters) is used only to pass
an arbitrary and open ended set of named values on the openDatabase
and createDatabase calls, and is not really part of the object model.
Your point about making the method names parallel to PreparedStatement
is well taken. I chose to use "put" rather than "set" since there can
be multiple values.

>- 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?
>

Yes, but I think this is appropriate for the extremely limited use
of Parameters/Properties.

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

The PreparedStatement::setXXX guys are used to set values for parameter
markers ("?"), which don't have names.

>- What's ResultList and how is it used?
>

Output of a full text search. InterBase doesn't support it.

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

Yes. The InterBase implementation doesn't get very hung up on the
difference between Blobs and Clobs.

>- 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;
> }

I've had trouble with MSVC++ throwing localing object instances that
I've never particularly run down. It is certainly simpler to throw
an object that doesn't need to be explicitly deleted. I want to
replace the SQLException class with an abstract class of the same
name, so this is a good time to revisit the question.

That said, assuming an class has a virtual destructor, the delete
operator is library/program safe. Now maybe if we eliminated
the delete operator in favor of garbage collection, eliminated
non-virtual methods, dropped overloaded operators as confusing,
purge "union" as unsafe, and required all method to find a home
in a class namespace, we could improve the language... C+=2?
Hot Chocolate?

Jim Starkey