Relationship question

jeo

Registered User.
Local time
Today, 06:40
Joined
Dec 26, 2002
Messages
299
OK, I'm trying to set up my tables according to "The_Doc_Man" suggestions.
From what I understood, I really need 3 tables in order to connect 2 tables together.
I guess I'm missing something somewhere...
Attached is a picture of my very first relationship and I know I'm doing something wrong because I'm not able to Enforce RI.
This might be dumb, but until I understand this thoroughly, I don't think I can't precede building the rest of my database.
Thank you.
 

Attachments

Hmm

First off, make sure each of the two tables (not the middle)

Have ID fields, (projectID and ConversionStaffID)

Make these Autonumbers and Primary Keys

Make the middle table have

ProjectID
ConversionStaffID

Make these numbers

then join throught the ID's
 
And... if you are going to set relational integrity, the relations have to be one-to-many (ONE:either "main" table to MANY: the "intersection" table) and RI must be such that you cannot add an intersection record until both main tables are updated with the appropriate individual-element records. No other form of R.I. can apply among this set of three tables if you normalized them correctly. This is, of course, because the relational "arrows" don't point from one "main" table to the other. Only to the table in the middle.
 
It worked this time, but I don't know if this is what I want.
I actually want names displayed, rather than IDs when I go back to the Project table, when you click on the "+". May this won't matter once I build my forms.
Not sure, but you thank you for your reply.
So, The_Doc_Man, is it recomended to use RI or not, your post was a little confusing... :o
 
Last edited:
RI is recommended any time you want to be sure that you cannot add the intersection record BEFORE you add the individual records that are intersecting. Cascade delete would be a good idea. Other options, up to you.
 
Thanks, that makes more sense.
 
In my opinion, RI is NEVER optional. If you have a relationship between two tables, it makes absolutely no sense to trust in the users or programmers to ensure that the foreign keys in one table actually exist in the parent table.
 
In my opinion, RI is NEVER optional.

Pat states it stronger than I would, I'd give it 99%+ as not optional, with just enough fudge factor to allow you to wiggle in that case, always <1% of the time, where RI doesn't work quite right for you because the relationship is kind of complex, or where the relationship is being enforced at another level.
 
OK, here I go again, still struggling with the same relationship.
I got it to work on the RI part, now I want to create a query for my form, where someone will be able to pick (from drop down) a project (by name, not ID) and a person, or people (by name, not by ID) and tie them to that project.
I just can't seem to figure out how to display a ProjectName and a Staff Name from my tblProjectStaff. May be I'm using the wrong table to do this with. May be I need to take my tblProject, my tblStaff, and my tblProjectStaff, and then create a query out of it with names, rather than numbers.
Thanks.
 
Hey Jeo,

You've got both The Doc and Pat Hartman helping you - you're in good hands.

But since you sound like you're still struggling with relationships/IDs in practice, let me tell you you're REAL close.

At the risk of repeating a lesson that's no doubt been illustrated here countless times, here's a walkthrough of dropdowns and how they work well with related ID fields. (Anybody wants to correct me, I say go for it. I can ALWAYS use new tips!)

When you build your form, you'll build it from a query based on the JOIN (aka "intersection) table, i.e. the table that connects the other two tables. As you've found out, it only shows you ID numbers, when you'd like to see colloquial names.

Here's the trick - add dropdown boxes, based on the "main" tables. When you use the dropdown wizard (it's right there on your toolbox), the wizard will walk you through step-by-step.

First, choose "I want the combo box to look up the values in a table or query." After you press NEXT, you'll get a list of Tables and Queries in your database - choose one of your "main" tables. (Actually, it'd probably be better to build a query and base it off of that, but for the purposes of this walkthrough, who cares?)

Now, from this table, make sure you grab the ID field (your Primary Key) AND the descriptive name field. When you press next, you will get a screen that lets you adjust the width of your columns. Chances are, the "Hide key column (recommended)" box will be checked. What this is doing is hiding your Primary Key. If you uncheck this box, you'll see your PK reappear...you can do the same thing this Hide box is doing just by dragging the column width like you would in a Table or in an Excel spreadsheet.

For now, because we want to see all the steps, uncheck the Hide Key Box, then drag the column width of the ID ket to nothing, then click next. The next screen will ask you if you want to store a value in a field...HERE'S where the ID relationships really shine! Choose your ID field, press next.

Now the wizard asks if you want the value for later use, or if you want it stored in a field. Choose "Store that value in this field:" and on the list to the right, choose the ID field that's ALREADY on your form (remember, this is the Foreign Key from the JOIN/"intersection" table). Finally, choose a name for the label, and you're good to go.

(If you left Hide Key Column checked, then Access usually just ask you to name the label and go on your way.)

After all that, here comes the payoff - go to normal view, and you'll see your dropdown with the colloquial names. Whenever you use the dropdown to choose a name, the ID field on your form will change. As you create new records, you use this dropdown to find the colloquial name (remember, this is based on a "main" table, with only one entry for each colloquial name, having a unique ID number) and the ID field on your form will populate with the appropriate ID number (remember, this is baed on your JOIN/"intersection" table, which will have many repeating ID numbers over time, but will always look back to the "main" table for the description/colloquial name).

If you go back to design view and make the ID field on your form invisible (set "Visible" to NO in the properties window), then your users will never be the wiser.

This kind of stuff is sometimes hard to put into words - I say plug away at it for a little while, and then come back and tell us how it worked out for you. Good luck!
 
Well done, monkeytunes.

Jeo, monkeytunes is quite right, and in fact he left you a few nuggets hidden in the body of his message besides the explicit instructions he gave you about the drop-down lists made through the wizard.

I say plug away at it for a little while, and then come back and tell us how it worked out for you

This is absolutely what most of us do when faced with something new. We just sort of give it a try, see what didnt' work, and try to understand what we actually did. If we see that we did something close to what we wanted, we just adjust our try and repeat until we get it right. The truth is that Access is so good as a Rapid Application Development (RAD) environment that it allows you to be sloppy about planning your test runs. And if you aren't under the gun for a huge, looming deadline that will affect your career for the foreseeable future, you might have time enough to play with it until you get it like you want it. Heck, I've been in the business for 25+ years and I still have to toy with my code to get it absolutely like it should be. I'm surely not perfect. Don't expect yourself to be perfect, either.

Stated another way, if "experience" means learning from your mistakes, then I'm a highly experienced guy 'cause of the huge number of mistakes I've made. So be of good cheer as you get elbows-deep into this problem.

Oh, by the way, here's another nugget. Monkeytunes told you to use the dropdown-control wizard. The first few times, this is exactly what you should do. BUT... then take a look at what the wizard did for you. The day will come when you want it to do something just slightly different. And you will tweak what the wizard build, and viola', it will be right. The second hidden lesson is therefore to use the wizards as a starting point. Anything they build for you is something you don't have to build for yourself. If you have to come back later and just tweak it, you've still saved gobs of time. What a wizard builds is definitely NOT sacred. In fact, it is OFTEN inefficient and rather mundane. But it still takes less time to customize a form/report/query if you let the wizard build you a good, basic starting point.
 

Users who are viewing this thread

Back
Top Bottom