FILEMAKER: GTRR Work Great In Anchor / Buoy

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

You might be thinking that a scripted GTRR (go to related record) may not work correctly in the Anchor/Buoy system. The truth of the matter is ... GTRR actually works better in a GTRR implementation. The fact that all layouts are only tied to base tables (anchors) is the key to making the whole thing work. Just because you are using a buoy relationship as the Go To, you are still going to a layout that has the same anchor. This is a bit confusing at first but your faith is not misplaced here.

If you have all your layouts tied to your true relationship graph anchors, your GTRR actions in an Anchor/Buoy implementation will work like a charm!

Free form use of the relationship graph is not easy to associate to layout. The way that everything links to everything and that relationships flow in both possible directions can confuse many a FileMaker developer.

The Anchor / Buoy method is very layout design friendly. This is because only certain table occurrences can be linked to layouts. This constraint pays some serious dividends later on in your design process but more about that later.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.
====================== ADVERTISEMENT ==============================
To check out the online FileMaker Crosswords, please visit http://www.dwaynewright.com/crossword.html
===================================================================

FILEMAKER: Benefits Anchor / Buoy (the quick list)

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

Here is a quick list of some of the benefit for Anchor/Buoy

HELPS DEFINE PROPER DATA MODELING
The aspect that no two base table touch directly can be helpful in understanding how each entity in your business model actually works. When you add a new buoy to an anchor, you are basically agreeing to the fact these two business elements communicate via this method.

LAYOUT CONTEXT IS FILTERED
This was the feature that got me drinking the Anchor/Buoy koolaid. In many places, you only see table occurrences that really do link (from a business perspective) to a default base table.

MAKES GREAT USE OF MULTIPLE PREDICATE RELATIONSHIPS
This is because the multiple predicate relationship can easily be identified in other areas and you don’t pick a multiple predicate relationship to use by mistake. This does require that you use the recommended naming convention.

NAMING CONVENTION ALSO INDICATES RELATIONSHIPS OTHER THAN EQUAL TO
Yeah, what I said above. One of the biggest hurdles in advanced FileMaker design is picking the correct table occurrence (and its associated relationship) to use at a given time.

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.
====================== ADVERTISEMENT ==============================
For more information on the Virtual One On One Training, please visit http://www.dwaynewright.com/training.html
===================================================================

A READER ASKS: Text vs Number Strings In Key Fields

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

A READER ASKS
I was reading your “FileMaker Thought Bucket” Blog. I have developed a FMP 8 solution for our 3000 student school district. I am using Filemaker serial number generated primary keys. Sometimes I have used a number field and sometimes a text field. Your Blog says you prefer text fields. Is that a strong preference and what is your logic? Should I go back and change my number fields to text? I know that primary and foreign keys have to be of the same type to properly match.

I realize you are probably at Devcon at the moment. Any opinions you have would be appreciated.

-------
DWAYNE RESPONDS
Well, part of the reason is pure muscle memory. I’ve been doing it that way for so long, that it is second nature to me. Here are some of the other reasons I use text values for my primary key fields.

1) When working on client databases and importing their data into the new database, I increment the first alpha character to a new value. So if the next primary key data string would have been D7341, I change it so the next value is E7341. Then when I look at the list view of my primary keys, I can easily see the records that were created after my last update.

2) Number characters can only go from 0 to 9 per character. In a text setup, I can use at least 30 characters per character (I avoid using O, I, L because they can look like 0 or 1). If I make the field case sensitive by changing the way the index of the field is stored, I can have even more unique character options per character position.

None of these reasons are very strong for going to text strings in primary key fields but I still do it nonetheless.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.
====================== ADVERTISEMENT ==============================
For more information on the Virtual One On One Training, please visit http://www.dwaynewright.com/training.html
===================================================================

FILEMAKER: Anchor / Buoy Segmentation Makes Better Printing

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

