I am stumped !

[ron G]

I suspect there is some relationship aspect I am missing. But, it doesn't seem to make much difference what I do, none of the Primary or Foreign Keys will update.

FYI: A Project is a single activity like "remodel kitchen" or "update bathroom" If I can get the keys to work, I want to make the Project table the basis for a POPUP on the Main Layout....

Got any ideas?

Thanks

Ron

HomeBasis.zip

Edited October 8, 2007 by Guest

[Søren Dyhr]

Isn't it because the graph actually should look like this?

--sd

[ron G]

Wow! Looking at your graph screams that it sure makes sense. (It is 2 am so I will try it tomorrow for a real experience)

I thank you very much for your trouble and insight. Can you share with me your reasoning behind the design you depicted?

Thanks again.

Ron

[IdealData]

The IMPROVEMENTS records don't have any values in the "FK" fields - accordingly they cannot display anything from the related tables.

It's not clear how the data was originally created, however I am sending back the file with the following changes:

1. Extra layout I used to determine source of problem.

2. Edited manually the FK_propID entry in record 1 from IMPROVEMENTS and added the ADDRESS field to the PROJECT LAYOUT to confirm the relationship works.

HomeBasis.fp7.zip

[Søren Dyhr]

Can you share with me your reasoning behind the design you depicted?

Well your original graph didn't make much sense to me in the first place it was as if the graph was thrown in arbitrarily, I found Projects a little exaggerated to exactly same rank as vendors and properties in a many2many structure, it was as if projects and improvements were diffferent names for the same.

I then tried to see if some kind of ranking of them made sense, I found it posible that a project consisted of many improvement, but that each improvement were spilt up on different vendors. But to be honest didn't it arrive to me immidiately because I was strugling to make sense of what was provided. I made 3-4 re-sketches and tried thier plausibility against each other before the presented showed up.

As it is, is it very very difficult to guess what people had in mind with their graphing - if sufficient explanation is scarce! Genuine development start elsewhere, with the interview - hardly with what people might guess the relations apparenly seems to be.

--sd

[comment]

Ir really depends on how you define a project. If a project is a group of improvements to any number of properties, then your graph* is correct. But in such case, it would make more sense to base the 'Main' layout on the Projects table. This becomes clear if you rearrange the graph to follow the basic structure logic (see attached).

If a project is limited to a single property, then Søren's graph makes more sense.

---

(*) The one in your file, not the one in your picture

Edited October 8, 2007 by Guest

[ron G]

I have read 5 FM books. I download everything I can get on relations, layouts, value lists etc... and just when I think I finally "get it", FM bites me in the #*@ and shows me I don't.

Your thoughts are appreciated.

Thanks

Ron

Washington, USA ;)

HomeBasis22.zip

[Søren Dyhr]

Before I download your file do I just wan't to make sure you havn't missed these two, in your chase for fm-wisdom?

http://www.digfm.org/ref/FM7_key_concepts.pdf

http://www.filemakermagazine.com/videos/graph-rules-four-rules-to-remember.html

--sd

[Fenton]

Your screenshot is not a Project layout, otherwise its primary key would not have double colons, which means it's a related field. It is an Improvements layout (looking at the actual file).

Your problem is simple. You accidentally linked the pk_ProjectID to the fk_PropID in Improvements. Oops! One of the pitfalls of having similar names.

[ It looks like it should be based on both IDs, so [x] Allow creation creates both, but the correct ones -]

Edited October 11, 2007 by Guest

[Søren Dyhr]

Ah! You're talking about Rons upload - the fast reply syndrome finally getting me as well. Lee have a point here!

--sd