Can anyone please confirm if a FM12 runtime solution can convert a FM11 file?
If not, can anyone recommend another way of doing this?
there seems to be a standalone converter for paying TechNet members, but I don´t know if you are allowed to give it away as a download for your customers if even normal not paying TechNetties aren´t allowed to get this thing.
Quite a disaster for Runtime-solutions-builders - we offer the conversion as a costfree service for our customers.
The runtime engine can convert a fmp7 file to fmp12 format if run with full access privelages, ie via a script. At least from my brief test, unless I am missing something?
I created a script containing:
[x] run script with full access privelages
I then deployed it as a runtime, removing admin privelages from the database.
After seleecting an 11 fp7 file, the conversion completed and the import dialog opened showing the records, although I didnt import, its clear that the runtime could converted the file.
I also set the bind key, extension and name matching that of the original 11 runtime, although aside from the bind key, im not sure the others make any difference.
well, shoot! I did not even see the script step Convert File!
sorry, just built a test runtime with one field and one script with only the convert script step in it - full priviledges granted
I can open a fp7 file, but then I get
could not open file, because it is not part of the solution
That sounds resonable, because the old file of the old solution of course is no part of the new solution.
Same binding key and extension for old FM7 and new FM12 solution doesn´t seem to be a good idea in my eyes.
Yes, I get that when it converts, it creates a new fmp12 file, which is sort of ok, because then I can import data from the converted file, into another runtime file anyway, which is sort of what I'm aiming for. I can convert the old runtime file with the new runtime application and then run a script in my new runtime that looks for the "converted" file within the same directory... then import from this file. I think it might work for me, thanks again!
but the file isn´t converted - the new renamed file is still in the old format ...
ok, I get you now. I wonder if it makes any difference if you specify Filetype = All available within the convert file dialogue...?
not to my experience
Weirdness, I just tried this myself and although I do get the message that the file can not be opened because it is not part of the solution, yet there are two interesting things here:
1. I'm not aksing it to be opened, just asking to convert it. and
2. The file IS actually created, but not converted. REALISATION, this script step is NOT compatible with bound solutions!
that´s what I said right in the beginning - it is NOT working. :-(
Very strange, its not what I am seeing.
I just tried again ensuring that the original file is a bound runtime file (with admin removed) and not an unbound file, lots of those on this machine anyway, it is a runtime file..
In the new bound 12 runtime, the script (as above) runs through fine.
After selecting the old file and setting a new name for the converted file, the lengthy conversion process begins, complete with a conversion.log..
The file is 100% being converted to fmp12 format and not just being copied / renamed and un-touched. After the runtime conversion, I can also open it directly in Pro Advanced 12 without further conversion (as I expected)
So, there has to be something preventing the conversion from proceeding.
I wonder if its something to do with with/without dialog or with/without a file reference options in the script step, since I used none for the test and manually selected the appropriate file.
P.S the name / extension was just for testing, ill try a few more tests my end to see if any changes cause it to fail as you are explaining.
I have no options activated in the convert script step too, I manually choose the file to convert.
I can´t take the same binding key and extension for old and new runtime, since that could bring up problems.
There is no conversion taking place, only the message
"could not open file, because it is not part of the solution"
appears, a new file is created though, but that is still fp7 format.
The bindkey is the problem. If I choose a different bind key, then I also get "The file cannot be opened because it does not belong to this solution"
A copy is made of the file, but it remains .fp7 and the conversion promptly aborts.
With the same bind key, it works.
Edit: Name / Extension / automated options (without dialog etc) have no effect, its just the bind key.
but with the same bind key people might get confused when trying to open files or determine with which runtime version what file has to be opened and can be opened. Different bind keys for different versions make much more sense than always using the same key.
Furthermore you can never convert any fp7 file from a runtime, no chance for building a multipurpose converter
I would only consider that a problem if you where to upgrade and leave the old legacy version active, which in itself could also cause confusion, such as one user adding records in the older version, whilst another adding in the newer version.
I have personally used the same bind key for the last 8 or more years in one of my solutions, which has undergone hundreds of updates including the version of FileMaker deployed in.
I guess the only time it could cause confusion would be if somebody tried to open the *edit: old* solution file itself by double clicking instead of the executable provided.
Of course, each and every solution / purpose is unique, so whilst it has never been an issue for me, I cant speak from your point of view...
Whilst on the subject though, I never did understand why FileMaker did not allow a "File > Import" to import data from an .fp7 file without having to convert, but I guess there where technical reasons.
we always change the binding key with every major update.
People regularly click the data file on Mac OS systems for starting the solution, because they are used to it and see the data file. On Windows it´s different, because people won´t find the data file too easy in c:\programs and aren´t used to search there. But most of our customers are Macies.
Furthermore we sell business solutions and just for tax regulations you have to keep your data available for ten years. So there is no chance for just deleting the old solution. And with many solutions we don´t import the old data, because it´s "old" data for the last fiscal year. It has to be kept as it is, but isn´t actively used any more.
So for us the script step "convert" just isn´t working as expected.
P.S: That FileMaker 12 can´t import fp7 file data is quite poor. Looks like they wanted to press people to the new format. Not every file should be converted to 12, you only need the data imported. You can do it with Text, Excel, SQL, ODBC, even Bento, but not with FileMaker 11. That is really strange.
I hope you dont mind me asking, but If you dont import old data into the new solution and dont remove the old solution, why you need to run a conversion on it in the first place? I thought the point of the conversion was to import the old data.
we did´nt want to convert the old files in the first place, but since their was no import option, the conversion would have been necessary.
Of couse we need part of the old data in the new version as for example preferences.
Retrieving data ...