8 Replies Latest reply on May 25, 2012 12:25 PM by Stephen Huston

    Separating data from structure referencing the file to itself, possible approach?



      I've got a FMP file with a quite complex solution, I want to keep the solution in a single file, but I want also to separate the data from structure. The result should enable, when needed, to refer the data to another data source while being able to have the solution in a single file.


      Possible solution (this is the question)

      1) I reference the file to itself, using External Data Sources

      2) I change in the relationship graph the references to the tables using the new external data source (which practically it's the file itself, but not logically)

      3) when needed I could change the references in the external data sources to display remote data or to simplify upgrades.


      Example 1 - I may install the solution file on the iPhone/iPad referencing it to FMP server, or I may install the solution locally on the iPhone/iPad referencing the data to itself enabling the user to download a single file.


      Example 2 - I could duplicate the file using one file for data storage (a) and the other file for the solution logic (b)referenced to the former (a). This should enable me to upgrade the solution changing the file (a) with a newer one.


      I've made some experiments using the Starter Solution "Contact Management" and it works


      Does it make sense?

      What are possibles issues?

      Does it works faster on a gsm network giving the fact that the application logic is installed locally while the data are on FMP server?


      Thank you


        • 1. Re: Separating data from structure referencing the file to itself, possible approach?



          I think you are describing is the conversion from a single file to the Data Separation model.  When you are done,  you have two files,  one that is the interface and one that has the data.  At least initially these files are close to being identical until you change the references in the interface file to point to the data file.  Once that is done you can modify the interface file and as long as no changes are required in the data file and simply swap the interface file for a new version.


          There has been a lot written about the Data separation model and there is a large segment of the developer community that love this method and use it very successfully.



          1 of 1 people found this helpful
          • 2. Re: Separating data from structure referencing the file to itself, possible approach?

            Thank you Bruce,


            I try to explain the question more clearly.


            I'm speaking of a data separation model (that I've already used a lot) but the difference is that the separation is in the file itself.

            Imagine that the filename is "Contact Management.fp7"


            In the external data sources I add a source Contact Management that point to the file "Contact Management.fp7" itself

            file:Contact Management.fp7


            file:Contact Management_data_local.fp7


            fmnet:/ Management_data.fp7


            Advantages / goals


            1) In this way I can keep the development in a single file (source file:Contact Management.fp7).

            2) I can install a single file on a iOs device (source file:Contact Management.fp7).

            3) I can instal a single file on a iOS device (or PC), with the application logic, and reference it to an external data source (ex.source fmnet:/ Management_data.fp7).

            In this scenario do I have a better performance due to the fact that the interface is installed locally on a slow GSM or VPN connection (THIS IS AN IMPORTANT QUESITON)?

            4) I can use a "normal" separation model installing two files "Contact Management.fp7" and reference it to an external data source ex. "Contact Management_data_local.fp7" that contains the data and that "Contact Management.fp7" is pointed to (source file:Contact Management_data_local.fp7).


            I hope that I've explained myself.


            I attach the the Starter Solution "Contact Management"  modified in the external data sources and relationship graph.

            I've made some testing and it's works fine, but before adapting a complex solution to this logic I'm searching for advice ;-)


            Thank you


            • 3. Re: Separating data from structure referencing the file to itself, possible approach?



              Is your goal to be able to quickly change the reference for the external tables [which in the current case are in the actual interface file]?


              Since you've not used any tables in the actual file, but all TOs are referenced as an external source, I am not sure what you gain. It seems like a extra layer of complexity is added.


              Your file path for the external references

              file:Contact Management.fp7

              file:Contact Management_data_local.fp7

              fmnet:/ Management_data.fp7


              would seem to always use the first instance (itself) unless the file is no longer named Contact Management. Or do you plan to remove one of the references should you deploy the file(s) separately?


              Perhaps adding a large group of records and comparing this method vs a more standard method would give you some answers.



              1 of 1 people found this helpful
              • 4. Re: Separating data from structure referencing the file to itself, possible approach?



                yes the goal is to deploy the file separately removing the "itself reference" (in the example file:Contact Management.fp7) beside being able to deploy the solution on a single file (for example for installing it on iOS device) - and develop the solution in a single file -



                In the real solution, not in this example, some tables are containing the interface data, images, text… those tables will remain in the file. So I suppose that accessing the solution data from an external data sources (fmnet:/ ….) from an iOS with a slow connection will speed up the process (the interface file is installed on the device, the data are on FMP server)


                Thank You


                • 5. Re: Separating data from structure referencing the file to itself, possible approach?
                  Stephen Huston

                  It sounds like you are doing exactly what many of us do during the construction of a Seapration Model file set -- build it in one file, but with mulitiple file references, one of which gets repointed to the external file when we save the copy of the file and rename it to be interface or data.


                  However, if the goal is to have a served data set, it makes more sense to me not to put the interface on the iOS device, but on the server itself. This way you need only update the copy on the server, without having to replace files on multiple devices, whenever there is an interface change.


                  I would recommend put it all on the server, and distributing only an Opener or Launcher file to the iOS users. The Launcher file simply points to the interface file on the server via the IP address and opens it via a script which is set to run On file opening, and this file won't have to be changed on the iOS device to deal with upgrades (unless the IP address changes or the files names on the server are changed).

                  • 6. Re: Separating data from structure referencing the file to itself, possible approach?

                    In theory, I agree with the data separation model, or some varient of it. Personally, I'd rather see all data stored outside the solution file, in as simple a form as possible (csv records, text files, media, etc.) and only the layouts, relationships, etc. in the solution. I don't know how much having two solution files (one containing only data) with all that overhead helps.


                    But I do know my clients. In pre-FMP 7 days, when each file could hold only one table, they were always losing tables or overwriting them, or having some sort of problem with the paths not resolving properly. Not EVERY client, but enough that it was a hassel. I'd rather deal with doing a data migration for every new build or corrupted file issue. It's probably about the same amount of work for me, but more straightforward, so I can just knock it out when I have to.


                    That said, your actual milage may vary. If you have one client, or a few, that have a decent IT department, and you're going to be modifying on the solution file on a regular basis, I'd say go for it. I have done SQL front ends in FMP and it can be a bit of a pain to set up, but the performance hit is tollerable, considering the vast amount of data being pulled in. So I wouldn't expect performance to be that much of an issue.

                    • 7. Re: Separating data from structure referencing the file to itself, possible approach?

                      Thank You Stephen,


                      the solution file is 8/9 mb without any client's data (just logic and interface), and it's 20 mb with clients data.


                      If I manage to install the logic on the iOs and leave the data on FMP server I guess that the performance should increase on a slow connection. (THATI IS THE QUESTION!).


                      I could in any case use a pointer to open the solution that checks if the solution logic is installed on iOS is the last one (eventually replacing it using a container field) but using the local solution logic to access the remote data without the need to download the interface and the solution logic on a slow GSM connection.


                      I suggest anyone interested to iOS and FMP to view the webinar

                      FileMaker Go Data Synchronization and Version Management Techniques




                      • 8. Re: Separating data from structure referencing the file to itself, possible approach?
                        Stephen Huston

                        Considering the file sizes, it does seem that installing the interface locally would speed up an iOS WAN connection's response. But I wonder if it makes a difference during session use or only when loading/opening the solution at the start of the session.


                        If gain is only at startup, I would still consider the issue of needing to update interface files on iOS devices when they are upgraded. Installing a local file if not current has been addressed in some of the webinar info re GoZync. They present a method to test if the local file is latest rev and update if not most recent.