The only application that can convert and create a FMP 12 Runtime is FMP12 Advanced.
The runtimes run databases, do not edit databases.
Runtime files are technically not "compiled" databases. They are standard FileMaker files that have been given a different file extension and "bound" to a "crippled" copy of the application file such that launching that copy of the application file opens the Database files that were bound to it.
Converting the files to .fmp12 format does not also produce the needed FMP 12 Crippled Copy of the application file nor does it "bind" the converted files to such an application file.
That "binding" process is what requires FileMaker 12 Advanced to accomplish.
David / Phil :
I understand that the "crippled" runtime apps are not databases. In my FMP 11 app distribution, I have several FP7 files which get turned into USR files. When I open each one of these same FP7 files in FMP 12, the conversion dialog box automatically opens up and offers the option of turning them into FMP12 files, which I choose. Then in FMP 12 app distribution, these same FMP12 files are turned into USR files. This is all well and good and understood by me.
The situation is this: the FMP 11 app I wrote is a commercially distributed program that has been sold to the general public since 2010. It's for screenplay writers and it makes copies of one of the distributed "blank template" USR (based on FP7 format) files to create individual user story files. Now I want to upgrade this app to run under FMP 12. I still have the distributed "blank template" USR (now based on FMP12 format) to create individual user stories, and that works as well as ever.
But here's the rub: I now have a sizable customer base using the FMP 11 product, each of whom has a created a slew of their own story files (each one of them a USR file based on FP7 format). So...when they upgrade to the FMP 12 version, they are definitely going to want to run their old story files under the new app. If each one of them actually had FMP 12 itself, they would be able to convert their FMP 11 USR files to be FMP 12 USR files merely by virtue of attempting to open them up in the new environment. But in actuality, all they'll have is the "crippled" FMP 12 runtime and when FMP 11 USR files are attempted to be opened under the FMP 12 runtime, all you get is a dialog box stating that the files need conversion and can't be opened, and then you are unceremoniously kicked out of the app at that point.
So...what I'm really asking here is: is the FMP 12 runtime app "crippled" enough so that it will never offer to convert the files like it does under the full FMP 12 development environment? I would sorely love to be able to have my existing customers upgrade to the new app and have their old FMP 11 USR files be converted on the fly to the new format and continue to use them under the new app. As it stands, I would have to have each customer e-mail me each of their FMP 11 USR files and then I would have to "perform" the conversion for them and send the converted files back to them.
So this posting is a last-ditch "question to the experts" as to whether this can actually be done using the FMP 12 Runtime app? It appears to me not to be the case, but I'm hoping against hope that there's something I've overlooked!
I would distribute a new empty runtime created in FMP12, then the user would import there data into the new file.
S Chamblee is on the right track.
I wrote an Automator (Upgrader) to do this for my distribution (which uses the separation model and has three .fmpur files). The UI file has the scripts to export and re-import the fmp12 files created. If you would like a copy of the automator to use as a starting point, send me a PM with your email address. In creating your version 12 runtime, you must use the same bind key as the version 11 runtime.
Here is the process overview:
The automated upgrade process consists of 2 steps:
- Step 1: Your database is converted and the Data saved.
- The database found in the Applications/”your_app_name” folder is renamed to “your_database copy.fmpur”.
- A copy of your existing database is moved into the Applications/”new_app_name” folder.
- That database is converted to the new structure.
- Your data is saved using the new structure.
- Step 2: The new schema is inserted and your Data restored.
- The new database schema is switched with the converted database.
- Your data is restored into the new database.
- The temporary files used to upgrade are moved to the trash.
The Upgrader handles 1a, 1b, 2a, and 2c above and opens “new_app_name” when needed. “new_app_name” does the others: 1c, 1d, and 2b.
Reply email sent…