List of Access XP bugs and not to do's?

[aaron.kempf]

at least I am standing up for what is right.

This OP can have a much much simpler time using Access Data Projects.

MDB is obsolete; anyone that is still using it should be fired for
being fat and lazy

-Aaron

 

[dbahooker]

yes I can't wait until google comes out with a database.

google deserves to kick microsofts fucking ass in the database market;
Microsoft just isn't committed enough / big enough to fix bugs while
delivering innovation

-Aaron

 

[David W. Fenton]

The Office product is on version 10 or 11 now? I am unsure and
frustrated as to how memo corruption is still in such a product?

If you're having memo corruption it's a sign of an UNSRELIABLE
NETWORK or UNRELIABLE WORKSTATIONS.

 

[David W. Fenton]

I know that the network connection drops quite regularily, which
maybe the cause of the problem, but this is out of my hands.

Why, then, are you blaming Microsoft for data corruption? The cause
of the corruption is your network techs' inability to maintain a
reliable network.

 

[dbahooker]

it's ridiculous that Microsoft is trying to spread FUD

you have nothing to FUD but Microsoft itself

-Aaron

He he, I would hope that MS didn't use this policy and that they would
better there [sic] product by adopting newer technologies, rather than
leaving a need for workarounds!

I think Microsoft wrote the book . Microsoft rightly spends more
money advertising than in developing new software. I think the gamble
I'm taking on with acquiring .NET capability may have been influenced
more by advertising than common sense . But if Microsoft has spent
all that money convincing companies to use .NET, I should leverage those
advertising dollars rather than fight against them.

Imagine that google brought out Google Databases!

From:

http://www.businessweek.com/technol...p+news_top+news+index_businessweek+exclusives

Microsoft CEO Steve Ballmer chats with BusinessWeek editors about Web
2.0's sky-high valuations and the new competition the company faces

Guys who can touch us in multiple places probably matter more than guys
who can touch us in any one place. And actually we don't really have our
big competition from any one company. Any one company, we know how to
compete with. It's alternate business models that we will have to
embrace or compete well with. You give me any enterprise software
company, O.K., and I'll say c'mon. We know how to go do that. We do do
that. And we're really pretty good at it. We haven't gotten any worse at
it. Boom. Boom. Boom. We know how to keep coming.

James A. Fortune
(e-mail address removed)

 

[aaron.kempf]

dont blame MDB flakiness on the network.. i've been there; done that!

when all is said and done; MDB isn't reliable enough to work in ANY
real-world networking scenarios

time to move to FREEWARE sql server, kids

-Aaron

 

[Adam]

Thank you. I will move the front ends off of the networks and initiate
the compact on close on the front ends to see if that resolves the
issue.

Nope they do not update Windows either. I am not joking when I call our
I.T and I.S division incompetent. Heck they have there group calendar
as a large post-it on the wall, and yes I work for a blue chip company!
It still makes me laugh.

 

[Master Programmer]

Dont be so fucking stupid. Its obviosly because he is using MS Access -
little more than a glorified excell spreadsheet - not a real RDBMS.

The Grand Master

 

[David W. Fenton]

I will move the front ends off of the networks and initiate
the compact on close on the front ends to see if that resolves the
issue.

Why do front ends need to be compacted?

 

[aaron.kempf]

why do front ends need to be compacted?

because the typical front-end / back-end 'split' is more complicated
than it first seems.

a) frequently there are 'temp tables' on the front end
b) frequently there are 'lookup tables' on the front end
c) some dipshits use a 3rd database for temp tables; but this is
unnecessary complexity

changing records in MDB format causes BLOAT-- because the chipmunks in
Redmond didn't care enough to make a more robust solution.

MDB is a dead solution.
I don't need a n-tier database architecture when I use ADP lol.. real
simple a SQL database and a SINGLE CONNECTION.

no screwing around with tables and queries; keep everything in one
place.

AND PERFORMANCE? I RUN CIRCLES AROUND YOU MDB IDIOTS. BOTH IN END USER
PERFORMANCE AND DEVELOPER PRODUCTIVITY.

MDB is completely obsolete; stop using it kids.
Fire anyone that still uses it and then spit on them.

