A Sanity Check, Please.

[javabandit]

Hi All,

I've just created what I believe is my cleanest-to-use filemaker database. I used some techniques that I've found in this forum to use tabs for navigation, and to use portals for selecting and highlighting records.

I'm not having any trouble with the database. It's working nicely (I think!). I have only two tables, but I ended up needing a lot of table occurrences to get where I am.

In the interest of learning, I would greatly appreciate it if someone would take a look at the structure of these two tables and give me a "sanity check". Do I have too many table occurrences? And, if not, how does one annotate them to indicate to future editors of this database the function of each occurrence?

The database is here:

http://madisonnet.googlepages.com/finish_chart.zip

Thanks in advance for your constructive criticism.

[javabandit]

I discovered a problem in the uploaded file. It has been corrected, and re-uploaded.

[Fitch]

Looks OK. First of all, that's a relatively small number of TOs compared to many systems I've worked on. Nothing to worry about there.

It would help if you used better naming conventions. E.g. rather than simply "categories" you could call it "Finish_chart_categories_ALL" and "categories 2" might be "Finish_chart_categories."

This helps a lot when you're in a dialog and trying to select the right layout from a popup list.

In addition you can document the graph using the text tool. Some people also use color in the graph to indicate functionality and/or base tables etc.

[Fenton]

Yes, unless you name your table occurrences (TOs) carefully, and according to a fairly consistent naming convention, you will have a hard time moving beyond the basics. There are basically 2 naming conventions, with some overlap. One is "functional" naming, and the other is "structural" naming. The functional method names things according to what they do, the structural method is the chain of relationships leading up to the TO, optionally including the field names (usually only at the end).

While I can see some virtues of the functional naming, in solutions where it makes sense, I use structural naming. There are many reasons, but the main one is that any given TO may serve multiple purposes. Since you name the TO, not the "relationship" (the little white box, which, sadly, does not even have a place for a comment within it), functional names soon become impossible.

As I said, there is some overlap between the methods, because each will often include the names of the tables themselves, as well as sometimes a field or fields' names. Since your tables and fields usually have "functional" names, it means the structural method can still be read for functional meaning.

In either case, if you use separate table occurrence groups (TOGs), it is critical to name ALL of their TOs so you can see the difference. In some lists FileMaker will tell you which TOs are connected (related), in other places it will not.

FileMaker naming conventions PDF:

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

[javabandit]

Thank you Fitch! Thanks Fenton!

I'll take some more time and look at the naming conventions. It's definitely hard to know what to select when they're just named Table 1, Table 2...

I don't mind having a complex relationship tree, as long as it's easy enough for someone to interpret it later on. Sometimes I have trouble myself understanding my own stuff. I couldn't imagine someone else trying to make sense of it!

Thank you very much for your time to help me out.

[javabandit]

Thanks for the pointer to the FileMaker Naming Conventions document. I've been reading it, and I can see lots of useful things regarding naming.

There's one question I have remaining on this, though. I've noticed that when I'm starting a database, I don't always have the best terminology for my tables, so I need to change them as I progress. If I let FileMaker just keep track of the TO's by "table 2", "table 3", and so on, Filemaker is smart enough to change all TO names when I change the table name. "table 2" becomes "categories 2" for instance.

But, if I edit the TO name in the relationship graph, Filemaker can no longer update that... or can it? Is there a way to retain the table name in the TO name?

So, for instance, suppose I start a project with a table named "clients" and I create a TO called "PTO__clients". Later I decide that the table should be "customers", how can I make "PTO__clients" automatically update to "PTO__customers"? Or, is it just up to me?

[Fitch]

AFAIK you'd have to manually change them. I wouldn't let that stop you from using an effective naming convention -- I would think you'd settle on a name well before your graph got too complex.

[javabandit]

Thanks for the response!

I did go through and add a legend, and I've changed some field and table occurrence names. It's already starting to help.

Thanks All.

[bruceR]

I'd suggest something along these lines. Your graph was unnecessarily complicated and confusing.

(Updated)

finishchart.zip

Edited May 5, 2009 by Guest

[javabandit]

Wow Bruce...

I'm looking through your version of my file. And first, -thank you- for taking such time with it.

