MS Access sucks

I've been sitting here for 15 minutes waiting for my frikkin Oracle ODBC query to finish. I could've easily done it with DBI and baked a goddamn pie by now. That's what I get for thinking it would be quicker to do it with Microsoft....

I would think it''s probably the ODBC drivers that are slowing you down more than access itself.

Microsoft''s ODBC driver for Oracle isn''t the most efficient thing I''ve ever seen, to put it mildly. Are you using it or the Oracle supplied ODBC drivers?

15 minutes?? Did you accidentally do a cartesian product?

Microsoft''s ODBC driver for Oracle isn''t the most efficient thing I''ve ever seen, to put it mildly.

Seems like I remember hearing the same thing, back when I worked with Oracle. I just can''t imagine what MSoft would have to gain by making their main database competitor''s software seem inordinately slow.

Well in this case it was my bad. I didn''t join two fields that needed to be joined. Still, you''d think it would have notified me instead of sitting there churning until the apocalypse. Then I just went and wrote it in perl and was done in about five minutes. I''m never gonna learn...

I know the ODBC drivers suck. It''s just that they''re right there, and you think you have a simple little query, so you say ""what the hell, I''ll just use ODBC"".

Access isn''t so bad when compared to something like Progress. Who needs relationships?

Wussies! I coded a whole billing application in Access, held together with blood, sweat, and tears.

Then we replaced it with a $200k accounting system.

Thank god. Would have hated to support that.

Good lord. I deal with a lot of MS Access 97 DB''s here. Mostly I yell at the morons who made them in the first place (the end user) and then convert them to .NET/MS SQL Server 2k.

God, the horror. You will never meet anyone who hates access more then I do.

"hubbinsd" wrote:

Well in this case it was my bad. I didn''t join two fields that needed to be joined. Still, you''d think it would have notified me instead of sitting there churning until the apocalypse. Then I just went and wrote it in perl and was done in about five minutes. I''m never gonna learn...

I know the ODBC drivers suck. It''s just that they''re right there, and you think you have a simple little query, so you say ""what the hell, I''ll just use ODBC"". :)

Sorry, but you can''t blame Access ODBC if you fed it a crappy query. Not that I''m defending either one, mind you, but if the problem is the chair-keyboard interface, no sense blaming the software.

And let''s not get started on how many times a day I blame the software on to find out it was me... it was me...

Well I posted before I realized it was my bad. But the software should still realize that my query didn''t make sense...perl DBI would spit out an error in about 0.0000001 seconds. Access & ODBC had me sitting there with my thumb in my butt and posting to some gaming web site about how slow they are

I don''t think there''s anybody in the world who can seriously say MS Access doesn''t suck unless they don''t know it''s a database and think it''s a magic SQL eating machine.

Also, install Oracle''s ODBC driver.

I don''t think there''s anybody in the world who can seriously say MS Access doesn''t suck unless they don''t know it''s a database and think it''s a magic SQL eating machine.

I think it has it moments where it doesn''t suck. Usually when you want to make a small personal database for something like say personal finances or something. But a majority of the time it does suck.

I think Hubbins was stretching the limits of what Access is really supposed to be used for. As I recall there are tools in the oracle client that allow you to easily build queries against an oracle database, so I don''t really see the need to use Access in this situation.

Access is great if you''re doing a small database. The Jet Engine wasn''t made for large amounts of data.

On preview: Looks like Stric9 beat me to it.

sh*te! Most of our desktop apps are done in Access 2000. The problem with working with local government is that the Network Nazis have just enough funding to keep our network to 2-3 year old standards.

I hate access.

At my last job, my boss (the owner of the small co) wanted to (as she put it) ""make an Access developer out of me yet."" Needless to say, I ran for the hills. The sad thing is, what happens is some clown takes one access class and thinks they can solve their company/organization''s problems with this newfound wealth of information. What they don''t know is that while you can make stuff quickly with access, it''s nothing but a hastily produced turd.

