Main Area and Open Discussion > General Software Discussion

Getting started with Access?

<< < (3/3)

CWuestefeld:
For applications of, say, 1-5 users, Access is a great DB platform. As a RAD platform, if you can do the job within its confines, without writing code, it's great. But if you do need to write code, the restrictions of Access's forms model become frustrating very quickly.

If you expect the amount of custom coding that will need to be written is non-trivial, and if you have any programming experience, I would consider a different route. Continue to use Access as the database engine, but forget about its RAD development capabilities. Instead, download one of the free Express editions of Microsoft's Visual Studio, and you'll have a free development environment for VB.Net or C#. They can interact with an Access database just as well as code you write in Access.

These are much more sophisticated (which is the flip side of more complicated :() but in my opinion they offer a much more coherent experience -- things will make more sense, as opposed to Access's platform, which has evolved into a Frankenstein monster without any real unifying philosophy (making it impossible for me, at least, to intuit how any operation ought to be accomplished).

I have the book that Perry suggested above, and I thought that it's pretty good, at least using it to quickly look up how to do a particular operation.

Perry Mowbray:
For applications of, say, 1-5 users, Access is a great DB platform. As a RAD platform, if you can do the job within its confines, without writing code, it's great. But if you do need to write code, the restrictions of Access's forms model become frustrating very quickly.-CWuestefeld (December 31, 2007, 04:06 PM)
--- End quote ---

I both agree and disagree here: I think the trick is not to fight Access, but to think in the "Access way". It's a toss up between flexible and frustrating... but I'd go with flexible. My most adventurous Access development was a local DB that integrated with a web enabled DB off-site via Web Services (sounds odd I know, but at the time there was not the budget to get the developers to implement everything in the web site so I did some bits locally in Access)... but it worked a treat! That's flexible!!  :Thmbsup:

If you expect the amount of custom coding that will need to be written is non-trivial, and if you have any programming experience, I would consider a different route. Continue to use Access as the database engine, but forget about its RAD development capabilities. Instead, download one of the free Express editions of Microsoft's Visual Studio, and you'll have a free development environment for VB.Net or C#. They can interact with an Access database just as well as code you write in Access.
-CWuestefeld (December 31, 2007, 04:06 PM)
--- End quote ---

This is another good suggestion if it fits your restrictions.

PPLandry:
One big advantage of using the Access UI is that it gives the car keys to users. They are free to create queries, new/modify forms, create reports. But always, always use 2 databases, one uniquely for data and one for UI (and temporary data)

CWuestefeld:
One big advantage of using the Access UI is that it gives the car keys to users. They are free to create queries, new/modify forms, create reports. -PPLandry (January 01, 2008, 09:32 AM)
--- End quote ---
That may also be an important disadvantage. If I had a dollar for every time I had to unravel the bad data resulting from someone who didn't have the knowledge to properly model the data relationships then, well, I'd have a lot of dollars.

But always, always use 2 databases, one uniquely for data and one for UI (and temporary data)
-PPLandry (January 01, 2008, 09:32 AM)
--- End quote ---
Yes! :Thmbsup:

Next to proper E-R modeling, this may be the most important of all Best Practices for Access development; I can't believe that books (not to mention Access itself) don't make more of a big deal of it.

Doing this is absolutely essential to ongoing maintenance of your application. It allows you to let your users keep on using while you work on bug fixes and enhancements; when you've got your code layer complete you can simply swap it in. If you've got one monolithic .MDB, you have to dance around people using it; they've got to be locked out while you work on it.

If you're going to have multiple users, consider using replication rather than giving all access to a single physical file. Access's replication features are really remarkable, in some ways even more advanced than SQL Server.

PPLandry:
One big advantage of using the Access UI is that it gives the car keys to users. They are free to create queries, new/modify forms, create reports. -PPLandry (January 01, 2008, 09:32 AM)
--- End quote ---
That may also be an important disadvantage. If I had a dollar for every time I had to unravel the bad data resulting from someone who didn't have the knowledge to properly model the data relationships then, well, I'd have a lot of dollars.
-CWuestefeld (January 01, 2008, 11:12 AM)
--- End quote ---

True but if you split the DB into 2, and lockup the data-database, then if users mess-up the UI database, it can easily be restored. I never let user modify the data-database

Navigation

[0] Message Index

[*] Previous page