-Aaron

 

[Bill Mosca, MS Access MVP]

I user local temp tables for complex reports. It saves lots of loading time.
These tables insert and delete data with every call to open the reports.
Deletes and inserts add to database bloat. Also if your users can create or
delete local tables/queries, compacting on close would be a good idea.

 

[aaron.kempf]

saves loading time?

I used queries that don't crap out when they don't get 'too compelx'

that saves lots of loading time

-Aaron
ADP Hitman

 

[dbahooker]

when is Microsoft going to come out with a simple web-based ODBC
database?

it would totally rock

GO GOOGLE, HERE WE GO NOW
INTO DATABASES

WE WANT YOU

-Aaron

 

[David W. Fenton]

I user local temp tables for complex reports. It saves lots of
loading time. These tables insert and delete data with every call
to open the reports. Deletes and inserts add to database bloat.
Also if your users can create or delete local tables/queries,
compacting on close would be a good idea.

Temp tables should not be stored in the front end. You should have a
separate tmp.mdb for those. Many in these precincts advocate
creating it on-the-fly (and handily provide code for it), but I just
keep a copy of it available and copy over top of it to get a fresh,
compacted copy.

So, again: why do properly-designed front ends need to be compacted?

Secondly, compacting may be warranted if users are creating and
deleting tables, but in my opinion, compact-on-close is *NEvER*
warranted as it's just way too dangerous. Compact when needed, with
a backup beforehand (if it's needed -- with a front end, it's not,
since front ends are fungible), but don't compact as a matter of
course.

Compact on close is one of the dumbest and most dangerous features
introduced into Access 2000 (among a host of competitors).

 

[Adam]

whoa whoa whoa... whats dangerous about compact on close?

I've set this on around 12 of my database users machines now.

 

[Rick Brandt]

whoa whoa whoa... whats dangerous about compact on close?

I've set this on around 12 of my database users machines now.

Back when repairing a database was a separate operation from compacting, the
help file clearly indicated that you should only repair a file that Access
indicated needed repairing so I think repairing is actually the risky operation.

Starting in Access 97 The Compact and Repair operations were combined. During a
compact Access might determine that the file also needs repairing thus exposing
you to the risk that a repair involves. I don't know if "just compacting"
involves any risk at all as long as the PC is not interrupted during the
process. I also don't know if compact on close would attempt a repair like
doing a compact from the menu might.

In my opinion it is just not necessary to compact that often. All my apps are
split, compact on close only compacts the front end, and I see no point in
compacting a front end so I just have never used compact on close. It is easier
and faster to just replace the front end than it is to compact it.

 

[aaron.kempf]

David;

that's ridiculous.. NOBODY NEEDS A THREE-TIER DATABASE SYSTEM

keep all your data- temp tables, permanent tables - in Access Data
Projects and you don' have any problems

AUTOSHRINK IS SET TO ON BY DEFAULT
AUTOGROW IS SET TO ON BY DEFAULT

 

[aaron.kempf]

i mean seriously here

any 'properly designed'

why don't you eat a DICK fucknut

a 3-tier database system is NOT PROPERLY DESIGNED

I only have 1 tier and i'm bigger, better, faster, more scalable, more
stable... and EASIER DEVELOPMENT

eat a big fat dick sandwich for thanksgiving you fucking moron

-Aaron

 

[David W. Fenton]

whoa whoa whoa... whats dangerous about compact on close?

Well, to start off with, if your app is properly set up, you'll just
be compacting a front end, which should never ever need to be
compacted, so it's a useless feature.

However, when you open the back end, you could potentially hose a
recoverable MDB by compacting it. Replicated databases, for
instance, are particularly susceptible to losing replicability when
corrupted and compacted/repaired. Since compact on close cannot be
avoided once it's turned on, the result is that you could lose a
working database that is still usable with some form of corruption
in it.

I've set this on around 12 of my database users machines now.

I think it's a worthless and dangerous feature that should never
ever be used in any circumstances.

 

[aaron.kempf]

if your app is properly setup; you shouldn't be compacting or dealing
with front-end; backend

using Access Data Projects is 100 times easier to manage

lose the training wheels kids

-Aaron