Access was never meant to do the things people have it doing. It was meant to be a small desktop database, not an enterprise information repository. I''ve seen some rediculous uses for access ""databases,"" even recently though if I divulged what for I''d further tarnish already hideous reputations. People of the world, stop using Access in your business. It only costs you more money and time in the end.

Actually, you''re all sort of wrong on the idea access is for small databases. Access is merely a prototyping tool and should not be used for real DB''s.

"Stric9" wrote:
I don''t think there''s anybody in the world who can seriously say MS Access doesn''t suck unless they don''t know it''s a database and think it''s a magic SQL eating machine.

I think it has it moments where it doesn''t suck. Usually when you want to make a small personal database for something like say personal finances or something. But a majority of the time it does suck.

I think Hubbins was stretching the limits of what Access is really supposed to be used for. As I recall there are tools in the oracle client that allow you to easily build queries against an oracle database, so I don''t really see the need to use Access in this situation.

Ok, to clear things up, here''s the dilly-yo.

Our database is indeed Oracle - our vendor sets up our staff with MS Access & the Oracle ODBC drivers for generating reports from the database. As the SysAdmin, I have to work with Access sometimes to make sure that new reports etc. will work for the rest of the staff. I''m not about to try to to retrain everyone on Oracle Discoverer or something like that -- it''s just not worth the time. If you look at my follow up post you''ll see that my Access problem was ""my bad"", but I still stand by my statement that Access sucks, whether you''re ""stretching it to the limits"" or not.

If you look at my follow up post you''ll see that my Access problem was ""my bad"", but I still stand by my statement that Access sucks, whether you''re ""stretching it to the limits"" or not.

Agreed. Who hasn''t made the bad query now and then?

However, the idea your company gives them access to build queries is unforgivable The instant you do that, as we did here, some yahoo goes and buys an Access for Dummies book, and proceeds to live up to the latter part of the title. Then the programmers, such as I, are forced to ""fix"" these damn things when they shouldn''t have been built, and were never authorized in the first place.

Of course I work for a healthcare company with all kinds of ignorant doctors (when it comes to technology, they are sooo ignorant, believe me) who of course assume that having a Doctrine makes them god so you obviously know nothing. It''s that mentality that really makes Access shine in the limelight. Ugh.
[/quote]

"Shaolin_Monkey" wrote:

sh*te! Most of our desktop apps are done in Access 2000. The problem with working with local government is that the Network Nazis have just enough funding to keep our network to 2-3 year old standards.

I hate access.

Tell them you can do it all in linux and mysql for only the labor cost.

"Dr.Ghastly" wrote:

Actually, you''re all sort of wrong on the idea access is for small databases. Access is merely a prototyping tool and should not be used for real DB''s.

That would be great, if the jet engine didn''t use some hacked SQL type that isn''t supported by real databases.

You are better off doing a processflow in Visio and handing it to your local Oracle/Sybase/DB team.

Then the programmers, such as I, are forced to ""fix"" these damn things when they shouldn''t have been built, and were never authorized in the first place.

Ugh - that brings back some bad, bad memories of ""under-the-desk"" Access databases that we were encouraged to link into REAL corporate database systems. Is it unbusinesslike to say ""HAHAHAHAAHAHAHAHA! No."" to your customers?

When I said prototyping tool I didn''t mean JUST for the SQl DB. I meant the application front end as well.

A process flow is nice and all, for the SA/BA to give to the programmer, but the programmer should still prototype the entire thing so they can demo the application to the end user to make sure that is what they were looking for. If it is, then you begin the final app development in whatever RAD (or not) tool your company uses. If the end user doesn''t like it, Access can provide a very fast and easy method for you to update the prototype before begginning the real work.

Of ocurse this is ""How it SHOULD be done"" and not ""How it usually happens."" Damn end users..

Also, Access doesn''t have a hacked SQL type. It merely contains ODBC drivers for many different DB''s. It still uses the basic (very basic) SQL support that MSSQL does.

"KillerTomato" wrote:
Then the programmers, such as I, are forced to ""fix"" these damn things when they shouldn''t have been built, and were never authorized in the first place.

