By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,383 Members | 2,063 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,383 IT Pros & Developers. It's quick & easy.

DAO (Instantiate as Object or use the Data Control)

P: n/a
I guess my question can go in two directions. I create applications
that run multiple queries against a database. Generally speaking in the

past I have used a Data Control (calling it dat1) making it invisible
and have used this whenever i needed it.

dat1.databasename = app.path & "mydatabase.mdb"
dat1.recordsource = "my query"
dat1.refresh

Lately I have seen that most programmers instantiate this when they
need it. For example, in typical DAO style.

dim db as database
set db = OpenDatabase(app.path & "\mydatabase.mdb")

dim rs as recordset
set rs = OpenRecordsets("my table or query")

My question is this. Is it better to instantiate it whenever I use it
or just use one control throughout my program and re-open it when I
need it. Which is better on memory?

My question is not just for DAO, ADO also has a data control or I can
instantiate that as well.

Which is better on memory?

Nov 13 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Is this Access where you are working?
What are you doing with these queries once you run them -
are you using the recordset you generate? If so, how?
Or are these action queries? (update, append, delete)?

<th***********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I guess my question can go in two directions. I create applications
that run multiple queries against a database. Generally speaking in the

past I have used a Data Control (calling it dat1) making it invisible
and have used this whenever i needed it.

dat1.databasename = app.path & "mydatabase.mdb"
dat1.recordsource = "my query"
dat1.refresh

Lately I have seen that most programmers instantiate this when they
need it. For example, in typical DAO style.

dim db as database
set db = OpenDatabase(app.path & "\mydatabase.mdb")

dim rs as recordset
set rs = OpenRecordsets("my table or query")

My question is this. Is it better to instantiate it whenever I use it
or just use one control throughout my program and re-open it when I
need it. Which is better on memory?

My question is not just for DAO, ADO also has a data control or I can
instantiate that as well.

Which is better on memory?

Nov 13 '05 #2

P: n/a


Yes this is Access, I am not appending, updating or anything like that.
I am usually just finding matches or filtering information that gets
displayed in a grid or T-List

*** Sent via Developersdex http://www.developersdex.com ***
Nov 13 '05 #3

P: n/a
AFAIK, the Data Control is not a native Access control. I'm not at all sure
what a T-list even is.

The native Access way to approach this would be to use a subform.

"John Grove" <th***********@yahoo.com> wrote in message
news:4%***************@news.uswest.net...


Yes this is Access, I am not appending, updating or anything like that.
I am usually just finding matches or filtering information that gets
displayed in a grid or T-List

*** Sent via Developersdex http://www.developersdex.com ***

Nov 13 '05 #4

P: n/a
The Data Control is a feature, a native, built-in control, of the separate
Visual Basic language -- you may well be using an Access (Jet) database with
VB, but it is highly unlikely that you are using a VB Data Control with an
application created in Access. In Access, binding is different, the Record
Source is bound to the Form, and individual Fields in the Form's Record
Source may be bound directly to Controls such as Text Boxes, and Combo
Boxes. Access developers neither have nor use a Data Control, and, thus, you
aren't likely to get the best answer to your questions here -- you need to
find a newsgroup that deals with VB, and, if possible, databases. I know
there used to be a USENET newsgroup, comp.lang.basic.visual.databases but
don't know if anyone posts there or monitors it, anymore -- even after
splitting the USENET VB newsgroups some years back, most still posted their
questions to comp.lang.basic.visual.misc.

Check the free news server, news.microsoft.com, for sponsored newsgroups
about VB.

Larry Linson
Microsoft Access MVP
<th***********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I guess my question can go in two directions. I create applications
that run multiple queries against a database. Generally speaking in the

past I have used a Data Control (calling it dat1) making it invisible
and have used this whenever i needed it.

dat1.databasename = app.path & "mydatabase.mdb"
dat1.recordsource = "my query"
dat1.refresh

Lately I have seen that most programmers instantiate this when they
need it. For example, in typical DAO style.

dim db as database
set db = OpenDatabase(app.path & "\mydatabase.mdb")

dim rs as recordset
set rs = OpenRecordsets("my table or query")

My question is this. Is it better to instantiate it whenever I use it
or just use one control throughout my program and re-open it when I
need it. Which is better on memory?

My question is not just for DAO, ADO also has a data control or I can
instantiate that as well.

Which is better on memory?

Nov 13 '05 #5

P: n/a
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?

Nov 13 '05 #6

P: n/a
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?

Nov 13 '05 #7

P: n/a
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?

Nov 13 '05 #8

P: n/a
"th***********@yahoo.com" <th***********@yahoo.com> wrote in
news:11**********************@g49g2000cwa.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.


Then this is the wrong place to post.

If you are programming in VB, YOU ARE NOT USING ACCESS.

You may use Access to create your tables and queries, but that is
really only a Jet database as far as your application is concerned.

The data grid you are talking about has absolutely nothing to do
with Access -- it's a VB control. Access does not have data grids --
it has something much more powerful and easy to use, continuous and
databasheet subforms. Because of that, most Access programmeers will
know nothing at all about the data grid you are awsking about.

Since this is an Access newsgroup, you are unlikely to find an
answer to your question -- it really isn't an Access question at
all.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9

P: n/a
"th***********@yahoo.com" <th***********@yahoo.com> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com:
I am speaking to
VB6 developers primarily who use Access specifically.


VB programmers DO NOT USE ACCESS.

They use JET.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.