Here is the method that I used:
If you are using the data separation model, use the version 12 interface file (.fmpur) to convert your users' runtime data files (.USR) to verson 12 (.fmpur) and then run the backup-scripts to create .fmp12 files. Next, restore their backup files (.fmp12) into a new clone data file (.fmpur) using the import-scripts.
If you are not using the data separation model, consider creating a small runtime (.fmpur) to do the same things.
The runtime files (.fmpur and .USR) must use the same bind key.
too bad that the FM12 runtime cannot convert fp7 files on its own. You can only
- provide the conversion as a service
- tell people how to do it with a FM PRO demo or
- provide an export/import path (with loosing graphics and formatted text).
thanks for your suggestion, but I seem to fail to understand it.
Did you mean I should not open my backup file (.fp7) but the .USR file of my previous runtime version?
I made my new runtime with a script step selecting the old user file that was part of my previous runtime with the same binding code and file extensions.fmpur
It starts to convert but then reports an error (database damaged).
I don't know how to really solve this...
Yes, we have successfully converted the runtime file_name.USR to file_name.fmpur using the scriptstep: Convert File[no dialog; "file:….USR"]. We do not open the old runtime.USR; we convert the file.
After it is converted, we run the backup-scripts on the converted file_name.fmpur that export the tables as .fmp12 files. We do this because the schema on the file_name.fmpur was modified and we need to reload the data into the new schema.
We then restore the .fmp12 files by importing them into a clone file_name.fmpur using our import-scripts.
This process is automated and has worked successfully for several users at their remote sites without downloading an FMP demo. Since it uses .fmp12 files, all data, including graphics etc, is restored.
I now know where my attempt went wrong. My previous solution did not contain adminstrator access. When you take out the admin access the conversion stucks and reports an error.
I republished my pre12 runtime including admin rights and I could convert the .usr file.
But since all my clients have the version with no admin access in the runtime I think I have to offer the conversion as a service like intex suggested.
Thanks to all!
Did you try checking the "Run script with full access privileges" checkbox at the bottom of the script?
Yes. But it only works if the admin privilegues are part of the "old" runtime. In my case, they are not, and this seems to prevent the conversion to run.
That's odd. The admin access was removed from both the "old" and "new" runtimes in my case.