Now, I'm studying your method to see what I can learn. I wish I could have been a bird on your shoulder as you were going through it, to hear your comments.

I thought I was on to something with the multiple layouts, and "fake" tabs. But, you've reduced it all to one layout, with a tab control. This will make maintenance so much easier. If I understand right, this is only possible because of the way you organized all the TO's to be related to the main "finishes" table.

I like the use of "z_" instead of "g_" to label global fields, since they now sort to the bottom of the table.

I like the use of "TableNameX" to indicate tables where all records match. The method I came up with after reading the "Naming Conventions" was too cumbersome.

You've simplified my portal selections too, by using script parameters. Again, I think this is only possible because you consolidated the TO's.

I see some changes in the scripting too, I'm going to study this more this afternoon.

Thank you again.

[bruceR]

You're welcome. Look for the hidden portal around the delete buttons - that's how they disappear and that's how the related record can be deleted without going to another layout. Also look at the use of auto-create relationships.

See attached for some more mods such as removal of header and auto resize. Another possible change would be the use of a resource or session table as the basis for the layout, thus allowing removal of the globals from the data tables.

finishchart.zip

Edited May 5, 2009 by Guest

[javabandit]

This is great. I feel like I'm really learning something, and my database is getting better by the hour.

I did notice the auto-create relationships yesterday, but I was having trouble understanding how the "Delete Portal Row" was working. I kept asking myself, "Which portal? How do I get to the row?" Now I see how you've gotten it to work by putting the delete button -in- a one line portal!

Those tooltips are quite extensive too. I have done some minor calculations in tooltips before, but not to the extent you've taken it. I'll save those ideas for other layouts in the future.

I've read about the auto-resize before, but I've never taken the plunge to try it out. I can see the usefulness of it, but I'm still a little shy to allow things to move and stretch around on my screen. I suppose I should just get up the courage and try it.

Today I'm incorporating some more of your ideas into my working database, and I'll post my results here when I get to a good milestone.

Thanks!

[javabandit]

Here's my new milestone:

http://madisonnet.googlepages.com/Finishchart_uploaded2_to_forum.fp7

BruceR, I've incorporated a lot of your ideas into my file. My supervisor wanted some control over certain fields, so I added an eng_change table to keep basic info on the Engineering Changes. I have also been asked to add similar info about logo designations that we have here, so there is a table for that... I'm still working on it.

I have a question:

When clicking on a portal record in the Full List tab, I'd like to set both the selected finish and the selected category. That way, if you selected a record in the Full List, it would also be the selected and highlighted record in the Finish Codes and Categories tabs. The only way I can think of is to use two different scripts to select_finish_ID. Is there a better way?

Thank you,

[bruceR]

Here's my new milestone:

http://madisonnet.googlepages.com/Finishchart_uploaded2_to_forum.fp7

BruceR, I've incorporated a lot of your ideas into my file. My supervisor wanted some control over certain fields, so I added an eng_change table to keep basic info on the Engineering Changes. I have also been asked to add similar info about logo designations that we have here, so there is a table for that... I'm still working on it.

I have a question:

When clicking on a portal record in the Full List tab, I'd like to set both the selected finish and the selected category. That way, if you selected a record in the Full List, it would also be the selected and highlighted record in the Finish Codes and Categories tabs. The only way I can think of is to use two different scripts to select_finish_ID. Is there a better way?

Thank you,

You're already using script paramters, right? Though there is only one parameter, it can handle multiple values, and there are many ways to do this, the simplest being return delimited. You can practically pass the library of congress in a script param if you want.

See http://sixfriedrice.com/wp/filemaker-dictionary-functions/ for a discussion on this subject.

And of course, you don't really need to pass multiple params in your case. If you select the finish ID then you know what its category ID is, right? So you can then set the selected category global.

[javabandit]

And of course, you don't really need to pass multiple params in your case. If you select the finish ID then you know what its category ID is, right? So you can then set the selected category global.

Yes, yes... of course! All I needed to do was add a step to my select_finish_ID script like this:

SetField [finishes::z_selected_category_ID; selected_finish::kf__category_ID]

Now, the selections are consistent across all the tabs. Thank you so much for your time and effort on this. I'll check out that six.fried.rice link later today.