Migration thru Consolidation: What to do with the "relationship TOs"?

[lpm]

FMP8 Adv, WinXP

I read this in Bob Bowers’ Best Practices article: “During the conversion process, a table occurrence that’s named the same as the source table for that file will be created, and every relationship in the old file will turn into a table occurrence linked to that occurrence.”

My question/problem:

After successfully coverting a small (6 file) solution from FMP5.5 to FMP8 and then consolidating the 6 files into one master file, I’m wondering if I need to keep the several “relationship TOs” that were generated during the conversion process or do I delete them and “reconnect” the TOs somehow. I’m having trouble understanding this. Resources seem to be quite available on the subject of conversion/migration and sparse on the subject of consolidation.

I’ve read the following resources but none seem to address this or discuss what to do with the “relationship TOs” after consolidation.

-“Converting FM Databases from Previous Versions”

-“Foundations & Migration Methodologies Tech Brief”(especially pp. 39-40)

-Danny Mack’s “Consolidating your FMP Solutions with FMP8”

-Bob Bowers “…Migrating pre-.fp7 Solutions to FileMaker 8…”

Thank you for any advice you have on this subject. lpm

[Ender]

In general, I think you'd reuse one of the TOs in the consolidated file to take the place of the external TO that the original file was referring to. But beyond that, it depends on what's needed. I guess you'd continue to consolidate the TOs so that there are only unique chains of relationships remaining.

You do have to be careful about removing TOs, however. Always figure out what all the dependencies are, and switch them to the consolidated TO before deleting the duplicate.

[lpm]

