ADO 6

  • Thread starter Thread starter aaron.kempf
  • Start date Start date
I do understand the differences.

engine-less database systems don't perform; they're not stable

MDB is for weenies
 
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.
Click to expand...

You are correct, I do believe you to be a newbie.

I apologize for sounding too harsh.

Anyway this conversation is going nowhere and has long left the original
topic.

live long and prosper.
-ralph
 
the original topic is that you DAO dipshits should be drinking whiskey
out of a paper bag on the side of the street.

I can do ANYTHING in ADO that you can in DAO

try me-- i've got a solution for your crap and it doesn't involve
mixing programming language and SQL syntax.

pure, simple TSQL for anything that you can do in DAO
and I can call it from ADO.. I don't have to rewrite all of my code
when the obsolete DAO has a new security problem

and I dont subject my users to crashes and hangs just because im a fat
lazy sloth that can't adapt to the 21st century

you kids are stuck in the 90s

-Aaron
 
the only place for MDB is in a time capsule; about how ****ing stupid
you kids were back in the 90s
 
sorry I meant 1gb.. not 2gb

ROFL

-Aaron


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.

--
Click to expand...
 
Ralph said:
I do believe you to be a newbie.

I apologize for sounding too harsh.
Click to expand...

Be as harsh as you like (after all, I have to put up with aaron, here
this conversation is going nowhere and has long left the original
topic.
Click to expand...

Actually, it hasn't. The flakiness of the MDB format is the underlying
reason for the OP's post, I believe. I've never known anyone to try to
defend the MDB format as regards 'flakiness' - the necessity for
regular 'manual' compact/repair to avoid frequent corruption and bloat
- so I'd assumed it was indefensible ...until you came along. However,
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?)

Jamie.

--
 
Bitch Ass Whore;

re: ALL file-based solutions present these problems

SQL Server is _NOT_ a file based database.

it _HAS_ a database _SERVER_.

Access does not.

I'm not a newbie; I've probably written more MDB and more SQL Server
databases than ANYONE ELSE ON ANY OF THESE FORUMS

I strongly agree with your diagnosis:
However,
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?)
Click to expand...

I don't believe that there is a single person that should be using MDB
for a single record and a single user anywhere in the world.

I would rather use PEN AND PAPER than MDB.

I just have been called out of bed at 2am-- TOO MANY TIMES to diagnose
Access MDB locking / concurrency problems

-aaron
 
I know what Jet is.. do you even know what it stands for?

ROFL

it stands for

J = CRAPPY
E = OBSOLETE
T = DATABASE_WITHOUT_AN_ENGINE
 
seriously

can you kids even tell me what it stands for?
any Non-MVPs can tell me without looking it up?

-Aaron
 
Robert said:
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.
Click to expand...

I concur with you, the person who said "ALL file-based solutions
present these problems" made a misstatement by including the word
'solutions'. They possibly meant all *files* exhibit problems. The
difference is, SQL Server 'automatically' mitigates such problems (a
solution?) whereas Jet leaves it to 'manual' intervention (and Access
causes the problems in the first place said:
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.
Click to expand...

I don't think SQL Server and MDB are mutually exclusive, as your
fire/oven analogy suggests, because both can be used for the data store
in an Access project (which is the OP's point, I think).

Jamie.

--
 
SQL SERVER-- YOU ****ING IDIOTS-- DOESNT NEED COMPACTING BECAUSE
AUTOSHRINK IS TURNED ON BY DEFAULT
 
MDB _CANT_ BE USED AS A DATASTORE FOR AN ACCESS PROJECT

OPEN THE BOOK; KNOW THE TECH BEFORE YOU TALK SHIT


ADO IS COMING BACK AND DAO IS _STILL_ TOO BUGGY FOR REAL WORLD USE
 
You earlier said you have programmed for many many years. From the languge
you use, I doubt that.
 
if you're not pissed off then you're not paying attention

just because I use 4 letter words-- when Microsoft has a MAJOR
MARKETING FAILURE ON THEIR HANDS-- Does that make me a bad programmer?

Henning are you telling me that MDB _CAN_ be used as a 'backend for an
Access Project'

ROFL

read the book before you start talking; dipshit

ADO is making a comeback and you DAO pansies should **** yourselves
 
I don't think SQL Server and MDB are mutually exclusive, as your
fire/oven analogy suggests, because both can be used for the data store
in an Access project (which is the OP's point, I think).
Click to expand...

Good point, my fire/oven analogy kinda breaks down there...I don't think
they're mutually exclusive, either.



Rob
 
SQL Server ISNT MORE DIFFICULT to deploy than MDB
ADO isn't MORE DIFFICULT TO USE THAN DAO

I'm just stoked that there is an ADO revival; thank god
I would rather clean toilets than use DAO

-Aaron
 
Me pissed off?? Nono just amused.

Just for the record, I use MySQL so I don't have to load that DotNet
Framework 2.x overload just to install an SQL-server.
MySQL installs in 10 minutes, not two hours.

/Henning
 
Back
Top