> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Viernes 2 de Junio de 2000 10:40
>
> At 08:58 AM 6/2/00 -0700, Glebas Paulevicius wrote:
> >
> >Jim, I have something deep inside me against having
> >Connection object in "unconnected" mode!
> >The fact that Connection object is created should
> >MEAN - we are connected!
> >Please, avoid object modes if possible.
>
> Point well taken. Realistically, however, eliminating the
> unconnected state would virtually dictate a data source
> driver class to create connections and databases. Ultimately,
> however, the driver class would be doing exactly the same
> thing we're doing now but hiding the details.

I don't understand the issue. What's wrong with a Connection object that's
unconnected? A semantic problem or a practical problem? Probably the
unconnected state is a must in libraries with design-time support like the
VCL stuff, but even so, I don't see the real harm for having a connection
unconnected even if it sounds like a word game. One alternative could be:
- define the connect() and disconnect() as protected;
- make a public constructor that calls connect so it forces the object to be
created in a connected state;
- make a protected virtual destructor, so it calls disconnect() internally
and in turn, the destructor is called by a (static?) method named close() or
whatever you want.

> Here is the JDBC driver class. Do you think we should add it?

[...]
Sorry, I got indigestion trying to read the JDBC driver specification. Can
I charge Ann for a visit to a physician? If anybody cares to explain me why
we need such fat interface, then at least I can say YES or NO o the
proposition of adding it. Is it that we don't have enough with an ODBC
driver that follows JDBC inspiration? The method getPropertyInfo looks like
the low-level routines that support the Delphi metadata.

C.