- Local time
- Today, 16:24
- Joined
- Feb 28, 2001
- Messages
- 30,622
I'll toss in my two cents' worth on this one.
I have used Access many times for many things and have absolutely no problem with it. The problem comes most often for people who THINK they are database designers because they got Access to work for something. They THINK they are programmers because they got some trivial piece of code to work. They think Access must be easy because it is part of Office and everyone knows how easy Office can be.
This is not intended to be an elitest remark, but it should be treated as at least a cautionary one: Access goes a LOT deeper than what people see. For that matter, so do Word, Excel, and PowerPoint. The ones who have scratched the surface and stopped there are content; they will continue to be happy. But for some, they cannot leave "well enough" alone. The real problem is simple: The more ambitious you get, the farther Access can take you until a programming version of the "Peter Principle" traps you. I.e., you can delve to the level of your own incompetence.
If you look at what Access allows you to do, you realize that to use it wisely you must be a graphic designer. You must understand asynchronous (and synchronous) interrupts (in the form of events). You must understand SQL. You must understand set theory the first time you have any kind of complex JOIN query or junction table. You must understand security issues the first time you deal with a multi-user DB. You must understand object-oriented concepts whenever you have to use VBA to control object attributes. You must understand relational database theory.
Oh, by the way - you ALSO need to know everything about the problem you are trying to solve. In other words, an expert in TWO fields.
Wait, you say, isn't that true of every shop? No. Companies that have a separate IT or DP shop get in-house consultants to handle the messy details for the products they prefer - like SQL Server, ORACLE, FOCUS, etc. But the odds are that those consultants are immersed in the big products so sneer at the little products.
Unfortunately for them, the power of Access that makes it so popular is two-fold. (1) Rapid Application Development. (2) Hidden power to take you a long way towards your final goal - maybe ALL the way for something that doesn't exceed size requirements for an .MDB file. These days, the gigaherz boxes with 10,000 rpm, 100+ gigabyte disks can handle a very huge stand-alone DB so quickly that you almost wonder how they could work so well.
As many others have mentioned, Access is a cheap way to start your project. It is a great springboard to the final implementation when you were just using Access for prototyping.
Our shop uses ORACLE as its final solution, but many times we have used Access constructively to get from point A to point B with very few stops along the way. In case you were wondering, we use ORACLE because our DB way exceeds the Access size and concurrent user limitations.
I have used Access many times for many things and have absolutely no problem with it. The problem comes most often for people who THINK they are database designers because they got Access to work for something. They THINK they are programmers because they got some trivial piece of code to work. They think Access must be easy because it is part of Office and everyone knows how easy Office can be.
This is not intended to be an elitest remark, but it should be treated as at least a cautionary one: Access goes a LOT deeper than what people see. For that matter, so do Word, Excel, and PowerPoint. The ones who have scratched the surface and stopped there are content; they will continue to be happy. But for some, they cannot leave "well enough" alone. The real problem is simple: The more ambitious you get, the farther Access can take you until a programming version of the "Peter Principle" traps you. I.e., you can delve to the level of your own incompetence.
If you look at what Access allows you to do, you realize that to use it wisely you must be a graphic designer. You must understand asynchronous (and synchronous) interrupts (in the form of events). You must understand SQL. You must understand set theory the first time you have any kind of complex JOIN query or junction table. You must understand security issues the first time you deal with a multi-user DB. You must understand object-oriented concepts whenever you have to use VBA to control object attributes. You must understand relational database theory.
Oh, by the way - you ALSO need to know everything about the problem you are trying to solve. In other words, an expert in TWO fields.
Wait, you say, isn't that true of every shop? No. Companies that have a separate IT or DP shop get in-house consultants to handle the messy details for the products they prefer - like SQL Server, ORACLE, FOCUS, etc. But the odds are that those consultants are immersed in the big products so sneer at the little products.
Unfortunately for them, the power of Access that makes it so popular is two-fold. (1) Rapid Application Development. (2) Hidden power to take you a long way towards your final goal - maybe ALL the way for something that doesn't exceed size requirements for an .MDB file. These days, the gigaherz boxes with 10,000 rpm, 100+ gigabyte disks can handle a very huge stand-alone DB so quickly that you almost wonder how they could work so well.
As many others have mentioned, Access is a cheap way to start your project. It is a great springboard to the final implementation when you were just using Access for prototyping.
Our shop uses ORACLE as its final solution, but many times we have used Access constructively to get from point A to point B with very few stops along the way. In case you were wondering, we use ORACLE because our DB way exceeds the Access size and concurrent user limitations.
