Hi all -

In DAO, there's a currentdb object, is there a similar ADO equivalent?

Thanks,

Ben


--

Depends on why you're looking for it. You might be looking for
CurrentProject.Connection

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Ben" <(E-Mail Removed)> wrote in message
news:7A8DCC0C-C477-4215-B858-(E-Mail Removed)...
> Hi all -
>
> In DAO, there's a currentdb object, is there a similar ADO equivalent?
>
> Thanks,
>
> Ben
>
>
> --
>

hi Ben,

Ben wrote:
> In DAO, there's a currentdb object, is there a similar ADO equivalent?
Not really, but maybe CurrentProject is sufficent for you.


mfG
--> stefan <--

Hi Doug, Stefan -

I just want to use it to reference the db itself without going through all
the trouble of pointing to another instance of the db, which currentdb makes
so much convenient.

so CurrentProject ? I am going to look into it. Thank you both much.

Ben



--



"Ben" wrote:

> Hi all -
>
> In DAO, there's a currentdb object, is there a similar ADO equivalent?
>
> Thanks,
>
> Ben
>
>
> --
>

Reference the db for what purpose?

As I implied, CurrentProject.Connection will give you an ADO Connection
pointing to the database.

Just curious. If you're familiar with DAO, why are you switching to ADO?
Hopefully it's not because someone told you should because ADO is replacing
DAO, because that's simply not true.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Ben" <(E-Mail Removed)> wrote in message
news:808FEF0A-3065-4141-ACBE-(E-Mail Removed)...
> Hi Doug, Stefan -
>
> I just want to use it to reference the db itself without going through all
> the trouble of pointing to another instance of the db, which currentdb
> makes
> so much convenient.
>
> so CurrentProject ? I am going to look into it. Thank you both much.
>
> Ben
>
>
>
> --
>
>
>
> "Ben" wrote:
>
>> Hi all -
>>
>> In DAO, there's a currentdb object, is there a similar ADO equivalent?
>>
>> Thanks,
>>
>> Ben
>>
>>
>> --
>>

"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in
news:(E-Mail Removed):

> Just curious. If you're familiar with DAO, why are you switching
> to ADO? Hopefully it's not because someone told you should because
> ADO is replacing DAO, because that's simply not true.

I was going to ask that question myself. I've never learned ADO in
any detail because most of my apps use Jet back ends, and ADO simply
serves no purpose with those.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

By the way, CurrentDB is an Access Application object.
Dao has db objects: Access gets a pointer to one and calls
it the Current db object.

Application.CodeDB
Application.CurrentDB
Application.CurrentProject
Application.CurrentConnection

I think that last one is the one you want: it is an ADO Connection Object.

The Project is neither DAO nor ADO: it's a native Access object.

(david)


"Ben" <(E-Mail Removed)> wrote in message
news:7A8DCC0C-C477-4215-B858-(E-Mail Removed)...
> Hi all -
>
> In DAO, there's a currentdb object, is there a similar ADO equivalent?
>
> Thanks,
>
> Ben
>
>
> --
>

Some Jet 4.0 extensions are (at least, were) only available through ADO. The
powerful CHECK( ) constraint (as defined by Jet, not the standard one,
limited ) among one of them, as example. Sure, once it is defined, it fires
even if you then use DAO or ADO since the database engine will simply see
the constraint (and not WHAT append it to the db).


Vanderghast, Access MVP


"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9B48B358E1FB7f99a49ed1d0c49c5bbb2@74.209.136.93...
> "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in
> news:(E-Mail Removed):
>
>> Just curious. If you're familiar with DAO, why are you switching
>> to ADO? Hopefully it's not because someone told you should because
>> ADO is replacing DAO, because that's simply not true.
>
> I was going to ask that question myself. I've never learned ADO in
> any detail because most of my apps use Jet back ends, and ADO simply
> serves no purpose with those.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in
news:#(E-Mail Removed):

> "David W. Fenton" <(E-Mail Removed)> wrote in message
> news:Xns9B48B358E1FB7f99a49ed1d0c49c5bbb2@74.209.136.93...
>> "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in
>> news:(E-Mail Removed):
>>
>>> Just curious. If you're familiar with DAO, why are you switching
>>> to ADO? Hopefully it's not because someone told you should
>>> because ADO is replacing DAO, because that's simply not true.
>>
>> I was going to ask that question myself. I've never learned ADO
>> in any detail because most of my apps use Jet back ends, and ADO
>> simply serves no purpose with those.
>
> Some Jet 4.0 extensions are (at least, were) only available
> through ADO.

This is true, of course, but it's not by necessity, but by
Microsoft's choice (as part of their misguided efforts back in the
day to replace DAO with ADO; for some reason they seemed to think
the merits of the switch were not sufficient, so they had to
introduce artificial hurdles to continuing to use DAO in order to
drive people towards ADO). And if one doesn't need that small
handful of features, there's no point in using ADO all the time.

> The
> powerful CHECK( ) constraint (as defined by Jet, not the standard
> one, limited ) among one of them, as example. Sure, once it is
> defined, it fires even if you then use DAO or ADO since the
> database engine will simply see the constraint (and not WHAT
> append it to the db).

So, you use ADO (with late binding) for the handful of Jet features
MS has not yet implemented in DAO. Frankly, since 1999 when Jet 4
was released, I've never yet needed even one of those features.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

You can use MS DOS 3.11 too, so far as I am concerned, and don't need a lot,
indeed. Other people, on the other hand, can have need for it, or can find
it is simpler to use those features.

I didn't mentioned late binding.


Vanderghast, Access MVP


"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9B4BB2B61E0E3f99a49ed1d0c49c5bbb2@74.209.136.91...
> "Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in
> news:#(E-Mail Removed):
>
>> "David W. Fenton" <(E-Mail Removed)> wrote in message
>> news:Xns9B48B358E1FB7f99a49ed1d0c49c5bbb2@74.209.136.93...
>>> "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_gmail.com> wrote in
>>> news:(E-Mail Removed):
>>>
>>>> Just curious. If you're familiar with DAO, why are you switching
>>>> to ADO? Hopefully it's not because someone told you should
>>>> because ADO is replacing DAO, because that's simply not true.
>>>
>>> I was going to ask that question myself. I've never learned ADO
>>> in any detail because most of my apps use Jet back ends, and ADO
>>> simply serves no purpose with those.
>>
>> Some Jet 4.0 extensions are (at least, were) only available
>> through ADO.
>
> This is true, of course, but it's not by necessity, but by
> Microsoft's choice (as part of their misguided efforts back in the
> day to replace DAO with ADO; for some reason they seemed to think
> the merits of the switch were not sufficient, so they had to
> introduce artificial hurdles to continuing to use DAO in order to
> drive people towards ADO). And if one doesn't need that small
> handful of features, there's no point in using ADO all the time.
>
>> The
>> powerful CHECK( ) constraint (as defined by Jet, not the standard
>> one, limited ) among one of them, as example. Sure, once it is
>> defined, it fires even if you then use DAO or ADO since the
>> database engine will simply see the constraint (and not WHAT
>> append it to the db).
>
> So, you use ADO (with late binding) for the handful of Jet features
> MS has not yet implemented in DAO. Frankly, since 1999 when Jet 4
> was released, I've never yet needed even one of those features.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/