I can also add to this:
Access does not allow for data corruption so easily by a user, such as selecting all but one column, access will still include all fields for sortings, Excel won't. Excel now has a warning dialog box that comes up, but in it's early days, it just sorted regardless. Therefore to say the least, Excel is very clumsy with data management.
Access can store X number of recrods, Excel can only store up to 65536 records on the same sheet without having to use a different set of columns or continue on with other worksheets.
Access has a 2GB RAM usage limitation as opposed to Excel having a 80 MB RAM (160 in XP and 03) usage limitation before it crashes.
Access can query data very easily and not run into issues too easily. In Excel, if using multiple files to compensate for the RAM usage limitation not to mention that calculation also eats away the RAM memory, try using External Link formula. This works fine at first, but when it references at least roughly 13,000 cells externally, Excel crashes.
Access Forms has lots of form events that one can use (though I don't care for how data validation works on bound forms/objects cause it not so user friendly for those that's predominantly mouse users, so I had to build with UNBOUND objects to make the forms more user friendly without sacrificing the strict data validation checks), Excel UserForms has very little Events to work off from.
Access has a fairly good security model, but I'm still not saying it's real good as it still lacks a few things for what I would like to see from a security stand point of view. Excel Security is nearly non-existent. Yeah, it does have security items, but it's not that great as I can demostrate too many issues such as users can still copy hidden cells on a protected worksheet and paste the information onto another worksheet that's not protected. That's just one issue of several.
Okay, so Access has all of these different advantages over Excel, so why then don't more users switch to Access?
Access is not nearly as intuitive as Excel is. This is where most users frenge away from Access.
Okay, so we still have a relatively large number of users that understands that this is going to require some additional learning and accepts that. Now as they get to building their DB program using the wizards and other automation features of Access, they then start to run into different types of issues as they test things out. At this point, frustration starts settling in cause things aren't working as well as one expected. Now, a large amount of the remaining people drops out at this point
Okay, so this means we have to do some Macro/VBA work, which in turn means we should learn how to write in SQL (Using the QBE helps a lot in the aid of this learning process) in addition to learning how to create macros/VBA codes, since that is what some of the RowSources are going to be dependent on within the forms and/or controls. At this point, we are basically down to the technical and programmer type of people to set this up.
After going so much further and learning how to work in the programming environment of Access, this group starts to run into other issues that is not liked. At this point, there's 3 options:
Option A, quit developing in the program and find some other program to do the development in. (Result, developer frustrated and doesn't want to continue)
Option B, continue programming in the program, but don't provide any solution to the issue (Result, developer gives up on trying to find a solution to the issue directly, but rather work around the issue, thus the impacted users gets frustrated)
Option C, continue programming in the program, and do some R&D to find a direct resolution. However, when the solution is found, it may require a lot more development time than what was initially planned for to still keep the requirements of the program, but at the same time, allow the ease of user friendliness (Result, developer may be frustrated and not like the issue at hand, but decides to continue programming including programming a work around into the program that will keep the requirements and allow for user friendliness of the program). Example of this that I had, users that predominantly use the mouse, if validation on a previous control fails before the focus is sent to the command button, the command button never gets triggered. This may be an acceptable behavior MAJORITY of the time, but THERE ARE THOSE FEW TIMES when it's not acceptable. This particular issue took me 2 months to find and create a resolution to this issue.
So by the time that all of these different levels of frustrations and issue went through, all you have left is a small handful of developers that reached the last option choice and went with Option C.
Okay then, how best to use Access and Excel?
Access should be used for all of it's DB means, and maybe even a lot of the analytical stuff via VBA coding.
Excel is good for 2 things
If you need to create a prototype, you can do this very quickly in Excel unlike in Access, it may take a while to do. However, don't spend much time creating this prototype as it's only meant to give a feel for how it would work on a general level basis in Access.
Excel is very easy to create things like charts and other data analytical tools from the data that may be retrieved from Access.
Excel is good for SHORT-TERM solutions while Access is good for LONG-TERM solutions.
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
When the going gets tough, the tough gets going.