"Christopher J. Demers" <
[hidden email]> wrote in
message news:ac18mg$m5325$
[hidden email]...
> If one opens an empty ADO recordset, and does a Display It the printOn:
> method will cause a walkback as it tries to show data for a nonexistent
> current record. It looks like it could be fixed in
> ADOField20<<printValueOn: with a check to see if there is a valid current
> record before it tires to get the value.
Thanks, just in time for PL1.
>
> Also as I look through the ADO classes it looks like some methods use an
> uppercase first letter in some method names. However most use normal
> Smalltalk method names. I wonder if there is a reason for this? It seems
> strange to have to switch conventions while working with ADO depending
upon
> the message being sent and object receiving it. For example I have to use
> Close to close the recordset, while I have to use close to close the
> connection.
The ADODB package is attempting to be a very lightweight wrapper around ADO
with minimal additional overhead. The wrapper classes were generated with
the 'minimal' setting in the wizard, which means that it only generates
wrapper methods around the raw COM method calls where they add value, so
pure forwarding methods are not generated. Since many (if not most) COM
method names tend to start with uppercase letters this is reflected in the
generated code. As the connection and recordset close method names are not
consistent, we'll add a #close to ADODB_Recordset.
> I really like having ADO readily available in Dolphin, it really makes it
> easy to do quick little database things without the strategic overhead
> (precompiling queries, etc...) required by the ODBC connection. I suppose
I
> could have used the ActiveX wizard in D4 to wrap it, but it sure is nice
to
> have it as a standard part of the image. Great job guys!
Thanks. Actually it is a quite a bit more useful than what you'd get from
just using the AX component wizard, though perhaps not to the extent of the
XML DOM wrapper. Any suggestions for improvement (within the overall
philosophy of directly exposing the ADO object model as opposed to being a
plug-compatible replacement for the DB connection package) will be
gratefully received.
Regards
Blair
Locked
