1 2 Previous Next 18 Replies Latest reply on Jan 12, 2015 5:38 AM by wimdecorte

    Multifile solutions design in FM

    jurijn

      Hello,

       

      Im opening some topic about multifile solutions vs. single file solutions.

      I want to hear some opinions from experienced FM developers and users.

       

      What are the benefits of dividing a one solution (file; FMDB)  in more files, FMdbs?
      Why and when should that be a good practise?


      I cant see advantage in dividing a solution to a frontend file and a backend file or even in a more files. Where frontend solution (file) holds only the layouts and backend solution (file) all the tables and table occurences -> data.

       

      Performance is probably not the cause.
      It is because of modularization?
      Is that just another higher unit of modularization (higher layer of modularization)?

       

      Please join the discussion and give some examples. Any good links would be also very helpful.


      Thanks in advance!

      jurij

       

       

       

       

       

       


       




        • 2. Re: Multifile solutions design in FM
          mark_scott

          Hello jurij,

           

          As you suspect, there are many options—not to mention many pros, cons, and opinions!—for using multiple files. The simplest conceptually (albeit not always simplest to design and implement) is the setup you describe, with separate front-end and back-end (data) files, known in FileMaker parlance as the "Data Separation Model" or just "DSM." Search this forum using that term and you'll find plenty of existing discussion. Here, for example, is a recent thread on that exact topic. Also, the independent (and excellent) FileMaker Forums has an entire subforum devoted to this topic.

           

          Hope this helps get you started.

           

          Mark

           

          P.S.  BTW, I'm (generally) a proponent of the DSM approach.

          • 3. Re: Multifile solutions design in FM
            jbante
            The most common reason given for multi-file solutions is the hypothetical ability to swap out a "user interface" file with new interface and business logic and leaving the same data file in place to avoid any need to import existing data to a new file. In practice, data schema changes are just as common as interface and business logic changes, making this a moot point. For folks with certain deployment constraints, like vertical market solutions, it can sometimes still be worth bending over backwards and twisting yourself into a pretzel to enable this anyway.  In my own experience, the best reason I've seen for multi-file solutions had nothing to do with modularity or deploying updates, and everything to do with organization and containing long-term corruption. In large enough organizations that run most of their operations out of FileMaker, it can make sense to have multiple interface files for each separate sub-application in use, e.g., production might have one interface file, sales might have another interface file, and fulfillment might have a 3rd interface file. This limits how much developers have to deal with at any one time while working on any one problem, and often takes a tiny bit of complexity out of the users' experiences, too. If the data files are also separated out, then this contains the damage done if one of the files eventually acquires any corruption.
            • 4. Re: Multifile solutions design in FM
              Mike_Mitchell

              Along similar lines, one good reason to separate is when dealing with external container data. If you move your table(s) containing the container fields into a separate file, you avoid any data migration issues when updating (since the schema associated with just the containers is unlikely to change very much, if at all). The data migration issues associated with containers are ... painful.

              • 5. Re: Multifile solutions design in FM
                wimdecorte

                One thing that is getting overlooked here is the BIG benefit that you get from multiple files and especially splitting of fairly static data tables into their own file: backups are a lot faster given the nature of the hard-linking in the backup mechanism.

                • 6. Re: Multifile solutions design in FM
                  fitch

                  I agree with you in general, JB. OTOH, in our main solution, where the data file is several Gb, it takes 15 minutes to swap out the interface file, vs. the many hours it would take to import data. This enables us to roll out new features and fixes every couple of weeks with minimal pain.

                   

                  You do have to take care when adding new fields: if the internal IDs get out of sync in the live vs. dev. data files, your scripts, layouts, value lists etc. will point to the wrong fields!

                  • 7. Re: Multifile solutions design in FM
                    jurijn

                    I ckeck this thread, forums on FM and google.
                    Thanks!

                    • 8. Re: Multifile solutions design in FM
                      beverly

                      Yep this indeed a 'correct answer'! I just wanted to add my experience with separation. I work with web design and it's the ultimate separation model - the interface is disconnected from the data. This makes it easy enough for me to also think of ways (and whys) to separate FM interface and data. My own experience with FM separation stemmed from clients needing to have a complex interface on the remote desktops and the data on the FM server. This indeed improved speed, as the interface elements did not need to travel in the ether, only the data. Yes, you do need to think slightly differently with this method. It mostly depends on what and why you want to.

                      • 9. Re: Multifile solutions design in FM
                        Mike_Mitchell

                        Beverly -

                         

                        Just out of curiosity, how do you deal with the "File X could not be found" issue when you have the interface local?

                         

                        Mike

                        • 10. Re: Multifile solutions design in FM
                          jgalt

                          When you guys implement these multi-file (20+ user) solutions how are you managing users and permissions?

                          • 11. Re: Multifile solutions design in FM
                            beverly

                            If there is a connection error (because of remote), Mike, then there would be a connection error whether it's separated or not. i.e. all files on the server can give the error when remotely connecting.  If the dialog comes up "... could not be found", the user knows that there is no connection.

                             

                            BTW: we tried a 'sync' before coming up with the separation. It was a nightmare. Semi-infrequent non-connections were a welcome trade-off.

                             

                            This solution can be on laptop or iPad, as well, though the iPad tends to have more frequent non-connection issues.

                            • 12. Re: Multifile solutions design in FM
                              wimdecorte

                              You really only have two choices:

                               

                              - native FM accounts: for that "Security Administrator" from New Millennium is a very handy tool

                              - or use External Authentication (my preference); that leaves all account mgmt outside of FM

                               

                              EA of course will not work if you keep the UI file locally.

                              • 13. Re: Multifile solutions design in FM
                                Mike_Mitchell

                                No, that's not what I meant. If your interface file is local and your data file is hosted, the host could be down but the interface file still accessible. User loses connection. Gets a bunch of "" indicators. How do you deal with that?

                                 

                                Also, you can get the situation where the user points the interface file back to itself when prompted to locate the file. That breaks the file pointer.

                                 

                                We've tried various solutions. Some work better than others, depending on the skill level of the users. Was curious how you do it.

                                • 14. Re: Multifile solutions design in FM
                                  beverly

                                  Yes, I knew what you meant, Mike! I'm pointing out that you will get non-connection errors when dealing with remotely accessed files whether you use separation or not.

                                   

                                  Don't let them select a file to munge the file reference!

                                  Beverly

                                  1 2 Previous Next