ADO 6

[aaron.kempf]

Ralph

didnt you write this:

Also you might be surprised to learn that toggling between MSAccess,
SQLServer, and Oracle is not so difficult to do with DAO either.

 

[Ralph]

Ralph

didnt you write this:

Also you might be surprised to learn that toggling between MSAccess,
SQLServer, and Oracle is not so difficult to do with DAO either.

<snipped>

I certainly did. It was in reference to the suggest that "...surely
developing solutions using DAO is ridiculous because it's nearly impossible
to switch from SQL to Access to Oracle; etc".

I was pointing out that DAO could be used for data access for any of those
databases, and be "switched" out between them with far less effort than
"nearly impossible".

I truly didn't expect you to believe I would actually recommend using DAO
with SQL Server.

-ralph

 

[aaron.kempf]

I disagree.

A typical application using DAO instead of ADO is crippled.

with DAO, you have to explicitly close your connections / objects!
It's a CONSTANT memory leak

 

[Henning]

I can't see what is crippled about explicitly closing what one have
explicitly opened.

/Henning

 

[Ralph]

I disagree.

A typical application using DAO instead of ADO is crippled.

with DAO, you have to explicitly close your connections / objects!
It's a CONSTANT memory leak

<snipped>

Of all the factors involved in selecting an appropriate data access
library - that has to be the sillest and most erronous reason I have ever
seen presented.

If you want to use ADO, use it. There ARE advantages to using ADO. However,
please don't waste your time, or ours, trying to justify your choice by
offering specious arguments against an alternative library you obviously
know nothing about.

-ralph

 

[Jamie Collins]

I was pointing out that DAO could be used for data access for any of those
databases

Not in my experience: Oracle + DAO is way too flaky.

Jamie.

--

 

[Jamie Collins]

I can't see what is crippled about explicitly closing what one have
explicitly opened.

You shouldn't have to. That one must explicitly close/destroy DAO
objects in the correct order is a symptom of an underlying and
fundamental problem:

"[DAO provides] another example of poor teardown code. DAO has Close
methods that must be called in the correct order, and the objects must
be released in the correct order as well (Recordset before Database,
for example). This single poor object model behavior has led to the
misconception that VB leaks memory unless you explicitly set all the
local variables to nothing at the end of a function. This is a
completely false notion in a well-designed object model. VB can clear
the variables faster at the End Sub line than you can from code, and it
checks the variables even if you explicitly release your references.
Any effort you make is duplicated." Matt Curland: Advanced Visual Basic
6 (P110).

Jamie.
--

 

[Jamie Collins]

It looks like we have slightly different view of what "replacing" means.

On reflection, 'resurrected' may not be the correct word. Circa
Access2000, DAO was left to die. ADO was the new kid on the block:

"In previous versions of Access, Data Access Objects (DAO) was the
primary data access method. That has now changed. Although DAO is still
supported, the new way to access data is with ADO." (Intermediate
Microsoft Jet SQL for Access 2000:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k/html/acintsql.asp).

DAO didn't even get support for the contemporaneous Jet 4.0
enhancements. Problem was, ADO was never popular in the Access ghetto
(as you say, emotional attachment), then ADO classic was suddenly
stopped in its tracks by the .NET response to Java. Around the same
time, and just as sudden, Jet was also left to die:

