ADO 6

[aaron.kempf]

I do understand the differences.

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

MDB is for weenies

 

[Ralph]

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.

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

 

[aaron.kempf]

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

 

[aaron.kempf]

it doesn't NEED compacting because it's automated; out of the box

 

[aaron.kempf]

the only place for MDB is in a time capsule; about how ****ing stupid
you kids were back in the 90s

 

[aaron.kempf]

go and play with your tonka truck you mdb script kiddie

-Aaron

 

[aaron.kempf]

ROFL

i'll bet that a map that large WOULDNT EVEN FIT INSIDE OF A 2GB MDB
FILE

rofl

 

[aaron.kempf]

sorry I meant 1gb.. not 2gb

ROFL

-Aaron

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.

--

 

[Jamie Collins]

I do believe you to be a newbie.

I apologize for sounding too harsh.

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.

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.

--

 

[aaron.kempf]

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?)

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

 

[dbahooker]

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

 

[aaron.kempf]

seriously

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

-Aaron

 

[Jamie Collins]

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.

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

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.

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.

--

 

[aaron.kempf]

SQL SERVER-- YOU ****ING IDIOTS-- DOESNT NEED COMPACTING BECAUSE
AUTOSHRINK IS TURNED ON BY DEFAULT

 

[aaron.kempf]

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

 

[Henning]

You earlier said you have programmed for many many years. From the languge
you use, I doubt that.

 

[aaron.kempf]

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

 

[Robert Morley]

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).

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



Rob

 

[aaron.kempf]

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

 

[Henning]

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