Hi Ender: During conversion, every relationship in the old FMP5.5 file turned into a table occurrence in the new FMP8 (converted) file. During the consolidation process, I recreated all TOs in the master file that existed in the converted files (including the "relationship TOs). After completing the necessary steps to finish the consolidation (repointing TOs internally, recreating layouts, importing scripts/data, eliminating file references, etc.) I’m still left with a relationship graph in the master file that shows the “relationship TOs” that were automatically created during conversion. Among the six FMP5.5 files before conversion, there were a total of 18 relationships (in the define relationships dialog). In the FMP8 master file (after conversion and consolidation) there are now 18 TOs whose sole purpose (I think?!) is to provide relationships that existed in the FMP5.5 define relationship dialog. Do I need to keep these 18 TOs in place to maintain relationships, or can I create relationships without these 18 TOs? I’m still confused about this. TIA, lpm

[Ender]

The only way you'd have the same number post-consolidation, is if you kept each file's TOs as separate table occurrence groups in the consolidated file. While this is fine, if you want to use multiple TOGs, it does require a little more scripting to navigate between layouts based on different TOGs.

For a small solution like yours, it's easier to have them all connected. This means removing some of the duplicates and tying the TOGs together into one connected graph.

It's hard to be specific about how to do this without having an example to talk about. If possible, I'd suggest you post your relationship graph, and maybe we can see what could be optimized.

[lpm]

Thanks, Ender. I'd like to try removing some of the duplicates and tying the TOGs together into one connected graph. How do I send a pdf attachment showing the graph to this forum?

[Ender]

Use the Attachment option in the Full Reply form.

[lpm]

Here is a view of the graph.

RelGraph.pdf

[Fenton]

A little confusing. You say that you you've done "repointing TOs, recreating layouts, ...scripts". Does this mean that there are NO objects whatsoever attached to the old TOs. In particular, to the old TO of the "one file" that you're in? In other words, did you remember that the current file's TO also needed to be switched over?

1. If you already switched everything over the current file's TO, its layouts, fields (both on layouts, and in Define Fields related calculation fields), and portals, so that the old TOs have absolutely nothing attached to them, then I'd say "Yes", you can delete them.

2. Otherwise you're going to have to do a switch of the two competing TOs for the file's original table. There are two ways I can think of to do that:

2.a, replace the new TO with the old one; break the relationships then recreate them. This would save retargetting all the fields on its layouts, but would break all your new scripts targetting the old. Ugh. Or,

2.b, switch original's layouts, fields and portals on them, to the new TO. Switch any calculation fields using relationships to new TO's. Tedious.

Hopefully #1 above is true. Otherwise it's either 2.a or 2.b, neither of which is fun. It depends how many fields on the layouts, and how many scripts as to which is easier. 2.a may be less tedious, but trickier; check every script step, including Go To Related Record, target layout.

[lpm]

I need to think this over... I believe that I did not begin with a hub file from the old set of converted files and then recreate/import/etc the other five files. Instead,I began with a newly created(blank)file and recreated/imported/etc all six files into one consolidated file. Is that the same as #1 in your list?

[Ender]

Yeah, it looks like the TOs are all local (there are no italicized TO names, which would be external references). So we do indeed have multiple TOGs.

Like I said, you can work with multiple TOGs, but I think it's a little bit of work to then navigate between their layouts. I'm mainly talking about Go to Related Record[] jumps. Fenton can probably say more about this.

I'd probably bite the bullet and link up the TOGs and remove the duplicates. To me, this is easier to build on later. In this case, you'd look at each primary relationship, and decide which TO is going to remain, and which can be re-pointed. Since re-pointing is tedious (2.b. above), it's best to keep the TO that has the most stuff going on with it. It's also best to have the busiest links in the middle.

So what might this look like? You might link TE_Teachers to SO_Student_Objs, and SO_Student_Objs to OB_Objectives and also to HO_HillObj. I'm guessing StudyAreas has a parent-child relationship to Objectives, if so, then SA_StudyAreas would be linked to OB_Objectives. This would eliminate a number of the ancillary copies of these TOs, and only leave the duplicates that are there because they are linked via other keys.

BTW: it would help us to understand the relationships better if you can identify the primary keys. This can be done by naming convention, or if you have primary keys using an auto-enter serial number or validated to be unique, they will show with a single line on the graph rather than a chicken-foot. For example, StudentKey in HillObj shows as a primary key, but CodeNum in Objectives and StudyAreas does not.

Anyway, I'd estimate consolidating the TOs would reduce the graph to about 10 TOs.

[lpm]

In a companion file that will eventually bridge to this file, the relationship graph is organized and displayed using the anchor-bouy method and it seems (please correct me if I'm wrong!) that you are describing more of a hub-spoke relationship graph. I guess I haven't used GTRR much and have always gravitated towards the a-b method. At this point, do you think it would be more difficult for me to learn how to trim/re-point the TOs and consolidate the TOGs (2.b above) or become better at analyzing my TOs in this file as GTRR is needed? In any case, I'm going to sleep on this great information you've shared with me and dive back in tomorrow and see what I can do. Thanks again!

[Fenton]

I'm a fan of the "anchor-buoy" method, so the graph looks pretty good to me. Though there's one that seems redundant, HO_Objectives. And Help is pretty much on its own, but that's OK.

Yes, I think Go To Related Record jumps between TOGs is not a problem at all. Of course, you also often have to get back, which, if related, requires another TO; but that's fine. Personally I just find easier to deal with a modularized Relationship Graph.

The main thing we cannot see, which is pretty important when you're deciding what to do now, is the layouts and scripts. It seems as if you've got the Relationship Graph done pretty much. So, if your layouts and/or scripts are incorrectly assigned, probably you should fix them.

By "incorrectly" I mean, the "main" layout for a table should be assigned to its "anchor" TO; otherwise it will be confusing. Scripts using relationships need to have the correct TOs, or the relational navigation/data access will not work.

Unless you've got lots and lots and lots of them; in which case you might want to consider consolidating your graph to be less modular, to save time; if that helps. But we can't see -! You could Save a Clone, zip and upload it, if it's not too big. That would help us see what the layout/script situation is, in relation to the graph.

[Ender]

...the relationship graph is organized and displayed using the anchor-bouy method and it seems (please correct me if I'm wrong!) that you are describing more of a hub-spoke relationship graph.

Yes on both counts! So Fenton is right that there's not much to do in terms of the graph if you wish to stick with the anchor-bouy model.

At this point, do you think it would be more difficult for me to learn how to trim/re-point the TOs and consolidate the TOGs (2.b above) or become better at analyzing my TOs in this file as GTRR is needed?

Well, I think it's good to understand both anchor-buoy and hub-and-spoke. You might try making a copy of the file and trying to switch that to hub-and-spoke so you can see how it works. Anyway, you asked about consolidation, and that's mostly a hub-and-spoke kind of need. But if anchor-buoy is what you're after, then you'll just need to worry about the script references and making GTRR work when you get to that point.

[lpm]

TO: Fenton and Ender

Yes, the HO_Objectives TO is redundant and will be deleted. The layouts and scripts seem to function well – I’ve revised all calcs and scripts to reference the proper TOs. I will indeed experiment with the hub-spoke model so I can expand my knowledge in this area, but I’ll probably stay with the anchor-bouy method for now. Thank you both so much for your insights, for your great advice, and for the confidence and security I’ve felt from reading your posts here. This forum thing is really great! Best wishes, lpm