My wants and wishes

[kiwiora]

I don't ask for much.. just some really simple things

Relationship Diagram:

Ability to view as a list rather than graphical interface

When in graphic interface and click on a TO, the relationship lines for that TO appear in a colour (e.g Red)

Specify Button:

When specifying a button to be "perform script" there is a wasted extra step of then having to click on "specify"

Importing/Scripts:

The ability to better organise than the drag. e.g when organising importing of fields and you have to drag one field up, it can get out of control stopping it from scrolling the window too fast.

Tables

The ability to duplicate a table. Or at the very least copy fieldnames from one table to another.

[jasonwood]

How could the relationship graph possibly be displayed as a list?

I agree with your other points but I believe once you solidly understand the concepts behind the relationship graph you would have it no other way.

[kiwiora]

excuuuuuuuuuuuuuuuuuuuuuuseeeeee moi? So because I don't like the way it's setout you automatically assume I don't understand the concept?

It's not the concept I take issue with, it's the way in which it'd laid out. I have no solution to this problem, I just don't like it. I have created a masterpiece of a database and the layout is soo messy it's not funny. I have 36 TO's and I'm not even finished yet. I've used colour to differentiate, but tracing all the tables/relationships is a joke.

If you turn the tables in the way in which you commented to me, I could suggest that you haven't understood the abilities of FM7 and perhaps have not created a large database design yet. But of course I don't know your abilities and would not be so rude as to suggest such a thing.

[Fenton]

I'm afraid you're both right. It cannot really be shown accurately as text, for one thing because, at best, it could only show the relationship from one TO to the next, and many of the more useful connections are through a central TO to the next. I don't think that a text list, showing just one TO connected to the next TO is really going to all that helpful. Also, any compound relationship connections would be difficult to display, unless they were shown as multiple lines.

It seems like it could be shown in a limited way as text. I think FileMaker made the decision that the text view was just not good, accurate or useful enough. I think they're right, though I hate in some ways to admit it.

The graphical view is accurate. You need to see the lines. As you say though, sometimes you can see the lines, but there are so many it's difficult to trace. The only real help I can see is to get a bigger monitor. My 17" screen is just not going to cut it for complex graphs. So I'm saving my pennies.

I wonder if it would be possible, in the distant future, to have an "Trace" tool, similar to Excel's "Analyze." It would be cool to click on a key field in one TO, then click a Trace icon, then click on another key field in another TO, several away but on the same path, and have the entire path highlight between the two. Or not highlight, which would be good to know also.

It is a consideration when you are deciding whether to put everything into one huge file, instead of breaking it up a bit. One has to think about what that graph is going to look like, when it has every relationship for the entire solution in one window (not to mention every script in its Scriptmaker list). Consolidated is one way to think of it. Spagetti and meat balls is another. I imagine we'll get used to it.

[Matthew F]

Why not list the relationships like the Finder (or Windows Explorer) displays nested directories, i.e. in columns, or in a nested list with little rotating triangles? For one thing this would allow you to sort them in a predictable way. The appearance would vary somewhat depending on which Tables the user chose to place at the root level, but I don't think it would preclude the creation of complex relationships.

[Fenton]

I just don't think there is any definite way to show the Relationship Graph as anything other than objects and lines. Yes, you could get some kind of list, but it would not be really accurate.

"Nested" implies a hierarchy. FileA is inside FolderA, which is inside FolderB, on up to the root. Say there is a FolderZ, also at the root, and it has FolderY inside it. What if FileA was also inside FolderY? Impossible. But with a Table Occurrence it certainly is.

One big difference with 7 is that you name the Table Occurrence, not the relationship. You may be reaching through several other TOs to get to the one you want. It would be possible to name every TO on the way, but pretty ugly. And it doesn't solve the problem that the same TO could be reached by several other relationship paths, from near and far (beginning to sound like a fairy tale :-)

What could be done however would be something like a Find tool in the Relationship Graph. Most higher end vector graphics applications have this. I'm not sure what use it be however, to select all the TOs that contained a word. Not much, since many of them would just be "tail ends," going nowhere useful. Probably a "Find one," then Find Next would be more useful.