In previous discussions, we have chatted about how the relationship graph TOs (table occurrences) can be grouped. We have chatted about how FileMaker Anchor / Buoy leverages TOGs (table occurrence groups) as a key element in its strategy to tame the FileMaker Relationship Graph. When you have all your table occurrences grouped in a manner such as this, it makes printing the Relationship Graph much easier.

Why would you want to print the Relationship Graph? Well, it might help you plan where you want your relationships to go and how you are going to get there. You may use this as a method to describe the interactions between modules to project stake holders. You might want to have a history of the evolution of your Relationship Graph for project management needs. You may want to print the Relationship Graph to pdf and send it to a FileMaker Consultant for their recommendations or technical support.

In the lower right corner of the Relationship Graph are the two buttons that help you setup your Relationship Graph for printing.

Page Guides - The first button in the print button group is used to turn on or off the page guides for printing the graphic area. This can be a worthwhile organization tool and is a great idea if you are going to print out the relationship graph area for a presentation or part of your overall database documentation.

Page Setup - The next and final button in the bottom button row is used to bring up the print preview screen for the relationship graph area. This can be very useful if you are going to print out the relationship graph area for a presentation or part of your overall database documentation.

ORGANIZING YOUR GRID TO A GRID
So in some ways, your Anchor / Buoy groups can be considered a grid of relationships. So the next step is to turn on the Paper Guides (via the button mentioned above) and then place your TOGs neatly into the spaces added by the grid.

So I decided to practice what I’m preaching here. I had my Relationship Graph in very good shape for my InBizness SOHO product. However, I have never made sure that it printed perfectly. This is a large task because InBizness SOHO 2.5 (the release I’m working on) has 211 table occurrences for the 45 tables it currently has. It took about 30 minutes for me to line up all those table occurrences to be in synch with the Page Guide grid. I know that many of my competitors in the FileMaker framework business market could never print all the relationships for their solution from one place and it all fits into the printable grid.

Here you can see a 50% print preview look at part of InBizness SOHO 2.5 Relationship Graph. All TOGs are sorted alphabetically, fully anchor / buoy, full consistent naming convention and now totally printer friendly.

SUMMING IT UP
The TOG setup for Anchor / Buoy makes the printing of a Relationship Graph a reasonable experience. Printing your table occurrence groups occasionally can be very beneficial for project documentation. The process of reorganizing your graph this way also gives you the opportunity to take a very close look at it. That means you can also use this time to delete unneeded TOs and rename them as necessary.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.
====================== ADVERTISEMENT ==============================
For more information on the InBizness SOHO and other quality FileMaker framework solutions, please visit http://www.dwaynewright.com/solutions.html

FILEMAKER: More About Calculation Context And Table Occurrences

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

FileMaker relationship context can be one of the most challenging hurdles for a FileMaker developer starting out. In many cases, you can create a very good FileMaker database and skirt right past context issues. However, as your FileMaker database grows and evolves, relationship context will be an area in your design that you will need to deal with.

Let’s briefly cover the aspect about how a calculation is tied to a table occurrence. As you know from our previous discussions, FileMaker relationships flow in a bidirectional manner. In an Anchor / Buoy design, we only utilize one direction of left to right or Anchor to Buoy. We also talked about how every layout can only be assigned to the Anchor table occurrence. I put it to you that every calculation should only be tied to Anchors as well. In fact, FileMaker will default to that action for every new calculation. This is because the Manage Database dialog box, by default, will show the calculations in context for the current layout (and that is an anchor).

If you are not aware of calculation context, look at the top of the define calculation dialog box and you will see it. There is a pull down menu that allows you to select a table occurrence as a reference point for your calculation. So if your calculation involves related values, you have to make sure your reference point (aka point of context) is set correctly. Anchor / Buoy helps in this matter because the naming convention you use to name your buoys will always allow you to pick the correct related table occurrence for the task at hand.


=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.
====================== ADVERTISEMENT ==============================
Click Here To See The FileMaker Book (via a blog) homepage!
===================================================================