Why Dim db As DAO.Database?
Bill Clark
Dim db As DAO.Database
rather than...
Dim db As Database
I'm still confused on the difference between DAO and ADO as well as
what each actually means.
--
Bill Clark
Sent via Deja.com
http://www.deja.com/
Michael Blake
Access 2000.
Michael
"Bill Clark" <bclar...@my-deja.com> wrote in message
news:95eli3$3t2$1...@nnrp1.deja.com...
Larry Linson
between them. In fact, ADO has no Database object, so it isn't
actually -necessary- to qualify Database, but it doesn't hurt and
qualifying all access method objects is a good habit to adopt.
If, for example, you Dim rs as Recordset, it will be taken as
whichever, DAO or ADO, happens to fall first in the list of References
(in a module, on the menu, Tools | References) and that may not be the
correct one. If you have an Access 97 database that you convert, and
just can't spare the time or effort to do it right by going through and
qualifying each reference to an access method object, you can go to the
References and move the DAO reference up the list (there's a command
button to do that) until it's before the ADO reference.
--
L. M. (Larry) Linson
http://www.ntpcug.org - North Texas PC User Group - Visit and Join
http://www.ntmsdevsigs.homestead.com - NTPCUG Developer SIGs
http://homestead.deja.com/user.accdevel - Access examples
jbthame
ADO = (Microsoft) ActiveX Data Objects
Because A2K can use a DAO object library and also ADO libraries. If you
don't specify DAO then you might find Access looking in ADO stuff for your
object and failing to find it and giving you an error message.
If you go to any Module and open it in design mode (even create a new Module
will do, you won't need to put anything into it or save it) and look at the
Tools menu and select References you'll see a list of the libraries etc.
that the database is 'linked to'. You could, if there is an ADO and a DAO
reference, ensure that the DAO comes before the ADO. Then Access will look
in there first and you can do without the DAO.Database syntax. It's
considered better to use the full syntax, however, because it leads to fewer
problems.
--
Jeff Bailey
Bill Clark <bclar...@my-deja.com> wrote in message
news:95eli3$3t2$1...@nnrp1.deja.com...
Jon
<mbl...@kleNOin-diSPAMckert.com> writes:
>I use it because I may need to upgrade an application from Access 97 to
>Access 2000.
>
>Michael
>
Yes, but ADO doesn't have a database object. It does have a recordset, which
differs to the DAO Recordset, and so DAO and ADO recordsets should be declared
as belonging to the correct Object Library, but as there is no chance of an ADO
Database object being created, it does seem rather unnecessary.
Also, as I understand it, when you convert a database from A97 to A2K, it
should pick up on the DAO Reference and resolve it behind the scenes. Although
I'm probably wrong......
>
>"Bill Clark" <bclar...@my-deja.com> wrote in message
>news:95eli3$3t2$1...@nnrp1.deja.com...
>What is the purpose of using...
>
>Dim db As DAO.Database
>
>rather than...
>
>Dim db As Database
>
>I'm still confused on the difference between DAO and ADO as well as
>what each actually means.
>
>--
>Bill Clark
>
>
>Sent via Deja.com
>http://www.deja.com/
>
Jon
Access tips & tricks - http://www.applecore99.freeserve.co.uk
Microsoft Access webring -
http://nav.webring.yahoo.com/hub?ring=microsoftaccess
Pedro Gil
I may have some concerns with the last statment, let me see if you can
agree with me on this one.
If you need to make reference to both ADO or DAO, then you must fully
qualify the objects, if not you will never known when you are going to
access one or the other, if you will use just one of the objects, then
remove the reference to the other and pray that no one remember to
reference it again. and change priority just so that that small
function work correctlly.
So my advise is always fully qualify objects... Even if you just need
one of the object lib at the moment, it will give you no pain once you
need for some reason to include the other.
On Fri, 02 Feb 2001 16:52:55 GMT, Larry Linson <accd...@my-deja.com>
wrote:
---------
Pedro Gil
http://www.geocities.com/pmpg98_pt
Larry Linson
Access 2000 and later. My comment dealt with a very specific situation,
to wit "just can't spare the time or effort to do it right by going
through and qualifying each reference to an access method object, you
been specific, that it ought to be "a temporary expedient".
That said, I tend not to qualify the objects when I am doing Access 2.0
or Access 97 development. I have no plans _ever_ to use ADO for access
to Jet databases (because: additional development on ADO for Jet has
ceased, and DAO is more complete, easy, and faster with Jet), and won't
necessarily use it for "run of the mill" clients to server databases
(because: ODBC, Linked Tables, and Bound Forms have served me well for
databases with user bases up into the low hundreds. They are simple,
straightforward, and quick to implement. And have, so far, been
adequate performers.)
Should the occasion arise, I'll deal with qualifying references as
a "conversion issue".
When/if I do some "real paying development" in an Access version newer
than 97, which I haven't done yet, I'll carefully qualify the data
access method objects.
Joe "Nuke Me Xemu" Foster
> What is the purpose of using...
>
> Dim db As DAO.Database
>
> rather than...
>
> Dim db As Database
CYA in case MS decides to break VBA like they will VB in VB.NyET. It's
wise to be fully explicit with all COM types in case the code converter
forever remains unable to find its own bum with both hands and a maglite.
> I'm still confused on the difference between DAO and ADO as well as
> what each actually means.
DAO is fairly stable, while ADO gets broken anew in every other release.
Have you downloaded your service pack today?
--
Joe Foster <mailto:jfo...@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Pedro Gil
Well I don't want to argue with you...
I known that we were talking about DAO/ADO but I was trying to make a
more general aproach to the fully qualifying of all objects.
And yes in a way I can understand the reason for the only necessary on
the A2K and later. But I think that's a habit it's not so hard to type
three more letters and yes the beneficts are really not there, but one
thing at least can be good in that, you known by anticipation that you
are using DAO or ADO, and your code does too...
Yep I do understand and when I said that, I was thinking in more of a
general declaration of objects and not particulary on DAO/ADO. I'm
sure that you fully qualify your object even in Access 2 and 97,
imagine this, I'm sure you never do it.
Sub NonExplicitCOMobject()
Dim a As Word.Application
Dim d As Word.Document
Dim r As Range
Set a = New Word.Application
a.Visible = True
Set d = a.Documents.Add
d.Range.InsertParagraph
Set r = d.Range(1, 2)
d.Close SaveChanges:=wdDoNotSaveChanges
a.Quit
Set r = Nothing
Set d = Nothing
Set a = Nothing
End Sub
It works because I only have Word Object library check, but If I
decide that I need Excel too?
On the decision DAO / ADO I do agree fully with your decision, not to
use the latter, I think that I only have made test functions in ADO.
On Sat, 03 Feb 2001 01:46:07 GMT, Larry Linson <accd...@my-deja.com>
wrote:
>I agree that it is a good idea to qualify all access method objects in
>Access 2000 and later. My comment dealt with a very specific situation,
>to wit "just can't spare the time or effort to do it right by going
>through and qualifying each reference to an access method object, you
>can . . .". I thought it would be clear, though perhaps I should have
>been specific, that it ought to be "a temporary expedient".
>
>That said, I tend not to qualify the objects when I am doing Access 2.0
>or Access 97 development. I have no plans _ever_ to use ADO for access
>to Jet databases (because: additional development on ADO for Jet has
>ceased, and DAO is more complete, easy, and faster with Jet), and won't
>necessarily use it for "run of the mill" clients to server databases
>(because: ODBC, Linked Tables, and Bound Forms have served me well for
>databases with user bases up into the low hundreds. They are simple,
>straightforward, and quick to implement. And have, so far, been
>adequate performers.)
>
>Should the occasion arise, I'll deal with qualifying references as
>a "conversion issue".
>
>When/if I do some "real paying development" in an Access version newer
>than 97, which I haven't done yet, I'll carefully qualify the data
>access method objects.
>
---------
Pedro Gil
http://www.geocities.com/pmpg98_pt