From 360Works Product Documentation Wiki
Revision as of 20:22, 24 August 2017 by Jesse (Talk | contribs)

Jump to: navigation, search



360Deploy is a product aiming to simplify the tedious process of deploying a development database onto an existing production database. Developers working on a file can deploy changes made to their database structure at the click of a button while avoiding the downtime and labor traditionally associated with the process. All that is required is the use of our plug-in, some simple configuration, and click Deploy!

For a better understanding, consider the typical FileMaker file development scenario of a production and development server. The production server continuously hosts solutions for clients. The development/staging file is the database where alterations are being made by developers to enhance utility and better serve client's needs. Overhauling the old file to reflect the new one typically involves a process during which production is shut down and administrators sift through tables, scripts, and fields to reflect updates. We seek to bypass this arduous task by automating the entire series of events.

The entire process takes only as long as it takes to import data based on your database size, during which the databases are paused. This allows files to be updated without worrying about how often or when the changes occur. The set up consists of installing our plug-in in the FileMaker client running the deploy file, and some simple script copy/pasting.

Why use 360Deploy?

Altering live databases has traditionally been a tedious, intrusive task. It consists of server downtime and technical labor at the expense of company resources. 360Deploy is capable of doing that in minutes by seamlessly automating the process. What our software does is create a clone of the development database, transfers it to the production server, and then imports data from production into the clone to absorb the new architecture. As a safeguard, a back-up of the production file is also created on the machine before the imports occur should clients wish to revert back to the old structure.

  1. Ideal for frequent upgrades to a databases of any size
  2. Minimizes file downtime, only pausing file temporarily during import of data
  3. Drastically reduces complexity and time required to upgrade new database architecture
  4. Includes import of scripts and calculations
  5. Backs up production file in event changes want to be reverted


Setup involves a handful of steps to get 360Deploy ready. Start by opening the 360Deploy.fmp12 file. This will guide you through the setup process:

  1. (Optional) Store server log-in credentials for quicker processing. This will skip over password prompts during the import process.
  2. Populating IP addresses and account credentials for both servers.
  3. Copying and pasting of a script folder and generate scripts to the production layout

Required database changes

  • Databases should be password protected (required by default in FileMaker Server)
  • Have administrative credentials for both FileMaker servers
  • If the startup script does any write operations (i.e. Set Field or New Record), then either disable these script steps by commenting them out, or create a separate account for running the deploy operation and do not run these steps if running with this account. For example:

Screen Shot 2017-08-24 at 4.20.00 PM.png


Import hangs with no dialog on screen

This probably indicates that a startup script is halting the process. Add a section like the screenshot shown above at the top of the startup script to exit the startup script for automated deployments.

Import hangs with import dialog showing

If this occurs, try resuming the production database using FileMaker Server Admin Console. The production databases are normally paused during the import to prevent users from making changes (which will be lost if the import has already run for that table), but sometimes this can cause the import to hang. In our experience, this is usually a one-time problem: Resuming the database once seems to fix the problem permanently, even for future imports that are not manually resumed.

Personal tools

Plug-in Products
Other Products