Best Practice - Move Data or Move Development Changes?

[deego55]

Hi all. I have recently developed a massive upgrade to an existing database. This includes dozens of new scripts, new tables, new relationships, new layouts and tons of new fields.

We have completed system and user acceptance testing and are ready to move the changes into production.

I am not sure of the best method to do this? Would it make more sense to save a clone of the updated database and copy all of the data from the current database into the new file? I would want to eliminate all auto-update options, i believe. Are there big risks involved in doing this?

I was originally considering copying all of the changes over to the current file, but since there are so many, this seems risky?

Can anyone provide me with some insight? Thanks so much.

[Colin Keefe]

We sometimes build a separate upgrade file with TOs pointing to the new file's base tables, TOs for the old file's tables, and layouts for each base table in the new file.

A script walks through the tables, deleting old data, importing new, and updating serial #s.

Keeping it separate from the solution file makes it a bit easier to maintain, since you don't need to wade through a few hundred TOs to set up your import dialogs. When you add a new table during development, update your upgrader code at the same time - it'll take a just a few minutes to copy a few lines of code, and if there's any special logic for that table that needs to be taken into account, you can do it while it's fresh in your mind.

I'm sure you'll hear other methods here; I'm also curious what others do.

[Mikhail Edoshin]

Transferring data looks simpler to me. There are special tools to transfer data (i.e. import features) and a special option to turn off auto-enter when importing. If you need to transform data, you can do this with auxiliary tables. What's best is that you can script the whole process and test it several times before doing the final transfer.

If you want to replicate the changes in the file with data, even getting a full list of these changes is problematic. Many of these changes are interconnected and you need to apply them in certain order, e.g. if you copy & paste layout elements before scripts, buttons will get broken, etc. Moving code in FileMaker is generally a more complex way and it's all manual work with no possible automation.

[deego55]

thanks for responses. i ended up doing a data transfer. as Mikhail said, trying to move all the changes would have been a nightmare.

data was pretty simple to move. a couple of caveats:

- i had to reset the auto-serials on keys in the new file to account for records added since the dev file was taken down.

- if a user changed account password or new accounts were added in the time since dev file was copied, those changes werent reflected in the new file.

Overall, WAY easier than trying to migrate changes, with less risk.

[Mikhail Edoshin]

Another thing that needs attention are custom value lists with the “Edit…” command. That is users can change them, but there's no fully automatic way to preserve these changes.

To transfer accounts we decided to have a table for accounts (it also helps users to manage them) and store passwords there. When importing we re-create accounts in the new file with the new passwords.

[jjjjp]

How were you able to store passwords in a table? Aren't they inaccessible even to the administrator or to scripts? (I use FileMaker Pro 11.) Is this solution perhaps only possible with Advanced?