12 Replies Latest reply on Jun 30, 2015 6:06 AM by coherentkris

    separate data from lay outs


      The solution that we have now has been designed for the own company (tax lawyers). It consists of various files without separation between the front end and back end. Others are interested now. Then a separation of the tables and lay outs seems to be more appropriate in order to avoid frequent changes in the tables and mainly limiting ourselves to changes in the different lay outs. My question is, given the situation of tables and lay outs together now, what is the most efficient way to separate them?


      Thanks in advance.


      Rein Dobbelaar, NL 

        • 1. Re: separate data from lay outs

          Create a copy of the file.  In the designated UI file, change each TO to point to the base table in the designated data file.  Tedious but easy since everything will map nicely.


          In the data file then strip out all scripts and all layouts.  Remove any TOs and relationships that are not needed for calculations.


          You may want to use a tool like BaseElements or Inspector Pro to quickly find any broken references.

          • 2. Re: separate data from lay outs
            Stephen Huston

            Wim has given you the right answer. I would add only that you need to complete ALL of the repointing of TOs in your interface/layout file to the duplicated Data file before doing any further development in either file. FileMaker uses internal IDs for everything in the file structure, and repointing only works when those internal IDs are identical, which is still true when the file is duplicated but otherwise unedted. Once you start fiddling with either file for anything other than repointing TOs, you will be affecting IDs. Your repointing needs to be complete before other file changes are made to avoid issues with mismatched internal IDs. After the repointing, they are different files, and it's safe to edit other structural stuff from then on.

            • 3. Re: separate data from lay outs

              Wim has given the basic answer correctly, and Stephen H.'s addendum is also very important. So you've got the basic ideas right there.



              Now, as Wim says, the process of repointing all the table occurrences to tables in another file is "tedious" — I've done it more times than I can count. But it might be more than tedious. It may be messy and complicated. Let's say you start out with files A, B, C, D, E, F and G. Duplicating these files is child's play. Opening A and repointing all the external-file table occurrences to B, C, D, E, F and G is tedious. Doing this again for each of the other files extends the tedium. The amount of tedium is proportional to the number of table occurrences. If the files are fairly simple and there are few table occurrences, great.

              But there are other possible problems.

              First, to extend Stephen's caveat: You're going to want to make sure that you create all of the data files before you start repointing anything, or you might end up with table occurrences in various files that are pointing to table occurrences in UI files that no longer have data tables in them (or are about to have their data tables deleted), and that could cause a lot of stuff to break.

              Second, there's more to fixing external file references than repointing table occurrences. I think it's probably safe to say that most of the references to data in scripts are going to be referring to table occurrences defined in the same file's table occurrence graph, and if the table occurrences in the local graph are properly updated, those script steps will automatically be updated too. But there are other, more literal ways to refer to a file, for example, even after you've repointed everything in the table occurrence graph, an import script might still want to open file F, instead of F DATA. Looking at the Manage External Data Sources dialog will make it fairly easy to fix most of these problems, but in my experience, this might not fix all of them.

              And then there's the fact that you may start out with half a dozen files and simply end up with a dozen files. Where's the benefit in that?

              If you're hosting the files yourself, the difference between hosting 2 files and hosting 12 or 24 is probably minimal. If you're hosting the files through a third-party hosting service, on the other hand, the difference will be enormous to your monthly bill.

              I've long been a huge advocate of the separation approach — I've used it for almost all of my databases ever since the release of FileMaker 7. There may be advantages to having several UI files and/or several data files — but those are, I think, special cases with special security concerns. For most of us FileMaker developers, it's a big enough pain to have to deal with JUST ONE of each. And if you have multiple files, you lose tons of benefits: themes have to be updated in each files; scripts have to be copied and pasted and edited; login accounts to be managed everywhere; etc. The main advantage of the separation approach is that it makes it easier to create updates offline. But if you're looking for simplicity, you're not going to find it by adding six, ten, a dozen to the number of files you have to manage.

              I've just gone through the process in reverse, that is, I've spent the last five days consolidating the two original files (UI and data) in a separation-model solution. I've done this a number of times, too, and went into it with a fairly solid awareness of the amount of work that would be involved. Even so, I was surprised. It turned out to be about three times more work than I expected.

              At some point, rebuilding the solution from the ground up in FileMaker 14 starts to make really good sense. I urge you to think the whole process through carefully before you take the first step. Good luck.


              • 4. Re: separate data from lay outs

                Dear Wim, thank you very much.


                • 5. Re: separate data from lay outs

                  Dear Stephen, thanks for you explanation.


                  • 6. Re: separate data from lay outs

                    Dear Will, thanks for your answer. What I feared already a bit is that it has a number of implications which are now clear to me.


                    • 7. Re: separate data from lay outs

                      Todd Geist has a great instructional video:

                      FileMaker Separation Model: Splitting Files - YouTube

                      • 8. Re: separate data from lay outs

                        You have received excellent advice.  Just one thing to add. Create ONE File for the interface and ONE file for the data. Then take the tables from the files you have, (depends on the age of your solution) and place them in the new files.


                        That way you only have two files with multiple tables to administer. In many cases, most of the tables will be in the data file


                        The suggestion to view Todd Geist's video is a good one.




                        Wim is also an excellent developer.  Hope the project isn't too taxing :-)

                        • 9. Re: separate data from lay outs
                          Stephen Huston

                          I agree with Hank, but then I have been using the Separation Model since the FP7 multi-table file format started, and I treated this question as being about "How to take a single file and turn it into a data/interface separation."


                          If you are already working with multiple files, each with its own data and interface, I recommend either of these approaches (but not both):

                          • Build one new interface file, leaving the data sources as is, or
                          • Move all of the data tables into a single file, and then build a new interface file to use with it.

                          Both approaches assume it's time to restructure your old multi-file (pre-7) with a single data file, and, IMHO, the 2nd option is preferable.

                          • 10. Re: separate data from lay outs

                            Thanks for the tip of the video. It has helped me a lot.


                            Rein Dobbelaar

                            • 11. Re: separate data from lay outs

                              Thanks very much for the suggestion of one file for the data and one for the UI. I know now what to do thanks to all your advices.