3 Replies Latest reply on Dec 5, 2012 2:16 PM by philmodjunk

    Development workflow



      Development workflow


           So for my first DB update, I copied the current FM file being used by our company and developed on a local version on my notebook.  After completeing my updates, I imported all the records from our company DB (obviously while nobody was using it) and deployed.  Key item: I left the Perform auto-enter options on import unchecked.

           2 Questions to go with this:

           1) Is this a good way to do it?  We only have maybe 10 or so tables and importing to each one individually wasn't all that bad but if there is a better way to do updates, I'm all ears.

           2) One issue I ran across: in a few tables (ones dedicated to be line items for parent tables via a portal mostly), the auto generated serial PK ended up entering duplicate values.  What happened was lets say a certain table left off with a PK of 898 at the time that I copied a local version over to my notebook.  Well, after a little while of development time and such, by the time I had deployed, the company DB had entered more of those, lets say getting up to a PK 925.  Problem is that the counter in my DB said the next value would be 899 and thus once I imported all the records from the company DB and deployed, it started duplicating values from 899-925.  Other than checking each table on import after a deveopment cycle and ensuring all next values are clear of what's already been entered, is there any other solution? (I've already ensured this won't happen again by checking the 'unique' validation criteria)

        • 1. Re: Development workflow

               There are two "better ways" that you can consider and they are not mutually exclusive.

               1) script the import process. This makes sure that every record of every table is successfully imported without omitting some records or a table. In this script, include code to update the Next serial value settings of any PK fields. Take a look at the GetNextSerialValue function and the Set Next Serial Value script step to see how you might do this from a script.

               2) reduce your data imports by using the Convert to Seperation Model. This design puts all your data in one file and your interface (Layouts, value lists, scripts, etc.) in another file. Since many design update only change the interface, you can avoid any imports in those cases just by replacing the existing interface file with the new version.

          • 2. Re: Development workflow

                 I like the idea of doing the data separation model.  Is this how most FMP databases are deployed?

            • 3. Re: Development workflow

                   I have no idea. Probably not. Much depends on the size of the user base and the level of complexity to your design as to whether or not it is worth it.

                   Be careful of any security settings--especially record level access control schemes that you employ with this model. Scripts set to run "with full access permission" don't when run from the interface file to modify data in the data file. Other means for "unlocking" the data temporarily have to be employed.