Why do Corporate DB persons hate MS Access

R

Ray S.

I have a continuing battle with our database managers. They do not want me to
use MS Access. They're pushing everyone into using Cognos. In my department
we like the flexibility to create ad hoc reports and develop rapid
applications to crunch our data. We also like the ease of integration with
Excel, which is our primary analysis tool. I would appreciate some good
arguments to convince the dB administrators and managers to get off our backs.
 
R

Ray S.

Chris O'C via AccessMonster.com said:
You won't get the dbas and managers off your backs until they hire at least 1
expert Access developer to show how to build stable, reliable, fast Access
apps. Your managers and IS people have witnessed the horrible problems and
security risks untrained non-developers create with Access and they've had to
fix them when they didn't have the time or resources. They blame the tool
instead of the untrained people who created the messes.

Get an Access expert to show them what Access can do in the hands of a
competent developer and most will change their minds. Some never will.

Chris
Microsoft MVP

We have Access experts, but even they prefer SQL Server...nobody likes
Access...I'm trying to figure why.
 
D

David Portas

I have a continuing battle with our database managers. They do not want me to
use MS Access. They're pushing everyone into using Cognos. In my department
we like the flexibility to create ad hoc reports and develop rapid
applications to crunch our data. We also like the ease of integration with
Excel, which is our primary analysis tool. I would appreciate some good
arguments to convince the dB administrators and managers to get off our backs.

There are many potential problems with putting database and data
analysis tools on desktops or on workgroup servers: security; data
integrity; multiple versions of the truth; duplication of effort;
difficulty of guaranteeing SLAs; expense and complexity of support.
These issues quite rightly concern those charged with enterprise
information management responsibilities. You can't expect them to get
off your back unless you can demonstrate that such concerns are
properly addressed.

These days there are plenty of cost-effective options for delivering
data and analysis using enterprise BI tools, tiered applications and
client-server DBMS. Those solutions tend to be designed with security,
high availability and manageability features in mind - features that
Access just doesn’t have, was never intended to have and never will
have. So there are at least some reasons why management may not be
convinced that Access is the right tool for the job.
 
D

David Portas

We have Access experts, but even they prefer SQL Server...nobody likes
Access...I'm trying to figure why.- Hide quoted text -

We have Access experts, but even they prefer SQL Server...nobody likes
Access...I'm trying to figure why.

Have you asked them?

Access is an application development tool whereas SQL Server is a DBMS
so they are not even directly comparable. As a data store however, SQL
Server has numerous advantages and features over the Jet/ACE engine
used in Access. Why do you doubt it?
 
A

Armen Stein

Access is an application development tool whereas SQL Server is a DBMS
so they are not even directly comparable. As a data store however, SQL
Server has numerous advantages and features over the Jet/ACE engine
used in Access. Why do you doubt it?

Access makes an excellent front-end application for SQL Server. Maybe
your corporate db folks hate Access as a database, but wouldn't mind
it so much as a front-end application if the data was stored in SQL
Server and if the applications were well-written and didn't cause them
problems.

We've built lots of client-server apps using Access and SQL Server
that IT departments, even picky ones, have no problems with. They get
the strengths of Access as a very rapid, low-cost developent
environment and the power and safety of SQL Server.

There are a lot of resources on this topic. I have a slide deck that
covers the basics called "The Best of Both Worlds" at:
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp

Hang in there,

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
R

Ray S.

I don't doubt it. I agree with you, but they don't like using Access at all.
They claim anything you can do in Access can also be done in SQL.
 
R

Ray S.

There's some truth to what you say, but I think there's more to it than that.
They agree that Access is useful as a front end. My suspicion is that they
want to control all queries and reports by having to route requests to them
for development, eliminating the ad hoc flexibility provided by Access.
 
R

Ray S.

Thanks, I checked out your slide deck. I understand and fully sympathize with
the "safety" or security concerns, but I never ask them for write access to
any of the DBMSes. Our department deals with financial data. We are very
small compared to the rest of the company. Nobody outside our group has
access to our databases and we must all sign non-disclosure and insider
trading agreements.
 
R

Ray S.

Points taken...see my reply to Armen Stein. While we are a very large
international corporation, our financial service group has only six full time
employees and only three of us, including our boss, have high level access to
or maintain any of our Access databases, with only one person actually coding
or managing specifically assigned ones.
 
A

Armen Stein

