Jump to content
The ORIGINAL FileMaker Community - Forum - Online Business Apps & Software Forum
  • 0
kirkrr

How to migrate spider to TOG?

Question

kirkrr

The last few FM apps that I built, are all TOG based (after a great deal of futzing around, just to find out that TOs are, in effect, an alias to the source table, but filtered based on the relationship). It has been a very, very successful piece of learning, making FM development a far, far easier thing than in the past.

 

But the past is what is haunting me now. I have an older (still FM9) application that is a spider diagram mess. I want to convert this to a TOG structure for some planned significant upgrades. I think I clearly understand what needs to be done; what I DON'T understand, is the appropriate order in which to make changes, to have the minimum work to do in the transition.

 

There are nearly 80 scripts, 8 source tables, over 300 fields, 36 user layouts, a dozen report layouts, and 20 or so, never-to-be-seen-by-an-end-user layouts for inspecting data under the covers.

 

Do I leave my spider diagram intact, while reconstructing TOGs? If I do, how will I know what is broken, as things will still work based on the old spider diagram? If I break the spider apart to TOGs, then all the scripts will need to be manually reworked.

 

I don't know whether the DDR is worth reviewing with all the change impact.

 

My current thought is to scrap the spider diagram, and go layout by layout, setting up new TOGs for each as appropriate, then fix the scripts for each layout as well. Tedious, but the best I can think of.

 

Suggestions?????

 

==============

Share this post


Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0
kirkrr

No suggestions? Is there some practice that someone has learned that is easier? or pitfalls of some approach?

At this point, I am considering just scrapping the spider TOs, and just keeping the source tables.

Share this post


Link to post
Share on other sites
  • 0
AHunter3

80% of the time, TOGs are more hassle than the hassle they attempt to fix. You have a relationship between Clients and Jobs in the top TOG, and also a relationship between Clients and ClientPersonnel which in turn power a value list of related values only of ClientPersonnel which you use from within Jobs. Then in a different TOG, ostensibly set up to simplify your rel diagram, you have InvoiceProducts which is related to InvoiceJobs and then one day you need a dropdown VL of related ClientPersonnel so the next thing you know you've had to add a rel from InvoiceJobs to new TO ClientsViaInvJobs and from there to CliPersonnelViaInvJobs just to power that VL, all of that redundant and in existence only because you're using TOGs.

 

But that's not answering your question, is it?

 

I'd make the new TOG and then duplicate the layout you wish to migrate to the TOG, and in the original change the home TO of the layout, change the native fields, change the related fields, change the VLs attached to the fields, then examine the buttonscripts and change those as well; you can refer back to the duplicate which will contain the original structure as you go, until you are done, then you can nuke it.

 

But spiders aren't so bad if you spend some time straightening them out; TOGS may look more organized but they can lead to their own messes as described above.

Share this post


Link to post
Share on other sites
  • 0
kirkrr
I'd make the new TOG and then duplicate the layout you wish to migrate to the TOG, and in the original change the home TO of the layout, change the native fields, change the related fields, change the VLs attached to the fields, then examine the buttonscripts and change those as well; you can refer back to the duplicate which will contain the original structure as you go, until you are done, then you can nuke it.

 

But spiders aren't so bad if you spend some time straightening them out; TOGS may look more organized but they can lead to their own messes as described above.

 

I've gotten really good at the TOG stuff, and the older product needs to have 4 new modules added, which, in the spider diagram, would be painful at best.

 

I REALLY like the idea of duplicate layouts. THAT sounds like a great transition approach, that I would not have thought of..... thanks!

Share this post


Link to post
Share on other sites
This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

Terms of Use