You would surely have saved me some typing if you had made it clear that you
were using VB6, instead of implying that you were using the Data Control
within Access itself. But, hey, that's the way the old newsgroup crumbles,
eh?
I would say that it depends on the circumstances whether you place a Data
Control on your VB6 Form, or instantiate it as an object. Object Orientation
is a current "buzz" in much of the development world, and it can be helpful
in code-intensive environments (but that isn't what I want in either Access
or VB... I want the least code to make the point-and-clicked friendly user
interface work, and work smoothly. Generally, I observe that using OO
techniques, esp. in VB.NET where even the variables are "objects"
_guarantees_ that you have a code-intensive environment, where using
standard old non-OO VB methods does the same job with less code. But, there
are many who believe "if it ain't OO, it don't compute" and who look down
their noses at anyone who isn't a true believer -- unfortunately for the
non-OO crowd, they are often the ones determining who is hired or
contracted.
And, I'd still say you are more likely to get a better answer on a VB
question such as this in a newsgroup devoted to VB than in one devoted to
Access. I have never seen anyone instantiate a Data Control in an Access
application, nor heard of it being done. If the appropriate library is
available, I suppose it _could_ be done, but I certainly see no advantage in
Access.
VB6 still has the DAO library, so I don't see any need to use ADO if you are
working with Jet databases, unless there are examples from which you can
obtain most of the code you need to accomplish _your_ work -- that would be,
in my mind, a valid reason, even though I am no fan of ADO.
Larry Linson
Microsoft Access MVP
<th***********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
I appreciate all your responses, but I think you all may have have
missed the force of what i was trying to convey. I am in the Visual
Basic 6 platform. In the past, my programs whenever I wanted to query
information (usually to display information in a 3rd party control
called T-List, similar to a listbox control) or for other reasons, I
would use the data control found in the toolbox that is native to VB. I
would use one-control throughout my programs, turning it on or off when
I needed it.
Now, I have seen users instantiate data controls as objects using it
like a variable whenever they need it, which of course is more wordy
and tedious in my opinion. But my question is what is the value of
that? Does it save memory? Why not always use a data control? I have
never come across any instance where it didn't suit my needs. But if
memory can be saved by doing this I see value in it. I am speaking to
VB6 developers primarily who use Access specifically. I know ADO is not
developed primarily for Access but for data in general. One thing you
have to consider is that DAO was built specifically for the Jet engine.
This means it was tweaked and optimized to give
the best possible performance with Jet. ADO is a more general purpose
library, and not optimized for any one engine. So you're almost always
going to get better performance with DAO-Jet than anything Else-Jet.
But back to the Data Control vs. Instantiating as an Object. Is their
any value to this?? Why is this method so popular?