There's some truth to what you say, but I think there's more to it than that.
They agree that Access is useful as a front end. My suspicion is that they
want to control all queries and reports by having to route requests to them
for development, eliminating the ad hoc flexibility provided by Access.

Well then, it isn't a problem with Access at all. It's a power and
control issue. Sorry, that one can't be solved so easily. For
starters, you would need change to be driven from above, for example
by the CEO/CFO level. They need to understand how much it's costing
for simple, safe read-only requests to be slowed down and routed
through IT.

Good luck.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
T

Tony Toews [MVP]

Chris O'C via AccessMonster.com said:
You won't get the dbas and managers off your backs until they hire at least 1
expert Access developer to show how to build stable, reliable, fast Access
apps. Your managers and IS people have witnessed the horrible problems and
security risks untrained non-developers create with Access and they've had to
fix them when they didn't have the time or resources. They blame the tool
instead of the untrained people who created the messes.

And, of course, folks never use Excel to handle data in "unusual"
fashions either. Yup, blame the tool.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
K

Klatuu

All your points are correct, but do ignore the specifics.
The tools and methods you discuss require trained professionals to use.
This is where IT fails the departmental user. The department does not have
the expertise of the budget and usually not access to those tools. The
department has to request support from IT. These departmental requests are
mostly ignored by IT or the turn around time is more than the department can
wait.

This is exactly where you will find Access a very useful tool. It can be
used as a front end for departmental users to get the data they need to
execute their processes.

Now comes the ignorance. Many companies will allow read only access to
their enterprise data through Excel, but absolutely freeze up when you ask
the for the same thing using Access. IT types know enough to know Access
can manipulate database data, but why they can't see all they really need to
protect the content and integrity of the enterprise data is to provide some
Views and allow the departments to work with the data as needed.

Much of the problem is also about control. IT has the belief they are the
Priesthood of the data and the unwashed masses don't really even know what
they need. If an request in properly reverent and humble and deemed worthy
the priests will, in their own good time, deliver what they think the serfs
need whether it is what they really requested.

I have seen some good IT departments that see their users as customers
rather than as a nucense and provide the knowledge and reap the rewards of
Access used properly.

I once did a 5 year international enterprise level project. Access was used
for prototyping because you can put together a form and some functional data
in almost no time.

But, I know the frustration. I am even seeing companies now that will not
allow Access to be installed on any computer. I know of one that does that,
but their business analysts are provided with a copy of SQL Server
Management Studio to query data for research.
Go figure.

I have a continuing battle with our database managers. They do not want me
to
use MS Access. They're pushing everyone into using Cognos. In my
department
we like the flexibility to create ad hoc reports and develop rapid
applications to crunch our data. We also like the ease of integration with
Excel, which is our primary analysis tool. I would appreciate some good
arguments to convince the dB administrators and managers to get off our
backs.

There are many potential problems with putting database and data
analysis tools on desktops or on workgroup servers: security; data
integrity; multiple versions of the truth; duplication of effort;
difficulty of guaranteeing SLAs; expense and complexity of support.
These issues quite rightly concern those charged with enterprise
information management responsibilities. You can't expect them to get
off your back unless you can demonstrate that such concerns are
properly addressed.

These days there are plenty of cost-effective options for delivering
data and analysis using enterprise BI tools, tiered applications and
client-server DBMS. Those solutions tend to be designed with security,
high availability and manageability features in mind - features that
Access just doesn’t have, was never intended to have and never will
have. So there are at least some reasons why management may not be
convinced that Access is the right tool for the job.
 
D

David W. Fenton

And, of course, folks never use Excel to handle data in "unusual"
fashions either. Yup, blame the tool.

I think it was through your blog, Tony, that I was pointed to this:

http://neopoleon.com/home/blogs/neo/archive/2003/09/29/5458.aspx

