DAO's currentdb object

[Ben]

Hi all -

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

Thanks,

Ben


--

 

[Douglas J. Steele]

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

 

[Stefan Hoffmann]

hi Ben,

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

Not really, but maybe CurrentProject is sufficent for you.


mfG
--> stefan <--

 

[Ben]

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

 

[Douglas J. Steele]

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.

 

[David W. Fenton]

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]

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)

 

[Michel Walsh]

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]

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.

 

[Michel Walsh]

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]

I didn't mentioned late binding.

Substitute "one" for "you" in the statement about late bindingl.

 

[david]

the merits of the switch were not sufficient, so they had to

introduce artificial hurdles to continuing to use DAO in order to

They maintained their old code with minimal changes. That was a
reasonable approach, that every software developer should emulate.

So people had a choice, use the old backward compatible object,
that wasn't broken very much, or the new forward compatible object,
that, like lots of new software, promised more than it delivered.

Choices are good.
Maintaining the old code instead of breaking it is good.

The problem was that ADO wasn't good enough to convince the
user base to switch.

But the fact is that there was never a coherent argument presented for
switching from DAO to ADO. The argument which was presented
was for switching from ODBC-API to a DAO-like COM object.
And if they couldn't present a coherent argument to the users, one
suspects that no coherent argument was made internally.

(david)

 

[David W. Fenton]

They maintained their old code with minimal changes. That was a
reasonable approach, that every software developer should emulate.

They could claim that, but it was very clearly a choice not to
update DAO to reflect the additions to Jet 4. Back then, we were
told that Jet 4 was the last version of Jet that there would be, so
failing to support all the features of that last version of Jet in
its native interface layer was just churlishness on MS's part.

So people had a choice, use the old backward compatible object,
that wasn't broken very much, or the new forward compatible
object, that, like lots of new software, promised more than it
delivered.

I think ADO was abandoned because it didn't fit the new (proper)
security model that was required when MS got the security everywhere
religion (that was back in '03 or so, I think). So, ADO.NET had to
be created to fit in with the security requirements of .NET, and it
really had very little to do with classic ADO, which was an orphan
by that point, not much needed by anyone except Access developers
who drank the ADP Kool Aid.

Choices are good.
Maintaining the old code instead of breaking it is good.

The problem was that ADO wasn't good enough to convince the
user base to switch.

That's because the concept was flawed from the start with regard to
Access and Jet. Many of us could see this and never bothered to try
using ADO with Jet.

But the fact is that there was never a coherent argument presented
for switching from DAO to ADO.

This is because there was no possible coherent argument to be made
on that front.

The argument which was presented
was for switching from ODBC-API to a DAO-like COM object.
And if they couldn't present a coherent argument to the users, one
suspects that no coherent argument was made internally.

Most of it was politics, I think, regarding two issues:

1. MS's agenda to push SQL Server out into customer bases that had
previously found Jet sufficient.

2. MS's campaign to try to clean up Access's "bad reputation" by
deprecating Jet (in the form of the ADP, whose main characteristic,
seems to me, was that it was Jetless).

What somebody forgot along the way (and eventually rediscovered, it
seems) was that Jet is actually remarkably efficient and robust in
dealing with all sorts of different kinds of data. This is why ADPs
are no longer MS's recommended front end of choice for SQL Server --
ADPs just traded one set of layers and inefficiencies for a
different set, many of which were much harder to work around.

 

[Michel Walsh]

And if they couldn't present a coherent argument to the users, one

suspects that no coherent argument was made internally.

DAO succeeded to reach heterogeneous data (ISAM, linked tables, ..) but
never succeeded to support what Jet does not (like disconnected recordset),
so one of the many steps Microsoft did to achieve that kind of UNIVERSALITY
was ADO. But now, even ADO.Net is losing favor for other mechanics allowing
a better 'compatibility match' between class-oriented technology
(hierarchy), technology used by the code, and databases (relational),
technology supporting the data. Such a match in action is LINQ (even
allowing SQL- like data retrieval to data which can be stored, as example,
in an array rather than in "database" ) and whatever can come next.





Vanderghast, Access MVP

 

[Sky]

... But now, even ADO.Net is losing favor for other mechanics allowing a
better 'compatibility match' between class-oriented technology
(hierarchy), technology used by the code, and databases (relational),
technology supporting the data. Such a match in action is LINQ (even
allowing SQL- like data retrieval to data which can be stored, as example,
in an array rather than in "database" ) and whatever can come next.

Vanderghast, Access MVP

LINQ to SQL may also die by neglect:

http://www.infoq.com/news/2008/11/DLINQ-Future

- Steve

 

[David W. Fenton]

The statement above was made by "david" <[email protected]>, not by me
(despite the implications of quoting it without attribution in a
followup to one of my posts).

Can't you please attribute quotes correctly? Is it your software
that is broken or are you personally just incompetent?

 

[Michel Walsh]

Is it necessary an exclusive or?


Vanderghast, Access MVP

 

[Michel Walsh]

Yes, I have read many rumors, some with what look like positive
(constructive) reasons about getting a potential successor to LINQ-to-(MS)
SQL (Server 2008). Note though that there are MANY kinds of LINQ, such as
LINQ-to-Objects, even a LINQ-to-Amazon (yes, the well known internet store)
which borrow and extend the basic LINQ syntax (Look INnocently as remote sQl
== LINQ, my definition ). The individual implementation/extensions
may be revised/revisionized, and the LINQ syntax is itself may improve (I
hope) and finally get another name too ( to make communications between
developers easier).



Vanderghast, Access MVP

 

[David W. Fenton]

Is it necessary an exclusive or?

I would assume that it's unlikely that both would be the case, but
perhaps I'm much too generous.