Oh what a tangled web we weave.. (PIC)

[BruceJ]

Wow... I'm about 70% through this solution for Texaco, an automotive POS solution and this thing is really looking busy.

It's not a converted solution, it's built from the concept up on FM7 with every new trick and gizmo I could find to optimize it.

This solution replaces one built in FM6 that had many files and even more realtionships.

This one just looks so ******* confusing becuase it's all crammed into one place.

I need a monitor the size of my wall to see all this stuff.

And - this is with as many advantages I could gain through all the new power of FM7.

[Charles Delfs]

A few things I found were to reduce the tables down to one line, esp. fo rthe ones that only have one tie (eg Phone#peopleGroups)

Also you can break them down into managable screens and even ad graphical seperators with really wide 'do nuthin' tables

It also looks like a lot of yout TO's are not placed close to the TO that they are connected to, so you have more crossed lines then ness (eg: Address#Store).

Although I don't know your solution, I have a hunch your TO's can be simplified, it looks like you have multiple tables (not TO's) for things like addresses and phone #'s, if so regardless of the address owner ( customer, store supplier) they can all be stored in the same table, same as phone #'s etc.

Charles

[BruceJ]

You're right Charles, I can see lots of places to clean up. I had been trying to keep the TO of the table types close to one another instead of the actual relationships near one another... I think I like your idea better with less corssed lines. I have a hard time selecting the realtionship for editing/viewing when they are all so close together.

The use if separate tables for phone numbers, addresses, ect is because one entity (peopleGroup) can have multiple addresses and phone numbers, some cross between groups, same with the PeopleNames, Stores, Venders, etc.

I think I'll definetely spit it into manageable screens as you sugested as well.

I wish we could add a "Comment" to realtionships. If I go get hit by a bus, some of these things will drive someone else crazy trying to fugure out what I did.

[bruceR]

You can navigate to a relationship definition with cursor keys and open it with the pencil tool or command-O.

[Oldsneekers]

Innocent bystander question: As I read the above, I wondered what is a "TO" and how do you make multiple screens for the relationships. I personally miss the simplicity of the relationship make process in FM5. I am converting to 7 as well and the relationship process is not as intuitive now as it was in 7. Thanks. Greg W.

PS while your at it. I don't get this "table" thing. It is described as a collection records. a file, a relationship??. How is it different than a rela and portal or related records?

[BruceJ]

A "TO" is a table occurance, AKA Relationship.

A "Table" is refering to what we used to refer to as a File.

[cellmaker]

Maybe in future versions we'll get some fun extensions to the chart such as the ability to group sets of related TOs (and collapse them to a grouping icon) and/or a full 3D view so that we can set up our chart in three dimensions (I'm sure this is *just* around the corner, hehe).

I heartily agree it would be a good thing to be able to comment out relationships.

[Tripod]

It all reminds me of 4D. I never used that much, but it had a ER diagram that the new relationship diagram in FM7 reminds me of.

About the documentation, for the relationships graph, that would be nice, but I suppose for now the thing to do would be to maintain a separate document or FM file with rationale for each table, description of the project, etc... On a good note, I love the options/comments toggle for each field displayed in the new define database/tables/relationships dialog. That is very handy.

[smorr]

The other thing I would love is the ability to give constants in the relational dialog -- this way I don't have to make a calculated field just to have a constant for a relationship.

IE it would be nice to say a relationship where:

Status = "Open"

rather than: Status = k_OPEN where k_OPEN is a calculation = "OPEN"

Maybe next version --- (the same version where they allow us to specify a field & repetition numjer to set (in set field script step) by calculation.

(please oh please oh please)

[CobaltSky]

Hello smorr,

The feature you are wishing for (if I understand you correctly) is already available on FileMaker 7.0. It is called a 'Cartesian Product' relationship and is represented by the 'X' symbol in the drop-down menu of relationship operators in the relationship definition dialog.

The Caretsian Product operator essentially relates all records in one table to all records in another (and vice versa) regardless of the values (or lack of values) in the field/s chosen as the keys for the join. So there should be no need for calculated constant fields such as your k_OPEN = "OPEN" in any FMP7 database - at least not for the purpose of setting up relationships which match to all records in a table.

Also worth noting is that one of the common reasons for 'open' relationships in earlier versions of FileMaker was so that global values could be passed freely between files (tables). In FileMaker 7, however, global fields can be read and written to from any table (TO) on the graph without requiring any relationship at all. So the need for such relationships is also less than it was previously.