Ugh - that brings back some bad, bad memories of ""under-the-desk"" Access databases that we were encouraged to link into REAL corporate database systems. Is it unbusinesslike to say ""HAHAHAHAAHAHAHAHA! No."" to your customers? ;-)

Yes. But we do it anyways in some cases.

To give you an idea of my personal hell, we have over 2,500 of these damn user created Access DB''s *I* get to fix/support/convert/complain about.

"Dr.Ghastly" wrote:
"KillerTomato" wrote:
Then the programmers, such as I, are forced to ""fix"" these damn things when they shouldn''t have been built, and were never authorized in the first place.

Ugh - that brings back some bad, bad memories of ""under-the-desk"" Access databases that we were encouraged to link into REAL corporate database systems. Is it unbusinesslike to say ""HAHAHAHAAHAHAHAHA! No."" to your customers? ;-)

Yes. But we do it anyways in some cases.

To give you an idea of my personal hell, we have over 2,500 of these damn user created Access DB''s *I* get to fix/support/convert/complain about.

Ugh...I feel for you. I''ve started taking great pains to get us away from Access as much as possible. In lieu of Access reporting, I''ve been writing scripts that dump stuff from Oracle into MySQL and then giving people ColdFusion pages that will pull the information they need from there -- it avoids Access completely and takes all the load off our Oracle database so that ""real work"" can get done.

We here prefer ASP.NET and/or PHP over ColdFusion

To give you an idea of my personal hell, we have over 2,500 of these damn user created Access DB''s *I* get to fix/support/convert/complain about.

2500?! Wow. I''d ask what they could possibly need that many databases to keep track of, but I''m sure the answer would drive me to madness.

Healthcare company. And, technically they don''t. 90% of the time the data they store in these evil Access DB''s is in our SQL Data Wherehouse. These people are control freaks and we repeatedly have to tell them ""No, it is not YOUR data. It is MY data.""

That''s the fun part of the job. Being the Data Nazi can be very rewarding at times.

There are an awful lot of people on GWJ who work for health care companies. I''m not sure if that''s great or terrifying

At least your people are using Access; I once worked support in a company full of accountants. They tried to use Excel for everything - including databases. My first real ""database"" job was managing 40+ workbooks containing contact information on healthcare (there''s that word again) providers. Every time I tried to talk them into converting they said there was too much cost and time involved. And now that I know what I know, they were right - it needed to be in a SQL database. I got out of there.

Access DB''s have there uses, but do give me a real database any day.

hubbinsd, have you looked at Crystal for reports? I''m guessing you have an ruled that out. I''m just curious why? If you feel like continuing the discussion...

[edit for spelling and grammar]

"Nameless" wrote:

At least your people are using Access; I once worked support in a company full of accountants. They tried to use Excel for everything - including databases. My first real ""database"" job was managing 40+ workbooks containing contact information on healthcare (there''s that word again) providers. Every time I tried to talk them into converting they said there was too much cost and time involved. And now that I know what I know, they were right - it needed to be in a SQL database. I got out of there.

Hah. You know. I forgot about our 1200 excel databases. Luckily we have nothing to do with them except when the morons convert them to Access and then ask us to fix them...

"Nameless" wrote:

hubbinsd, have you looked at Crystal for reports? I''m guessing you have an ruled that out. I''m just curious why? If you feel like continuing the discussion...

[edit for spelling and grammar]

Crystal reports can *edited for content so the parents don''t complain about their kids being taught dirty words by perfect strangers. After all it isn''t like THEY ever use them around their kids*

If you do work on VB6 or .NET (any .NET language) I *highly* reccomend ActiveReports. Youc an get a fully functional demo for it off their site: Datadynamics.com. The only catch on the demo is that it puts a little disclaimer at the bottom of the report. Big deal. It exports to word, excel, HTML, and even PDF. It seriously rocks.

I believe it supports other languages, but I never looked that close since we are a VB shop here, mostly.