3 Replies Latest reply on May 24, 2013 9:10 AM by philmodjunk

    Shared scripts and layouts across databases

    ArjenSchipmolder

      Title

      Shared scripts and layouts across databases

      Post

           Hi,

           I'm trying to make a multi-database system that keeps as much of the data separated from the interface as possible.

           That way I should be able to keep all scripts and layouts in one database and the actual data in other databases.

            

           To do this, I initially tried to create one database that would contain all layouts and scripts etc and then additional databases, one for each of our customers, to contain all data for that customer. The idea being that the user logs in and selects a customer. This in turn would display the data for that customer, as in "data from that customer's external database".

           This in itself worked ok, but it looks like it would require me to make individual layouts for each customer as well as the layouts are linked to one particular table (from the external database in this case) and can't be altered on runtime which isn't what I want as the layouts of all customers would be largely identical.

           Another problem I'm running into is that, althought the layout are styled identically, the fields used by each customer may differ slighly. As I understand it, layouts are static and I can't create a dynamic list of fields to display so that would be a problem as well.

            

           Alternatively, I thought i may be possible to do it the other way around, where each customer has it's own database with layouts for that customer and the user would open the database for the customer they want to view, but for all generic layouts (like headers, footers, etc) and scripts to be loaded from one centralised database. That way it would still allow me to keep all those consistent throughout all customers without having to change them all every time a change is made, but I haven't found any way of doing this yet so not sure if this is possible at all.

            

           I hope this makes any sense, but does anyone know how to make it work like this (if at all possible)?

            

           I'm currently running FM Pro Advanced 12 and the databases will all be shared via IWP on a FM 12 server as well.

            

           Thanks

           Arjen

            

        • 1. Re: Shared scripts and layouts across databases
          philmodjunk

               Please see this thread on what we refer to as the data separation method: Convert to Seperation Model

               Trying to put each customer's data in a separate file, but sharing the same copy of an interface file--the file with all your scripts and layouts won't work. But you can put all the customers' data into one single set of tables in a single data file and then there are a variety of ways that you can control which customer's data is accessible for a given user and which set of layouts in the interface file are to be used when viewing that data.

               

                    Another problem I'm running into is that, althought the layout are styled identically, the fields used by each customer may differ slighly.

               You may indeed need to either develop several layouts to handle the differences or you might have a tab control (The control itself can be invisible) where each panel contains slightly different layout design variations and a script can automatically select for the tab panel appropriate for a given customer.

          • 2. Re: Shared scripts and layouts across databases
            ArjenSchipmolder

                 Thanks Phil,

                 I was afraid you were going to say that, but your answer makes sense.

                 I've got a feeling I'll end up with individual databases for each customer after all and just have to manage updates to layouts and scripts manually. Not ideal but it'll work.

            • 3. Re: Shared scripts and layouts across databases
              philmodjunk

                   I see no major reason why maintaining separate database designs would be necessary and can make for a lot of duplication of effort.