"The Microsoft Jet OLE DB Provider and other related components were
removed from MDAC 2.6. Microsoft has deprecated the Microsoft Jet
Engine, and plans no new releases or service packs for this component."
(MDAC 2.8 Overview: Deprecated Components:
http://msdn.microsoft.com/library/d...us/mdacsdk/htm/mdac_deprecated_components.asp).

Presumably, the desktop version of SQL Server (MSDE, later SQL Server
Express) made it difficult to justify ongoing support for the mdb
format. Also, the apathy must have been hard to take: the SQL Server
team gave the Access world many gifts (table-level CHECK constraints,
the DECIMAL data type, vastly improved SQL DDL, 'fast foreign keys'
etc) in Jet 4.0 form and to this day it seems most Access power users
(including MVPs) haven't discovered them all. Let's face it people,
aaron tells it like it is: mdb (2003) = flaky (compact and repair?
concurrent users? security/permissions?)

For 2007 (and beyond), Access has become even more ghettoized. ADO
classic was too big for the Access team; DAO was an easy win. Jet was
too big for them; Access Data Engine is a good way to lock people in.

BTW Ralph, I'm not trying to mislead; rather, I'm trying to paint a
picture based on publically available information. The truth is not out
there because of MSFT marketing considerations and NDAs.

Jamie.

--

 

[Ralph]

On reflection, 'resurrected' may not be the correct word. Circa
Access2000, DAO was left to die. ADO was the new kid on the block:

"In previous versions of Access, Data Access Objects (DAO) was the
primary data access method. That has now changed. Although DAO is still
supported, the new way to access data is with ADO." (Intermediate
Microsoft Jet SQL for Access 2000:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k/html/acintsql.asp).

DAO didn't even get support for the contemporaneous Jet 4.0
enhancements. Problem was, ADO was never popular in the Access ghetto
(as you say, emotional attachment), then ADO classic was suddenly
stopped in its tracks by the .NET response to Java. Around the same
time, and just as sudden, Jet was also left to die:

