Dear forum'ers',

I really hope I missed out on something really important.

It's really great what you can do with relationships in fmp7. But...

Is the relationship window really the only way to view existing relationships?

Even though you can do your best to 'organize' that window. It's really not 'lookup' friendly.

You have to search really hard for existing relationships.

Wish somebody would tell me there's also a text version of the relationships.

Something like there used to be in previous versions.

It's really weird there is an edit relationship button but no 'view relationships' button.

Maybe somebody can give me ideas concerning naming the new tables. I really think it's hard to invent new names for new table occurences.

Actually I keep trying to give it a name which will give me an idea of what this table has been created for.

For example:

idcustomer_idcustomer|customers_invoices

This in lack of a clear relationship overview.

Thank you for reading and eventually answering this question.

Edited August 21, 200520 yr by Guest

Hi Michele,

The Relationship Graph is the only was to view/edit relationships in FM7. My trick for helping to organize things is to use the same color for all TOs of the same table. When I name my TOs, I use the actual table name for the primary TO, and append the filter field names (or path) to the names of additional TOs.

Example: suppose I have a Student-Enrollment-Class system, I would name the original TOs "Student", "Enrollment", and "Class", each with a different color. Then suppose I want to add an Enrollment TOs to filter the enrollments for a class by a particular Session, I would link a second TO of Enrollment to Class by ClassID and Session, and name the new TO "Enrollment by Session". This new TO would get the same color as the original Enrollment TO.

Here's a TO naming scheme that I like:

The name for the primary TO for each table is just the table's name. All primary TOs are related to the Main TO (where global containers are stored) using the X relational operator. This is the only exception to the rules. The name for all other TOs is this format:

TO1|field11|field12__to__TO2|field21|field22

TO1 is the TO associated with this table. Fields are added after the TO and separated by |. The double __ are useful if you use underscores in field names like I do.

When TO1 or TO2 is not a primary table, but rather a TO with the format like above, the name is put in {} to deliniate the TO from the fields. Example:

TO3|field31__to__{TO1|field11|field12__to__TO2|field21|field22}|field16

This takes a bit of getting used to, but it's really helpful when dealing with anything that has a list of TOs (e.g. calculations).

Did I explain this clearly?

Hi Sam

Enders seemed clearer

Phil

Definately use colors, I agree that all TOs for a table should be the same color.

The main advantage to my method is that each name describes the relationship in detail, so you don't have to reply on your memory. In simple databases this may not be an issue, but in more complex databases with 50 or more relationships, many of which will have subtle differences, it's a lot easier to find exactly the one you need in calculations, etc.

And the problem with the beginning of the TOs being the same ... you can't tell one TO from other when selecting the TO for the layout when viewing the popup (at least on Windows) because the names are too long to fit in the popup and it won't allow the popup to expand to see the whole TO name. It drives me insane. I'm working at converting my names to LI (for LineItems), IN (for Invoice) etc., so that the descriptive part shows in popups. Starting with the descriptive part puts them out of logical alpha sequence when scrolling to find the correct TO.

For being an Apple product, they have sure dropped the ball on providing user-friendly to us Developers. I adore FileMaker anyway, but geez ...

And yes, I'm talking about solutions with lots of relationships. Started using the colors for now as you suggested. It helps (a little). Thank you.

I'm surprised filemaker didn't think of a 'cleaner' way of looking at the relationships.

Strange Filemaker didn't figure out the database window would look messy and that their would be naming problems.

Wonder if they take a look at other relational databases as MS Access, I'm definitely a Filemaker lover but there are a few things they could have learned from MS Access (and Microsoft could learn from filemaker no doubt about that).

1) Split relationship views

- the database design window only shows the 'main' tables'

- all other relationships are created seperately (though you can't compare the working method of MS Access, we don't have seperate queries).

Maybe filemaker could change it's database window so that it works like layouts.

You can give the layout a name and put the several relationships (f.ex. per table) on the different layouts.

2) Please Filemaker let's get rid of this flat database value lists. You should be ashamed there's no method of hiding the id's in the value lists and yet still be able to use them.

That's really a must in a relational database.

3) It's about time 'events' are part of the database.

But these last points are another topic isn't it.

Hope nobody takes offence at my remarks, just had to let it go.

Thanks again for your replies, happy I'm not the only one struggling. Feel free to add suggestions for the relationships.