9 Replies Latest reply on Nov 4, 2016 3:01 PM by jfletch

    1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea

    rchapelle

      I am new to FM. I have been asked to look at spitting a large file with 10 Tables into 10 Files each with 1 Table.

       

      My question is will I have to update the programs to direct a data call to a specific File/Table/Data Element when I split out the 10 Tables to reside in 10 Separate files or is this a function that FM will provide to the program automatically?

        • 1. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
          philmodjunk

          A more important question needs to be answered first:

           

          Why are you making this change--which will complicate your design in a number of ways.

           

          What problem is being solved by going back to a FileMaker 6 or earlier approach to data modeling?

          • 2. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
            rchapelle

            Thanks for your quick response - let me try to answer your very reasonable questions.

             

            While I have a technical background this is my first introduction to FM - first day. Making the 1/10 split to 10/10 split is my first task. My question was intended to know if someone had done this before and if so to gain general direction on the approach

             

            A more important question needs to be answered first:

             

            Why are you making this change--which will complicate your design in a number of ways.

             

            There is a contractor, his first FM project, that locally built the solution and now remotely supports the solution. While implemented and in production there are still changes that need to be made. The process has both the end users and the programmer working on the same set of programs and tables simultaneously which I am told reside collectively in the same file, which is  preventing individual programs/tables from being updated directly. The owner is uncomfortable with this set up and wants the tables set apart as individuals - each in its own file based on the contractors input, additionally that he cannot update individual tables under the current configuration - 1 File with many tables/programs.With this separation the owner feels he will have less risk with this new configuration.

             

            My suggestion was to have a production and test set of data/programs and once tested and approved, copy the changes into the production set - contractor says that cannot be done

             

            I would like to ask you if possible:

            * to list a few of the major design problems

            * Does FM compile the source code into machine code for files/tables/programs

             

            My apologies the nature of these questions.

             

            I appreciate your time and consideration in this matter.

             

            Rich

            • 3. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
              Markus Schneider

              There is no predefined task for splitting tables into files.

               

              There are some points for separate files (ie more than one developer who is working on that, different modules shiped seprarately for whatever reason, no dependencies, etc.)

               

              Maybe the easiest way would be to duplicate the whole file and delete non wanted objects - so, layouts, etc. will remain.

              Depends on Your needs. As Phil mentioned, there is not really a need for separate files - but under some circumstances, might be desirable...

              (-:

              • 4. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
                beverly

                as with the other answers, I'd question

                a) why?

                 

                b) do you need just the data tables?

                     If so, then just export each table as FileMaker type and save the export by whatever name you need. This preserves the data and field (names & types). It does NOT, however preserve the calculation of fields. Calculation & summary fields just export the current values in them at the time of export and not the options to create the data. (calculated result of 'text' becomes a text field upon export, for example, with the current calculation evaluated)

                 

                this also does not preserve layouts and scripts and value-lists and ....

                 

                hth,

                beverly

                • 5. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
                  jfletch

                  rchapelle wrote:

                  The process has both the end users and the programmer working on the same set of programs and tables simultaneously which I am told reside collectively in the same file, which is preventing individual programs/tables from being updated directly.

                  Not entirely true. If the file is hosted correctly, multiple people can work on the file at the same time. It is true, however, that only one person can be in Manage Database at the same time, but how much time do multiple people need to do that? I have not found it to be that big a deal in multi-developer environments. If it does become a problem, work out a schedule for who gets to be in the schema when.

                   

                  Also, the first reason why you don't want to split the files is because your security will be much more difficult. Unless you use external authentication, every login will have to be replicated in each of the files. New user? Okay, you get to enter their account setup 10 times! Not fun.

                  • 6. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
                    beverly

                    Ah! good "why", Rich. I used the method I described for going from 1 file into multiple "Data Files" (but not one for each table). I grouped the tables by tasks that made sense for the client and evenly distributed the storage load. Then I went with an entirely new "interface file" that used the data files by referencing them on the Relationship Graph.

                     

                    The logins is one caveat to having many files. Hosting is another - especially if you host externally and pay-by-file.

                    beverly

                    • 7. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
                      coherentkris

                      First consideration is that their is a contractor involved who has little experience (first project ...as you said).

                      If I was the contractor and you started making changes to stuff I built I would stop work soon as I detected it and call a meeting to discuss.

                      I would never allow myself, as a contractor, to become responsible for your work unless their was some kind of mentorship going on.

                      What if you do something destructive and their is no way to prove who did it?

                       

                      Top Gun Highway to the Dangerzone - YouTube

                       

                      In a multi developer environment the left hand must know what the right hand is doing.

                      Its a recipe for disaster and increase in development cost.

                       

                      I would seriously consider bailing on this project if i were you with one day of FM experience.

                      Especially if the guy who's giving technical direction is NOT an FMP/RDBMS expert.

                       

                      The development choices need to be carefully considered and all of direction guy's concerns need to be addressed before refactoring.

                      Mistakes you make now will come back to haunt you.

                       

                      Setting up a separate development/staging/production environments with FM is a serious undertaking.

                      • 8. Re: 1 File with multiple tables (1 to 10) split them out into 10 files with 1 table ea
                        philmodjunk

                        My suggestion was to have a production and test set of data/programs and once tested and approved, copy the changes into the production set - contractor says that cannot be done

                        This statement by the contractor isn't really true if you have quoted them correctly. We routinely work out new design changes in a separate copy of the DB and then, when satisfied with the changes, move the design changes into the production copy of the database.

                         

                        Script steps, calculations, new field definitions, new or modified layout objects can all be copied from the development system and pasted into the production copy. This does have to be done with care and some changes--particularly those that modify tables and fields via Manage | Database we do at a time when we've briefly taken the DB offline for such maintenance upgrades.

                         

                        Some design changes, value lists and new relationships come to mind, are not as easily replicated from one copy of the file to another, but it can be done.

                         

                        All such changes, do need to be done with care and both with documentation that documents the change and in a way that makes reverting a change quick and easy to do where/when possible in order to make such transitions as smooth and safe as possible.