Stephen,

I really understand your desire to use Anchor bouy.  I have worked on solutions that use spider or other mutant graph arangements and found it helpful to leave the graph more or less as is and add notes in the graph for the TOs  that are pseudo anchors.  These are the TO that would be the anchor and the layouts and calculations are based on them.  Not as neat,  but lets me think about how things work in an ABish way. It makes it easier for me to how the existing calculations and scripts work.  This does save a lot re-development time since you are not breaking any of the existing calculations or scripts.

I have also found it useful to add a limited number of Anchor bouy TOGs for new work and base my calculations and scripts on these.   In most cases,  I'm starting the process with a script. At the beginning of script is a GTRR to a blank layout built on the AB TOG in an off screen window.  So I end with the correct record/record set in the correct context. At the end of the script I commit the record,  close the off screen window,  select the original window and refresh the screen.   If everything is setup correctly the user should see the correct results on the screen.

HTH  Best of luck with your project.
Bruce Herbach
Herbach Consulting
FileMaker 9,10,11 Certified Developer

On Sat, Jan 5, 2013 at 11:38 AM, Stephen Wonfor <[log in to unmask]> wrote:
Hi

I am doing some reno's on a system I built in late 2004 using Filemaker 7.  A new world for sure back then and much to learn - all of which I did during this build.  8 years later I have been called back in for some updates.

Some issues:
1.  Relationship graph design seems to have been a mutant variant of "Offset Twisted Spider"™.
2.  3 other programmers - none Filemaker at heart - have "adjusted" the database over the years.
3.  I became an "Anchor Boy" - the design philosophy works well for me and I "get" it.
4.  Anchor Boys, this one anyway, are afraid of Spiders.

So...

I am thinking about adding some TOGS to suit the purposes of the update.  All updates are in regard to calculations.  What I am thinking about is adding some TOGS to base calculations upon - and thus I find the "evaluate this calculation from the context of" matter becoming of first importance.  In my AB world I have always used the base table as the context for calculations.  Now I am wondering, due to design complications whether I can create some new AB TOGs to derive my calculated values and still have them function as expected when viewed in other TOGs.

The main issue is 5 anchor tables that are sadly linked together - these account for 90% of the "traffic" in terms of calculations and scripts.  Rather than deconstruction - no budget for that - I just want to get these new calc's enabled so I am hoping I can use my new AB style TOGs to implement this.  It seems like it will work but I'd like to confirm prior to starting in on them.  The gist of it being that my new calc's will use the same base tables but different instances of them.

Stephen

----

"There is so little difference between husbands you might as well keep the first." ---- Adela Rogers St. Johns