"The Microsoft Jet OLE DB Provider and other related components were
removed from MDAC 2.6. Microsoft has deprecated the Microsoft Jet
Engine, and plans no new releases or service packs for this component."
(MDAC 2.8 Overview: Deprecated Components:
http://msdn.microsoft.com/library/d...us/mdacsdk/htm/mdac_deprecated_components.asp).

Presumably, the desktop version of SQL Server (MSDE, later SQL Server
Express) made it difficult to justify ongoing support for the mdb
format. Also, the apathy must have been hard to take: the SQL Server
team gave the Access world many gifts (table-level CHECK constraints,
the DECIMAL data type, vastly improved SQL DDL, 'fast foreign keys'
etc) in Jet 4.0 form and to this day it seems most Access power users
(including MVPs) haven't discovered them all. Let's face it people,
aaron tells it like it is: mdb (2003) = flaky (compact and repair?
concurrent users? security/permissions?)

For 2007 (and beyond), Access has become even more ghettoized. ADO
classic was too big for the Access team; DAO was an easy win. Jet was
too big for them; Access Data Engine is a good way to lock people in.

BTW Ralph, I'm not trying to mislead; rather, I'm trying to paint a
picture based on publically available information. The truth is not out
there because of MSFT marketing considerations and NDAs.

Jamie.

The problem with painting such pictures is that it is done with broad stokes
that often covers more than it reveals. Everything is wheels within wheels
and no single assembledge is ever representative of the whole.

For example, you suggested that MDB files are "flaky" because they need to
be occasionally packed, don't support concurrent users well, and have
security and permissions issues? Duh!

Perhaps, it would be of interest to you to learn that MDBs are a
"file-based" data store. ALL file-based solutions present these problems.
Any problem-domain that would have these items as a service-level
requirement would not find a file-based store an optimal solution.

However, with an application with more limited requirements, a simple file
and an engine that natively supports ISAM, can perhaps be an ideal solution.

As for the rest of your comments, I will not even attempt to address how
"too big", "easy win", "left to die", or &etc, might create a misleading
picture. But I will absolutely agree that MS marketing is also guilty of
providing such images. <g>

-ralph

 

[aaron.kempf]

you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?


DAO is the buggiest ass library i've ever used in my life; by far

I mean.. you can't even use CurrentDB... you have to build a variable
and set dbs = currentDB

it's laughable.. and I for one-- am glad that Microsoft is releasing a
new version of ADO

I would rather quit my job and go join the army and go to iraq-- then
ever use DAO ever again

-Aaron

 

[Ralph]

you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?
you don't see what's crippled about memory leaks?


DAO is the buggiest ass library i've ever used in my life; by far

I mean.. you can't even use CurrentDB... you have to build a variable
and set dbs = currentDB

it's laughable.. and I for one-- am glad that Microsoft is releasing a
new version of ADO

I would rather quit my job and go join the army and go to iraq-- then
ever use DAO ever again

-Aaron

<snipped>

In the face such eloquence for the disapprobation of an access library you
apparently don't understand, and an inablity to recognize that opportunities
for "memory leaks" exist within any programming context - a sensible reply
is futile, nor perhaps even warranted.

However, based on functionality, MS is NOT releasing a new version of ADO
with DAC 6 - Which is what I believe the original topic of this thread was
all about.

-ralph

 

[aaron.kempf]

well... technically-- they ARE releasing a new version.. RIGHT?

how can you ignore the FACTS?
have you even bothered to open up VISTA and look?

Memory leaks are rampant; I shouldn't need to explicity close
connections / db objects... etc

DAO _HANGS_ACCESS_ if you dont' explicitly close EVERYTHING

what a crappy ass language; what is the point in bringing it back?

ADO has _EVERYTHING_ that we need.
DAO is CRAP; it always has been and it always will be.

-Aaron

 

[aaron.kempf]

here are some references that illustrate the BUGGINESS of DAO
DAO is a piece of shit ass language that is only used by fat lazy
senile MDB dipshits.

I can do ANYTHING in ADO that you kids can do in DAO; but it's easier
and simpler





http://groups.google.com/group/micr...345?lnk=st&q=DAO+HANG&rnum=8#81e841175f082345

A search of Deja/Google (using 'Q244/7/99') suggests that this fix will

be included in SP7. A link to the 'hotfix' is given:


http://groups.google.com/group/micr...82?lnk=st&q=DAO+HANG&rnum=17#346a4c6951a35682

Is there a way to check to see if the DB is still
connected before it tries to communicate over the LAN?

Would this even help or is the LAN hanging always going to
crash the DB?

In a word: yes. Access-Jet has always been sensitive to even minor
hiccoughs on a network, down to a misbehaving NIC not even involved in
the
particular connection.

If you have a noisy network that you cannot fix, you might be well
advised
to look at the SQL Server/ MSDE options which will make your database
much
more error-resistant.


http://groups.google.com/group/micr...lnk=st&q=DAO+HANG+MDB&rnum=3#ae97b9b34446f323

but with Access 2000 ADO is
slightly faster.


http://groups.google.com/group/comp...lnk=st&q=DAO+HANG+MDB&rnum=7#9a25a8fea311448d

It's not just a matter of setting to Nothing -- you have to close
the object beforehand, if it's appropriate. In the following code,
you need to close the recordset, but not the database:

Dim db As DAO.Database
Dim rs As DAO.Recordset


Set db = CurrentDB()
Set rs = db.OpenRecordset([SQL])
[do your thing]


rs.Close
Set rs = Nothing
Set db = Nothing


Why don't you need to close the db variable? Because the CurrentDB
can't be closed -- it's the open one in the user interface.


If, on the other hand, you opened, say, the back end MDB, then you'd
need to close it before setting it's variable to nothing.


Now, why must you close the recordset before setting its variable to
nothing? Because there are two completely different (though related)
memory structures involved. The database variable is a pointer to a
location in memory. When you set it to Nothing, you've cleared the
pointer, but you haven't necessarily released the memory it pointed
to (theoretically, it *should* be released, but it often isn't).
Closing the recordset releases the memory it was using. Then setting
the variable to nothing cleans up the pointer.


Keep in mind that there are also situations where you could have
implicit references left open, rather than explicit ones. I can't
think of a clear example, but if you go through all your code and
implement .Close where appropriate before setting to Nothing and
still have the problem, I'll try to come up with a better
explanation.


http://groups.google.com/group/micr...nk=st&q=DAO+HANG+MDB&rnum=10#de9fd9c3d1973d78

Make sure you allways close your data access objects and set them to
nothing:


Dim db as database
Dim rs as recordset


set db=....
set rs=db.open......


your code


rs.close
set rs=nothing
db.close
set db=nothing


In some cases not cleaning up may cause the database to become
corrupted. Also if your program hangs the data access objects may not
be closed. So a good technique is having error handling everywhere.
Make sure that if you need to use the End statment that everything is
closed.

 

[aaron.kempf]

FINE RALPH

ALL FILE BASED DATABASE SYSTEMS ARE FOR FRIGGIN WUSSES
their only advantage _WAS_ PRICE -- which isn't an advantage anymore

you sit there and say that 'ADO was never popular'

WHERE DO YOU COME UP WITH THIS CRAP?

the real developers-- that embraced ADO-- are out in the real world;
solving problems.. BUILDING SOLUTIONS

where the DEFUNCT DAO DIPSHITS ARE STUCK IN THE 1ST GRADE

I don't believe that it is economically FEASIBLE to develop for Small /
Medium businesses with 2 different platforms.
I have achieved economies of scale, by using a single platform from A
to Z.

it is called ACCESS DATA PROJECTS

ADO was never 'stopped in its tracks'

I've been developing ADO every day for almost 10 years now.
It's easier, simpler than this VB.net _CRAP_.

And it's not going to placate VB6 developers to go back to YET ANOTHER
UNNECESSARY DATA ACCESS LIBRARY.

Microsoft and all you other dipshits made the mistaken conclusion: 'oh
shit they liked 1998 so lets go back to 1996'

I CAN DO ANYTHING IN ADO THAT YOU CAN DO IN DAO-- BUT I AM NOT TIED TO
A SINGLE OBSOLETE FILE-BASED DATABASE 'ENGINE'

ROFL

Access is a car without an engine and anyone that uses it for
anything-- should be drinking whiskey out of a paper bag on the side of
the street.

-Aaron
ADP Nationalist

 

[Jamie Collins]

you suggested that MDB files are "flaky" because they need to
be occasionally packed, don't support concurrent users well, and have
security and permissions issues? Duh!

Ooh, I missed one: they frequently go corrupt. The sweet irony is that
it is Access features, rather than Jet functionality, that
predominantly cause MDB file corruption.

Perhaps, it would be of interest to you to learn that MDBs are a
"file-based" data store. ALL file-based solutions present these problems.

MS SQL Server is a file-based SQL DBMS product and doesn't suffer these
problems. I do see a difference, though: Access/Jet is first and
foremost a file system with a SQL gateway. It's kind of ingenious but
one of those "Pay no attention to the man behind the curtain" things
i.e. look to hard and all the fun goes away because you can't take it
seriously anymore. No, it's better to suspend disbelief: "I do believe
it's a DBMS, I do, I do..."

I don't know what you mean by "ALL file-based solutions present these
problems." I have an elderly hard disk running dozens of
(non-business-critical) applications (all 'file-based'?) and I've never
defragged (just for fun really) and this has never been a problem. I
can't think of any application other than Access where I must
'manually' perform a compact/repair or similar action. Maybe I've
missed your point?

Jamie.

--

 

[Jamie Collins]

The problem with painting such pictures is that it is done with broad stokes
that often covers more than it reveals. Everything is wheels within wheels
and no single assembledge is ever representative of the whole.

In cartography, it's called 'generalization': the smaller the scale,
the less detail you can show.

There are practical problems associated with the full scale renderings
you seem to desire e.g.

"...What do you consider the largest map that would be really useful?"
"About a six inches to a mile."
"Only six inches!" exclaimed Mein Herr. We very soon got to six yards
to the mile. Then we tried a hundred yards to the mile. And then came
the grandest idea of all! We actually made a map of the country, on the
scale of a mile to the mile!"
"Have you used it much?" I inquired.
"It has never been spread out, yet," said Mien Herr: "the farmers
objected: they said it would cover the whole country, and shut out the
sunlight! So we use the country itself, as its own map, and I assure
you it does nearly as well."

Carroll, Lewis (1893): Sylvie and Bruno Concluded.

Jamie.

--

 

[Ralph]

Ooh, I missed one: they frequently go corrupt. The sweet irony is that
it is Access features, rather than Jet functionality, that
predominantly cause MDB file corruption.
problems.

MS SQL Server is a file-based SQL DBMS product and doesn't suffer these
problems. I do see a difference, though: Access/Jet is first and
foremost a file system with a SQL gateway. It's kind of ingenious but
one of those "Pay no attention to the man behind the curtain" things
i.e. look to hard and all the fun goes away because you can't take it
seriously anymore. No, it's better to suspend disbelief: "I do believe
it's a DBMS, I do, I do..."

I don't know what you mean by "ALL file-based solutions present these
problems." I have an elderly hard disk running dozens of
(non-business-critical) applications (all 'file-based'?) and I've never
defragged (just for fun really) and this has never been a problem. I
can't think of any application other than Access where I must
'manually' perform a compact/repair or similar action. Maybe I've
missed your point?

You didn't miss my point, you just don't seem to understand the nuance of
the name - SQL "Server" and the difference between it and Jet.

I can only assume most computing appears to you as a "man behind the
curtain", which makes any further attempts at education from me rather
silly. There are many good books out there. Perhaps you could take a few
courses at a local community college?

Good luck.
-ralph

 

[Ralph]

In cartography, it's called 'generalization': the smaller the scale,
the less detail you can show.

There are practical problems associated with the full scale renderings
you seem to desire e.g.

"...What do you consider the largest map that would be really useful?"
"About a six inches to a mile."
"Only six inches!" exclaimed Mein Herr. We very soon got to six yards
to the mile. Then we tried a hundred yards to the mile. And then came
the grandest idea of all! We actually made a map of the country, on the
scale of a mile to the mile!"
"Have you used it much?" I inquired.
"It has never been spread out, yet," said Mien Herr: "the farmers
objected: they said it would cover the whole country, and shut out the
sunlight! So we use the country itself, as its own map, and I assure
you it does nearly as well."

Carroll, Lewis (1893): Sylvie and Bruno Concluded.

It is interesting that you feel detail or greater understanding of internal
workings can only lead to obscurity, and also explains a great deal.

Good bye.
-ralph

 

[Jamie Collins]

you just don't seem to understand the nuance of
the name - SQL "Server" and the difference between it and Jet.

You seem confused.

Yes, I do differentiate between a file-based SQL product such as
Access/Jet and a file-based SQL product such as SQL Server; I even
said, "I do see a difference". It was *you* that said, "ALL file-based
solutions present these problems."

If you assume I'm a newbie then be patient and explain things in simple
terms. If you think I'm not a newbie then enough with the "go back to
college" insults, eh?

Jamie.

--

 

[Robert Morley]

I don't know what you mean by "ALL file-based solutions present these

problems." I have an elderly hard disk running dozens of
(non-business-critical) applications (all 'file-based'?) and I've never
defragged (just for fun really) and this has never been a problem.

In point of fact, SQL files need "Compacting" just as like Jet files do (SQL
Server calls it "Shrink Database"). The difference is that SQL Server can
be told to do this automatically in the background, where Jet-by it's
nature-doesn't do anything automatically. SQL Server's also a bit more
intelligent in terms of reusing space compared to Access, though there are
still a few oddities, like not automatically reclaiming space from dropped
variable-length columns (not even with a "Shrink Database"...you have to use
"DBCC CLEANTABLE" on each table in your database that you've ever dropped a
variable-length column from!!!). And yes, more than once, I've had
corruption in SQL files as well resulting in odd behaviour, where I had to
use the various DBCC commands to repair the file.

The long-and-short of it is that both solutions have their place, and both
have their problems. To debate the merits of using one over the other is
like debating the merits of using a fire vs. an oven. An oven does you no
good in a camping ground, and a fire does you no good in your kitchen.



Rob