Updating Runtime Solution without Loss of Data

[Vandy]

I am new to this forum and posting for the first time. I just upgraded to FM Pro 13 Advanced from Filemaker Pro 11 and am a very novice user. I have created a number of databases for my own use that I use locally on my computer and have been successful at getting things to work as I want for the most part (although probably not in the most efficient manner).

 

Now, on to my issue. My daughter-in-law wanted to track her customers in the business she works at and I created a small database (3 Tables) that does that. In order for me to allow her to use it I upgraded to the Advanced version to use the Runtime application. My understanding of this is very basic but I did successfully get it to work and I simply copied the folders from my computer to hers and it does what we want. After using it she has requested I add fields to track additional information which I did on my “original” FM file along with modifying the layouts, and all works great. But.... how can I update the Runtime version for her with my design changes and capture the “real” data she has been entering?

 

Any guidance will be greatly appreciated. Thanks!

 

Bob

[Ocean West]

Automatic message

This topic has been moved from "FileMaker 13 Interface Features" to "Advanced & Developer Features".

[Ocean West]

In the runtime you created the files and it instructed you to choose an extension like .usr

 

these files are no different the .fmp12 files and these can be opened in FileMaker to make edits to the schema.

 

However you will need her to send you the files she has you then need to make the changes and then send them back to her moving them into the folder that is required by the RUNTIME engine. 

 

If you modified the schema on your original files and send them to her again then any data that she entered would not be preserved. 

[doughemi]

 you will need her to send you the files she has you then need to make the changes and then send them back to her moving them into the folder that is required by the RUNTIME engine. 

 

 

The files should be zipped to prevent possible corruption by the email (or other transmission) process.

[comment]

how can I update the Runtime version for her with my design changes and capture the “real” data she has been entering?

 

There are numerous paths you could pursue here. Given your self-declared skill level, I would suggest the following:

 

1. Get a copy of (only) the solution file used by your daughter-in-law;

2. Save a copy of your modified file as clone (no records);

3. Import the data from the received file into the clone (three imports, one for each table). In each table, set the serial number field to pick up from the last number imported;

4. Bind the cloned file to a runtime solution, using the same binding key as with the original file;

5. Pick the solution file from the runtime bundle and send it back.

 

Make sure to have a backup for each step. Naturally, your daughter-in-law has to cease operations for the duration.

 

 

I just upgraded to FM Pro 13 Advanced from Filemaker Pro 11

...

My daughter-in-law wanted to track her customers in the business she works at and I created a small database (3 Tables) that does that.

 

 

Note that we are assuming here that both files are made with the same version. If you made the file for her in version 11, and now have improved your copy using version 13, that's another story.

[Vandy]

There are numerous paths you could pursue here. Given your self-declared skill level, I would suggest the following:

 

1. Get a copy of (only) the solution file used by your daughter-in-law;

2. Save a copy of your modified file as clone (no records);

3. Import the data from the received file into the clone (three imports, one for each table). In each table, set the serial number field to pick up from the last number imported;

4. Bind the cloned file to a runtime solution, using the same binding key as with the original file;

5. Pick the solution file from the runtime bundle and send it back.

 

Make sure to have a backup for each step. Naturally, your daughter-in-law has to cease operations for the duration.

 

 

 

Note that we are assuming here that both files are made with the same version. If you made the file for her in version 11, and now have improved your copy using version 13, that's another story.

Thank you for the directions. All went well and the Runtime solution my daughter-in-law has is now updated just as we wanted. The process was actually very simple and quick to perform (once you told me how).

 

Doing this for one or two copies of the same database would be no problem, but I imagine there is a more automated method for updating on a larger scale. I purchased a fairly decent manual for version 11 and have used it to answer many of my questions, but it is does not provide much on this subject. Do you have any suggested sources that I could use to help me dig a little deeper into this area?

 

Thanks again for your help!

Bob

[comment]

Doing this for one or two copies of the same database would be no problem, but I imagine there is a more automated method for updating on a larger scale.

 

Actually, this is one of the thornier issues in Filemaker and subject to numerous threads here. IOW, there is no really good solution to the problem. You try to automate the process as much as possible, so that the update can be done by the client clicking a button - but you must have left some "hooks" in the older version in order for this to work.

 

It's also convenient to split the data and the user interface into two separate flies. Thus some upgrades are possible by simply swapping the UI file. But not if the upgrade requires adding/changing a calculation field, for example. Complete separation of data and logic is not (yet?) possible in Filemaker.

[Vandy]

Actually, this is one of the thornier issues in Filemaker and subject to numerous threads here. IOW, there is no really good solution to the problem. You try to automate the process as much as possible, so that the update can be done by the client clicking a button - but you must have left some "hooks" in the older version in order for this to work.

 

It's also convenient to split the data and the user interface into two separate flies. Thus some upgrades are possible by simply swapping the UI file. But not if the upgrade requires adding/changing a calculation field, for example. Complete separation of data and logic is not (yet?) possible in Filemaker.

Thank you for the response. I will continue to use the method you provided and let the automation method sit for awhile and maybe by the time I actually would need it Filemaker may have improved the process. Procrastination may actually pay off for me here!

[Ocean West]

Actually, this is one of the thornier issues in Filemaker and subject to numerous threads here

 

 

Hey comment, I have been saying this for years - even apart from runtime solutions, any vertical market solution distributed the "upgrade process" to get dozens of different clients upgraded to a new patched or improved version of a solution is not something to be done on the whim.  I have lost so many evenings and weekends because that is the "only time" they seem to be able to make the upgrade is when all the staff are away. 

 

I have had a 17-30 GB solution with dozens of separate files that had all the hooks in place to import in to a new production version - but that required taking it offline and running in single user mode - if we started the process at 4:30 pm on a Friday it may have finished about 9PM on Sunday - provided there were no hiccups. 

 

The irony here is we have as developers have to move (import export)  gigabytes of data around - just to make a few hundred kilobits of changes ( layouts / scripts / schema ) - to me it makes no sense. On one project we tried to do the notes method by trying to map out by hand all the changes that were made so that when we roll up on site to make the changes to the files - and rinse and repeat that by however many clients need the patch - (then deal with the divergent client customizations)

 

Just wished FMP would have a true DIFF engine that could compare the difference and outline out a set of instructions that could be applied to the solution.

 

I know some have used SQL plugins to modify the schema to a solution ( probably not recommended ) but it still doesn't help with the other areas that require updating.

 

Just daydreaming - In FMP 13 I wonder if they could leverage the unlimited undos on layout changes and then log that so that could become procedural code to instruct an an executable solution upgraded to make the changes ( in addition to all the other needed bits)