(for some reason, the images don't load when I view this page; oh, I
see, the archive version doesn't have a base URL defined, so the
links are broken; the images are here:
http://www.neopoleon.com/blog/images/excel/1.jpg to
http://www.neopoleon.com/blog/images/excel/11.jpg)

Didn't you also post a pointer to a discussion of this topic on your
blog in the last year? I remember going there and adding to the
discussion myself, but can't figure out where it was now.
 
D

David W. Fenton

We have Access experts, but even they prefer SQL Server...nobody
likes Access...I'm trying to figure why.

I don't even understand the statement. You may prefer SQL Server as
your data store, but that doesn't mean anything at all about what
you use to develop your front end.

This is yet another example of the problems that come from failing
to distinguish Jet and Access. Jet is the db engine, and it's Jet
that most DBAs mis-trust (because they aren't smart enough to figure
out how to use it reliably), and they often don't get that Access is
the front-end development tool and can be used with almost any
database engine out there.

Basically, I'd say they are against Access because they are
ignoramuses.
 
D

David W. Fenton

it isn't a problem with Access at all. It's a power and
control issue.

A very large number of these "programming" problems are actually
administrative problems. Or "people" problems.
 
A

Armen Stein

On Fri, 24 Oct 2008 00:49:33 GMT, "Chris O'C via AccessMonster.com"

Hi Chris,
Then they aren't Access experts. They have limited Access dev skills and
don't know what Access is capable of. Access experts can do so much more
with Access than with SQL Server because Access is a RAD front end dev tool
and can use many different back end data stores, including SQL Server, so
they aren't giving up superior data engine support by using Access as the
front end.
Agreed.

SQL Server is a powerful back end tool, but it's a back end tool. It doesn't
have custom data display options (forms and reports), it doesn't have a point
n click query designer, it doesn't have a point n click macro designer, it
doesn't have a simple programming language nondevelopers can use to automate
apps quickly, it doesn't have wizards to help build front end apps quickly.
It doesn't shine where Access does because it's a different type of dev tool.

I agree on most of your points, but some things have changed with SQL
Server.

SQL Server Reporting Services (SSRS) is a very powerful report design
and delivery system. It has drag and drop design, code behind, graphs
and charts, etc. It has built-in scheduling and subscription
capabilities and native output to PDF, Excel and HTML. SSRS isn't as
easy to develop as Access reporting, but it's an alternative that
professional developers should now consider. It's a free addition to
SQL Server.

And SQL Server has a very good graphical query designer. Some of the
developers on our team prefer it over Access. It isn't exactly the
same, and Access has much better on-the-fly filtering of the data, but
it's a far cry from the old days of typing SQL.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
N

NTC

Cognos is a great product - a great mining tool for large DBs. It was an
independent company for a long time and then was bought by IBM. But
SQLServer and Access are also fine products. If I was the IT Department and
fully invested in Cognos - I would tell you to use Cognos also....its the
pragmatic view to a sunk cost of investment in a reasonably good tool.

It is like comparing an 18 wheeler (Cognos) with a PickUp Truck (Access).
It is not that the technology is better/worse between an 18 wheeler and a
pickup truck. Discussing the technology misses the point. Anything you need
to do in Access you surely can do in Cognos.... so they want you to go with
what is mainstream to their IT department. If you worked for another
company that was Oracle oriented - they would be referencing you to Oracle....

You ask for arguments to justify Access; in my past corporate experience it
comes down to who provides support....if you need to rely on IT/Cognos for
support then you should do it their way with Cognos...but if you are self
contained then you should be able to use whatever tool you want....
 
K

Klatuu

You analogy is correct.
An 18 wheeler is very expensive to operate, requires a trained operator, and
is slow getting up to speed. So, why would you use an 18 wheeler when a
pickup will do?
 
D

David W. Fenton

Then they aren't Access experts. They have limited Access dev
skills and don't know what Access is capable of. Access experts
can do so much more with Access than with SQL Server because
Access is a RAD front end dev tool and can use many different back
end data stores, including SQL Server, so they aren't giving up
superior data engine support by using Access as the front end.

I agree completely with your comments here, and would also point out
that it's also Jet itself that is one of the big plusses of Access.
Even when you're using a non-Jet datastore, Jet provides all sorts
of capabilities for interfacing with multiple data formats that
almost all the standalone db engines completely lack (or only
provide through difficult methods).

I have often argued that the "bad reputation" of Access is entirely
due to the "bad reputation" of Jet, which comes about because of
people using Jet as data store when they don't understand WTF they
are doing. I'm making an argument well beyond that -- Jet provides a
near-universal set of tools for data interface with almost anything,
and the ability to work with heterogeneous data sources, whichi s
something that is simply not provided by any other tool I'm aware of
(at least not with such point-and-click ease of use; ADO can access
disparate data sources, but only in code).

This is why I always felt the "ADPs are so much better because they
completely avoid Jet!!!!!" was so misguided. It indicated that the
people who preferred a Jetless connection simply didn't understand
what they were throwing away.
 

Ask a Question

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.

Ask a Question

Top