* Newbie problem - relations and lists

[Ken M]

I'm having a look at FMP8 trial to see if it will d what I need and am testing it's relational capabilities on a fairly simple contact management system.

There are 4 tables with relationships between each:

* Organisation (org)

* Office (org, office)

* Person (org, office, name)

* Contact (org, office, name, date)

On the 'person' layout I want a list box to select their organisation and another for their office so I've defined a list based on Organisation and that works fine.

I then defined another list based on Office but cannot get that to work properly...

If the list is unconstrained then I get ALL the offices in the database, not just for the specified organisation.

If I say include only related values starting from Organisation (and I've tried all sorts of other ways), I get nothing.

Am I doing something wrong or have I simply reached the limits of FMP?

I must say I've not found the help, dopcumentation or tutorials to be a lot of help for anything much more than the basics.

[mz123]

Hey there - i hope the attached file helps!

The relationship for the Office and Person table should be by Organization.

Martha

Test.fp7.zip

[Ken M]

Many thanks for your input and I see that this works OK, although it's not quite what I was after since I was trying to have a relationship of person - office but maybe FMP is just not sophisticated enough for that?

Also, the next relationship would doubtless have a similar problem as I try to develop the contact layout with the person appearing in a drop down list box.

I guess I could have all tables relating to Org, which would probably be OK for this simple app but may be a problem for the 'proper' app that I'm hoping to use this product for.

[PeterHW]

Hi, first you said :

...have I simply reached the limits of FMP?

and then you went and said :

although it's not quite what I was after since I was trying to have a relationship of person - office but [color:red]maybe FMP is just not sophisticated enough for that?

Apart from the fact that the relationship in the database is from person<=>office, these comments are not really helpful if you are trying to get assistance from a community that takes Filemaker very serious and uses it as a versatile tool that is quite adequate to provide solutions for very complex database requirements.

If you continue using Filemaker past the initial few days and make some serious effort, you will find it will do everything you need, and more. Sure there are limitations, but to assume that you are already running into them with such a basic design is not only unlikely, but even condescending.

I hope you will interpret my post as constructive, I have no intention of burning you. But I do recommend that you study the documentation, help file, online resources and especially some of the sample files that you will find around here, they are really way beyond 'the basics'.

Regards,

Peter

[Ken M]

Well, I don't know what I said to deserve such a tirade from you!

I am an experienced database developer who is looking to see if FM will do what I need and I've hit a problem so asked for help. Surely that's what these forums are for, not to belittle my serious attempts to find out about this product.

You are right to say that Martha's test database does relate people to office but it has lost the relationship between organisation and office!

In order to get these relationships to work for me I need to be able to show offices in an organisation, people in the offices and contacts for those people.

Also, when adding a new person I need to be able to select an organisation and an office in that organisation from drop down list boxes (hence my original question).

Now with a time limited trial such as is available, I need to discover how to do things (or find out if they can be done) very quickly and I'm quite prepared to believe that some of the online resources and sample files may provide the help I need (although from what I've seen, I'm less sure about the documentation and help files) however, unless you are prepared to point me at particular solutions, I'm not going to have the time to search through everything. That's why I asked the question here.

Perhaps you have a solution to the question I asked rather than to glibly suggest, "of course FM can do it"?

[Søren Dyhr]

My guess is that you make the mistake that the relations graph isn't an ER, because it has to deal with both querrys as well as data structure. The key to the problem i guess you have is to insert extra TO's to you graph in order to make this distinguisement in behaviours.

I'm actually with PeterHW on this, the real problem is the time constraints you're on ...it sounds like you're exposed to filemaker against you will, and not really are ready to learn the ropes of this particular tool.

The question is, if you still would have the same problems after reading the whitepapers say:

http://www.filemaker.com/downloads/pdf/techbrief_fm8_migrtn_found.pdf

...where it's kind of waste to study the migration part of it, while the study of the "Methodology" part of it makes more sense. But there exists a shortcut that deals with exactly this distinction between datastructure-/querry-'ing you seemingly can't get ontop of:

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=541

Enjoy

--sd

[PeterHW]

Well, I don't know what I said to deserve such a tirade from you!

And that while I took such care to exactly quote the comments in question : . Ah well, maybe I was a little touchy, but the way I read your post it was indeed from an experienced database developer who decided to take Filemaker for a spin without the willingness to take it all too serious (this is an attitude often seen with "serious" database developers), but instead waiting for the first case that would prove he was right all along and FM just wasn't cut out for "serious" development. Maybe I jumped to conclusions, but your comments did point in that direction.

But to answer your original question :

Am I doing something wrong or have I simply reached the limits of FMP?

You are doing something wrong. You indicate that you try to populate a value list in Persons with related values from the table Offices, which should start with Organizations. But I assume you have a relationship graph which looks like

Organizations<=>Offices<=>Persons

So although with this setup there is a direct path between Persons and Organizations, there is no way to populate a value list in Persons the way you would like, since this would require a Persons<=>Organizations<=>Offices path.

Starting in Persons, how could there be related records from Offices, based on OrganizationID, if there is no relationship from Persons to Offices based on OrganizationID to begin with ?

A very important concept in Filemaker, at least with the introduction of version 7, is Table Occurrence (TO). This differs from the concept "table", insofar that one table can have many TO's on the relationship graph. That also means that the context in which a TO is referenced becomes very important.

Take a look at the attached file for a simple implementation of what you want to do. Let us know if you run into any more trouble.

Regards,

Peter

Test2.zip

[Ken M]

the real problem is the time constraints you're on ...it sounds like you're exposed to filemaker against you will, and not really are ready to learn the ropes of this particular tool.

It's true that I have severe time constraints on this but not at all true that I'm not tackling this whole heartedly. It was my decision to investigate FM in the first place, as a potential solution for one of my clients.

I've not read the white paper yet but the movie you pointed me at was extremely useful.

A very important concept in Filemaker, at least with the introduction of version 7, is Table Occurrence (TO). This differs from the concept "table", insofar that one table can have many TO's on the relationship graph. That also means that the context in which a TO is referenced becomes very important.

It does seem that I was missing a basic understanding by assuming a more traditional view of relationships. Your example was very helpful and I think I'm now beginning to get to grips with this whole aspect. It seems that the relationship graph is all important, not just in describing the actual data connections but also in defining data access by the use of TOs.