0 Replies Latest reply on Apr 5, 2016 10:31 AM by rickenbacker360

    Managed Container Storage – Upgrading a Solution and/or FM Server

    rickenbacker360

      Background:

      I have a LAN-deployed solution in fmp12 format (no FM Go or WebDirect). My commercial software version 1 ( v1 “FileName”) is a runtime solution from which [Full Access] is removed. (When deployed in a desktop LAN environment, of course, no runtime engine is used—it’s all straight FMP and FMS.)

       

      My solution has a document management feature using managed storage: External (Open). It uses [hosted location] at the default “RC_Data_FMS” directory with sub folders corresponding to the primary key of the document record’s parent. It has robust traps: If the solution is not hosted by FM Server, files cannot be inserted, nor can copies be opened or emailed. Likewise, document records (having container fields and their contents) cannot be deleted. In short, without being  a guest of FMS, the document management feature does little more than find and sort document records.

       

      When I release a newer version of the solution (still having the same, “FileName”), I have my users take FM Server Down (close the file using the FM Server Admin Console). Using FMP, users click the “Upgrade – Part 1” button from within the v1 “FileName” to create a separate file called “UP_FileName,” which is simply a compressed (smaller) copy. The script also does certain housekeeping chores, like setting globals for primary keys used to eventually reset serial numbers. At completion of this procedure, this “UP_” file is still located inside the (currently non-served) directory located at the default location on FMS. Of course, it could be at a different user-determined directory.

       

      Next, I have users create a folder containing the newer v2 “FileName” file. The user then manually moves the “UP_” file (so that it is no longer in the served directory) into this “New” folder, opens the v2 “FileName” using FM Pro and runs the “Upgrade – Part 2” procedure which imports all data into the correct tables and resets the serial numbers. When done, the user replaces (overwrites) the old v1 “FileName” file at the original served location on FMS.

       

      Finally, user deletes the “New” folder (now containing only the no-longer-needed “UP_” file), opens the v2 “FileName” file using FileMaker Server Admin Console and all is good… or is it?

       

      Questions:

      1. With this procedure, will all external connections to the “RC_Data_FMS” directory (and its sub-directories) survive the process and remain intact? In other words, will the v2 “FileName” document management records still point correctly to the “RC_Data_FMS” directory and its subdirectories?
      2. What can go wrong in my outlined procedure? This upgrade method has been in place for 20+ years and I’m hoping it’s as easy as I’ve outlined. I provide thorough documentation and only IT professionals do the procedure. Shoot a hole in it if you see one.
      3. I’ve thoroughly read the whitepaper, In-Depth Container Fields, by Susan Prosser and am unclear of best practices procedure for protecting “RC_Data_FMS” when upgrading FM Server. I’m trying to avoid any use of the “Save a copy as… self-contained (single file)” command. (Remember, my solution does not have [Full Access] so there’s no access to field definitions.

        I do know that the FMS Schedules feature saves the contents of the “RC_Data_FMS” but most often FMI wants FM Server Software removed from the machine, then the new version of FMS installed. What is a best practice I can tell my users who will occasionally need to upgrade FMS?
      4. Are there other land mines I should know about in either of these two procedures?

       

      Thanks!