Larry said:
It's only "better" if the features you list are required, or useful, in
addressing the business problem -- and they often are neither required nor
useful.
In fact, they are often "useful" only to demonstrate the "advanced"
techniques used by the developer, that is, to "wow" clients with how
up-to-date and accomplished the developer is with the "new stuff." My
clients are 'way too practical to be impressed -- they want a quick,
efficient, low-cost solution to the business problem. And, their "BS
repellent" is to hustle the BSer out the door.
Impressing client with COM-based middleware? Claiming ADO is
up-to-date? Sounds a bit far fetched <g>. In my experience, clients ask
for "XML" and "dot net", seemingly without knowing what those things
mean (tip: such clients would be impressed if you ship and install the
..NET framework - who says you have to use it <vbg>).
Personally, my use of ADO is strictly under the covers. Typical usage
example: I have lots of VBA class modules for business objects (i.e.
designing components for other coders to use) in a hierarchy: parent
class, collection classes, child classes with a further collection
classes, etc; I mainly use a Collection (to expose IEnumerable hence
support For Each) for the collection classes but often also use a
fabricated disconnected ADO recordset to hold pointers to the children
along with strongly-typed fields to hold property values so that I can
use Sort, Filter, GetRows (output any array), GetString (output
formatted text), etc.
Another time there were no methods, just data headed for a treeview
control, so I used a fabricated hierarchical ADO recordset instead of a
hierarchy of classes, again under the covers.
FWIW I hold 'dumb' pointers to parent objects that are 're-hydrated'
when required (using CopyMemory API), avoiding circular references and
associated memory leak problems. Shame I can't say the same thing about
the DAO object model ;-)
Does any of the above (i.e. leveraging ADO functionality rather than
re-engineering my own) sound to you like "useful" or more like "BS"?
I'm not even sure any of that kind of stuff would impress you, Larry,
let alone a *client* e.g. you might say, "I don't *require* a
fabricated ADO recordset to sort child objects because I can use a
strongly-typed array and a bubble sort." True, of course, but each to
their own, don't you think? I don't think the suggestion of me being
"BSer" because I use ADO is due. Admittedly, the above sounds like the
coder's equivalent to a guitarist describing some signature guitar
solos but then you've got me all defensive now said:
in my experience, it is mostly or always in situations where
the data is being kept in Microsoft SQL Server where [disconnected,
asynchronous, fabricated, hierarchical, persisted on disk, etc]
are useful
I'm interested. Please give an example from your experience where you
used the ADO recordset features mentioned for data stored in Microsoft
SQL Server that wouldn't also be useful for data stored in Access/Jet.
Thanks in advance.
Jamie.
--
