H
Henning
I can't see what is crippled about explicitly closing what one have
explicitly opened.
/Henning
explicitly opened.
/Henning
<snipped>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
Jamie Collins said: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.
<snipped>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
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?
Jamie Collins said: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?
Jamie Collins said: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.
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.
Jamie Collins said: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.
Jamie said: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.
--
so far your defence - "ALL file-based solutions present these problems"
- does not stand up to scrutiny e.g. SQL Server is a file-based SQL
product widely perceived to be 'less flaky' (and this is the OP's
point, I believe i.e. if SQL Server available for Access, why use
'flaky' MDB?)
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.