Planning User Interaction

[eastfield]

I want to put a Access 2000 database together. I want to assume I have all the data in the tables normalised to the 3rd form. I want the end user to be able to extract info in forms,reports formats ect.What other objects coupled with customised objects would I need to consider to make the user extract info easily? I have some experience using v.9.0 Access 2000 but no experience with VBA programming .

Question I will need to consider are the following:

What does a user need to enter?
- How must he enter that info?
- What sort of output does the user needs?
- How do I give him that output?
- What does a user need to do in case of problems?
- How can a user contact me to add information?
- How will I keep the information up-to-date?

I welcome suggestions of possible solutions to these questions.

Thanks all

Eastfield

[vass0922]

- How much database knowledge does the user have?
If they don't know about relations, they'll never be able to pull reports from a normalized database.

What do you mean by customized objects?
Do you mean forms?

Personally I prefer sql server, because you can setup views for users to write reports from, but it really depends on just how big the database will be and of course $$$$.

I'd suggest making up some forms in Access for common data entry stuff, or if you wish you can learn some VB and create a small visual basic application so that the user does not require access installed on the local machine (licensing $$$$$)

Reports are always a problem, how to get the data to the user without bogging down the IT folks with minor tasks such as printing xyz report.

You could make a general startup form in Access that has one button access to normal reports that the user may need. Its very easy to add print report functionality to a button in access.

[Creosote]

Is this homework?

[eastfield]

No this is just me trying to learn about how to get the user to interact with Access. I am currently unemployed and use my time to learn about Access and eventually VB/VBA.

[qball]

eastfield,

sure hope that is true, as I like people to do their own homework, you know like I paid for when I was kid, lol.

Anyway,

why waste time with access, as stated, go to VB and real DB access (SQLServer, ORacle, DB2,...).

Better yet, learn mySQL and PHP, or Python, or Ruby... and learn how to interact through a browser with a backend DB, effectively.

other things.

you can actually set up windows and let users perform (or try) SQL queries on existing data, much like the access GUI works, or in my case, powerbuilder.

it works like this:

Let 'em choose tables. Then columns from tables.
Let 'em choose the conditions, this is a little harder, as stated user may not understand relations.

Then, a couple of things could happen:

Attempt to do what user wants, intelligently. as in if user chooses all tables and columns, with no conditions, you could generate a VERY dangerous query.

SELECT * FROM all tables; say NOT good, though the cartesian products could be somewhat interesting.

You need to only allow user to create acceptable SQL, this is a lot harder.

Lastly,

Quote:

Reports are always a problem, how to get the data to the user without bogging down the IT folks with minor tasks such as printing xyz report.

[edit]
oops..
reports shouldn't be a problem, or accessing data, should not be a problem. as this is fundamental to what a DB does, among other things.

if a user can't access data, what good DB? if DB stores data great, but can't show, virtually useless.

now, if user's demands for data outstrip the DB's ability to perform, then problem NOT reports. it's how you manage the DB, AND users.

example:
end of month, DB swamped with end of month reports! like this never happens!

user wants HUGE result set, like this never happens!

want to allow user to create own reports? could be a good idea, but, not likely....

There are easy ways to MANAGE these above situations. Try to think of some...