Pro's and Con's to using One Form

[asherid]

I wanted to get a good idea from some of the experts out there on the pro's and con's of using one form for most (or at least your main) data entry. Let me explain my scenario.

I want to make things as simple as possible for the end user in order to avoid confusion and in turn increase the usage of the database. In this database we are keeping track of Supporters (i.e. people, companies, etc.), Campaigns (i.e. Golf Tournament, Special Fundraiser Projects, etc.), and their Registrations, meaning each supporters' individual registrations for each campaign.

I have three main tables, tblRegistration, tblSupporter, tblCampaign.

What would be the implications if I created a query that queries all fields in all three tables and then based my one main form on this query?

Would this limit my ability to perform future tasks not yet forseen (scalability)?

How would it effect importing and exporting of data with other programs?

How would it effect things like generating reports or setting up mail merges with MS Word?

What about form layout. Would this be considered bad practice or is this a format that would be preferred by extremely novice users that are performing data entry only?

Any and all feedback, tips, and/or advice will be greatly appreciated.

Thanks to all in advance.

Aidan

 

[Steve101]

Aidan,

(a) Before you do any application development, you need to understand a little more about good database design principles - I guess that's the reason that you placed this post in tek-tips, so thats a good start.

(b) Get yourself a good Microsoft Access Introductory book, and read up on good design principles (lots of books in good bookshops). In particular find out a little about Data Normalisation. This tells you how to design and relate tables properly.

(c) Now to answer your question relating to how many forms you should have:

Again, generally speaking, each table should have its own data entry form, thus in your example, you would have a data entry form for Supporters, another for FundRaisers, another for Registrations (which I assume is Supporters registering to attend FundRaisers).

(d) The above approach would allow you to enter information relating to Supporters and Fundraisers only ONCE, then draw on this as required (eg. via selecttion of pulldown list's) when adding Registration information on your Registration form.

(e) There are many ways in which you can design and implement a User Interface; your users' "window" into the underlying data, and this is where you can make it easy or hard for your users.

(f) For starters, learn about forms and subforms, and how to link them. This will allow you to "syncronise" and view related data (eg. Supporters of a selected campaign), whilst maintaining "data separation" with respect to the data underlying the different (but linked) forms.

(g) Also find out about the "Tab Control". This provides a good capability for organising different categories of data on a single form.

(h) I frequently employ different subforms on a single master form, but on different pages of a tab control. This provides a clean but powerful user interface.

(i) Be aware also of the different way in which data can be displayed on a form; In Access, you have Single Form, Continuous Form and Datasheet display options. These all have different benefits when designing an interface.

(j) Finally, your question relating to having a single form based on a single query. Well hopefully I've convinced you that its not a good idea, with the points made above. Having said all of that, it is technically possible to set up such a "joint" query, and then to source it to an all encompassing single form, but it would make for a very confusing user experience, would end up showing a lot of confusing duplicate data (eg. if one supporter was registered to multiple campaigns), the person details would be repeated alongside each campaign; not a good way to maintain person data, and would be constrained in your ability to add certain types of data - wont go into the details here, but the bottom lines is that it would not be a good idea at all.

Hope some of these pointers help,

Good luck,
Steve Lewy
Solutions Developer
steve@lewycomputing.com.au
(dont cut corners or you'll go round in circles)

 

[asherid]

Yes, Steve these points really do help! Thank you. I would still like to hear if anyone else has some other points to make for or against the idea in my previous post.

Here's another question for everyone that is more in response to Steve's post:

I have heard of people always having their forms run off of a query instead of running it off of the raw table. What are the advantages to this?

In this scenario I would make a query for each of my three tables I assume. Is the query wizard sufficient for creating a basic query to use in this scheme or is a more robust query better suited?

Thanks in advance... again.

Aidan