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
>