Application Selection Report..?

[leamas]

Currently brainstorming ways to make my db work, and hoping anyone with input can help me out.




The end result, in my head, is a simple form that generates a report.

As it stands, my db is only on paper. I have a number of "applications" (much like an iphone i.e. flashlight, redlaser, other utilities) that I would like a user have the ability to select (but not actually operate within the database). These applications will be able to complete certain goals, so if the user knows my applications functions, it will automatically select the "results" and all information regarding those results i.e. safety info (do not look directly into light), but not the info for applications not selected.

Conversly, if the user is not familiar with my apps, I would like them to also be able to select the "goals" or results of the apps, with the same information "pull" as with the other option.

My problem currently is how to link these within a table, or what exactly I should put in each table, or even the number of tables.

I know Access, but I'm definitely no wiz. Please help if you would be so kind!

Thank you,

Alec

[R_Badger]

I would go for an initial idea of three tables:

Tbl_goals

G_ID,Goal

Tbl_App

App_ID, Application

Tbl_App_Goal

AG_ID, G_ID, App_ID

what you are trying to explain is hard I know, concept it always hardest to understand.

But that would enable you to link goals to applications.

From there because you haven't elaborated on the safety info I dont really know what to suggest, i.e will it be like COSHH sheets whete you link to another (supplier produced) document, or will it be within the database. Will you be linking generic sections of safety data, or will you be writing bespoke ones for each?

As I said I know the concept is hardest (and its even harder to explain it to anyone else!)

But good luck anyway I hope this has helped a little

[leamas]

This helps quite a bit, thank you R Badger. I'm a little confused about the ID's though. how do those fit in?

Thank you!

[R_Badger]

take a look at this, link here. Basically you are mad if you design a database that does not conform to a normalzsed principle.

You could, use the text fields as the keys, however they are larger for the database to store (long story short normalization reduces errors, makes your database run faster, and work consistently) and I'm certain nearly anyone will tell you to organise it that way too.

[leamas]

take a look at this, link here. Basically you are mad if you design a database that does not conform to a normalzsed principle.

You could, use the text fields as the keys, however they are larger for the database to store (long story short normalization reduces errors, makes your database run faster, and work consistently) and I'm certain nearly anyone will tell you to organise it that way too.

Thank you!