Jump to content

Stopping the FileMaker Server

Recommended Posts

I may in the future be part of a shared database that would include two, possibly more, distinct databases, and I would like to have a better understanding of the limitations, if any. Currently, whenever I want to replace my database with an updated version, I stop the database, import the data into the new version, the replace the old version with the new one, and then restart the database. As part of a shared database, would I need to stop activity for all of the other databases on the server whenever I want to update mine? Or is there a way to replace my database without stopping the other databases from functioning?

Link to post
Share on other sites

Ideally you should consider using the Data Migration Tool or third party offering such as Otto. or 360 Works Deploy.

Doing manual imports you are bound to forget something - plus dependent on size it could take hours or days to complete.

The DMT was designed just for this purpose it moves the blocks where data is stored in to a clone of your file you won't have to remember to update serial numbers or other things that a straight import provides. 


Link to post
Share on other sites

Thanks for the information about how to migrate data without the risk and hassle of importing. I will definitely consider switching. My main concern at the moment is how to avoid having to stop the databases on the server every time I want to update to a new version and thereby interfering with the smooth operation of any other independent databases running on the same server. 

Are you saying that I can run Data Migration Tool to update to a new version without having to stop all of the databases sharing the server? 

Link to post
Share on other sites

All databases hosted on the server belong to the same organization. If you using your server for multi tenancy you might need to consult your license agreement.

The database that you wish to migrate with the tools mentioned before:

  1. Pauses development version
  2. Makes Clone of development file
  3. Kicks users in production version
  4. Closes production version
  5. Moves production version
  6. Performs migration production data > development Clone (renaming if necessary)
  7. Opens/Hosts new production version.
  8. Users then can resume access. ( you could kick off some script that emails or informs users system is available ) 


Link to post
Share on other sites

We would all be part of the same organization (a faculty within a university), and the databases would be administered by the same IT staff, but, functionally, there would be no need to stop the databases at once. Both databases would be relatively small without many users at any one time, and the code is fairly stable and so wouldn't need to be updated frequently. If all users need to be kicked out at once, we can probably accommodate that, but it's worth knowing what the options are ahead of time. Thanks for the help, Ocean.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.