Basically you look for the TO in the location where it would be connected to another TO, or in a particular Table Occurrence Group (TOG), that would provide the functionality you're wanting. So you know more or less where it would be found; or, if not, you can tell (guess) by looking at the surrounding TOs and the links between them.

I've seen people create "dummy" TOs, as labels for a TOG. Not a bad idea (if you can actually come up with a conceptual name that identifies the group).

So it's more of a graphical search, like looking for something on a map,* than it is a text search, looking for something in a list. Still, it would be nice to have a Find, and to have a drop-down list of existing TOs (which we can see practically everywhere else except on the Relationship Graph), in case you know the name, but forgot where you put the darn thing.

What's really needed is a bigger monitor. Donations accepted :-)

*With the difference that things on a map tend to stay in the same place, within a reasonable time span.

[Matthew F]

What if FileA was also inside FolderY? Impossible...

I do that in the Finder with a folder alias (short cut). Something similar should work here. What someone places at the "root level" would be arbitrary, I agree. Even with the operating system the heirarchy of folders simply defines connectedness, not a physical relationship of one item physically "containing" another. Circular definitions aren't allowed in Filemaker so I don't think this an impossiblity.

One big difference with 7 is that you name the Table Occurrence, not the relationship...

In the finder I name the equivalent of a Table Occurance (folders and folder aliases).

I've seen people create "dummy" TOs, as labels for a TOG. Not a bad idea (if you can actually come up with a conceptual name that identifies the group)...

I agree a method of labeling graphs would be a nice feature and a lot more realistic than adding a second method of creating relationships.

[smorr]

In relationships, Here is what I want:

Be able to Group relationships structures and perhaps name them

(rather than making a dummy TO with the name (which will appear in any relationship menu) and even (gasp) collapse them by name.

Have the relationship structures in a list with the option to show one at a time.

Change the ways colors work in the diagram -- you can choose dark red and it displays as pink. You can choose light red and it displays as light pink. Choose purple and it displays a purply pink... choose orange... and well you have the idea. its not that I have anything against pink... its just I like to use colors that will are clearly distinctive. (My vote is to get rid of the faux windows XP tables occurances and get something that will display more clearly.)

Add The ability to specify constants in the relationships without creating a calculation for the so purpose of the relationship

Add notation to the ends of the relationship. If a record can be created in a TO via a relationship put a little * or C or whatever on the appropriate side of the relationship indicator.

Same with Sorts and Same with Cascaded deletes.

In datastructures: Extended Tables

I would give my left arm for a "extended table" based on another table. I don't know if I am communicating my idea correctly but I would love to say that TableB is a extension of TableA. With would be based on a primary ID and B would "inherit" all fields from A. but allow for Table B to add to or even override fields in table A -- When a Record is added to Table A, it is available to Table B. When a Record is deleted from A, it is deleted from B

Eg.

Table A:

UserID

LoginName

FirstName

LastName

LastFirstName = LastName &", "& FirstName

Table B: extends Table A

// accessing table B will allow UserID, LoginName, etc etc but also the following

UserNotified

fieldsSpecificToSolution

LastFirstName = TextStyleAdd(Lastname,bold) &", " & FirstName

This would allow a basic structure that can be unsullided by various needs or uses and then this structure can be extended in multiple ways.

[transpower]

kiwiora:

You may want to upgrade to Developer--this has a Database Design Report.

[kiwiora]

Transpower - I have Developer. The database design report is UGLY

[Oldfogey]

I'm with kiwiora (even if he does come from Brisbane). I do not care much about ugly (glass houses and all that) but I suspect it will become user-agressive with a significant number of relationships. So far I've only played with fairly simple DBs but I'm dreading converting one DB which has a spaghetti-like relationship structure involving zillions of relationships. Some kind of grouping mechanism would be really nice!

[GerryGerry]

Hi,

How about a "3-D Relationship Graph"?

Similar to The Visual Thesaurus (with DisplayOption=3D of course).

Just an idea.

-GerryGerry