ron G Posted May 5, 2012 Share Posted May 5, 2012 I developed an application under FM 11 Advanced. Then, I 'upgraded' to FM 12 Advanced. My application has an import script that allows the user to browse to a previous version and import the USR file data. It works under FM 11. However, when I run the same script under FM 12 and specify a FM 11 USR file I get an error message that the import can not take place because the USR file has not been converted to FM 12. That's fine for me but is a problem for my users. Question: "What are my users supposed to do to make their 'old' FM11 database tables 'acceptable' to FM 12? Surely FM has thought of this problem... Thanks Ron Link to comment Share on other sites More sharing options...
Ocean West Posted May 5, 2012 Share Posted May 5, 2012 drag & drop on to FMP12 to convert the data files first to convert it to FMP12 Link to comment Share on other sites More sharing options...
ron G Posted May 6, 2012 Author Share Posted May 6, 2012 drag & drop on to FMP12 to convert the data files first to convert it to FMP12 My 'users' don't have FMP 12. Their data files are created under FMP 11. Now what? Additional thoughts. When I compiled my application in FM 11 and would import records from a previous version of my app, I would import the .USR file. That worked great. Question: "Since the .USR is apparently the 'data' file, why did FM 12 get a different file format for just the .USR data file? Or, do I misconstrue what the .USR is? Link to comment Share on other sites More sharing options...
Wim Decorte Posted May 6, 2012 Share Posted May 6, 2012 the USR file in a runtime is pretty much a real .fp7 file. FM12 introduces a new file format so what you are trying to do is import an fp7 into fmp12 which doesn't work. You have to script an export from the usr file to any supported in-between format (csv, tab delimited,...) and import that into the new runtime. Or you can tell your users to download the trial version of fm12, use that to convert the usr file (not sure that this will work) and then your new runtime can import the converted file. Link to comment Share on other sites More sharing options...
ron G Posted May 6, 2012 Author Share Posted May 6, 2012 the USR file in a runtime is pretty much a real .fp7 file. FM12 introduces a new file format so what you are trying to do is import an fp7 into fmp12 which doesn't work. You have to script an export from the usr file to any supported in-between format (csv, tab delimited,...) and import that into the new runtime. Or you can tell your users to download the trial version of fm12, use that to convert the usr file (not sure that this will work) and then your new runtime can import the converted file. Hmmm... since the Export function is *NOT* part of the FM 11 application, that's out. Yep. It looks like users will have to either DL FMP12 and convert or send me their USR file and I will convert. Since FMP12 offers to convert a .fp7 file to fmp12, this situation begs the question "Why didn't FM build FMP12 WITH the conversion code as part of the runtime module?" Since they don't 'consult' me, I will probably never know... for sure.. Thanks for the input. Link to comment Share on other sites More sharing options...
JerrySalem Posted May 6, 2012 Share Posted May 6, 2012 Export is allowed in FM runtimes. What you may need to do is release a final FM 11 update to your application that will export all the tables to csv (or other format) to a known location. Then the users will have to open the Newest and Greatest FM12 version of your application and import the csv files from that known location. It is a little clunky but this worked for me when our run time when from 6 to 7. Link to comment Share on other sites More sharing options...
ron G Posted May 7, 2012 Author Share Posted May 7, 2012 Export is allowed in FM runtimes. What you may need to do is release a final FM 11 update to your application that will export all the tables to csv (or other format) to a known location. Then the users will have to open the Newest and Greatest FM12 version of your application and import the csv files from that known location. It is a little clunky but this worked for me when our run time when from 6 to 7. Wow. By *not* including the conversion 'engine' with the runtime engine FM sure makes life difficult for developers. The best case scenario is that I: a) create some export code that works with the 'old' version. rewrite my import code to recognize the exported files. c) But, if the import is from a FM 12 app, the import would be different so it too needs to be rewritten ... or d) Have my users email me their data file and I will 'convert it' and send it back... All this because FM chooses NOT to include the file conversion in the runtime engine. There must be a good reason for this but I don't see why choose not to include it.? Thanks for your ideas... You confirmed my 'worst case scenario'. :hmm: Link to comment Share on other sites More sharing options...
Newbies Gigigino Posted May 19, 2012 Newbies Share Posted May 19, 2012 I have exactly the same problem with my runtime. Although the conversion script function is available for a runtime, it does not work when the USR file is not recognized as belonging to the same runtime (it's unfortunately the case when it's a backup file) Link to comment Share on other sites More sharing options...
Newbies Gigigino Posted May 20, 2012 Newbies Share Posted May 20, 2012 Well, I have a solution... You can use the conversion function in a runtime but the file you want to convert must have been created with a runtime sharing the same binding key (Bindkey). 1 Link to comment Share on other sites More sharing options...
Vaughan Posted May 21, 2012 Share Posted May 21, 2012 That could be a very useful piece of information. Thanks for sharing it! Link to comment Share on other sites More sharing options...
ron G Posted May 22, 2012 Author Share Posted May 22, 2012 I have exactly the same problem with my runtime. Although the conversion script function is available for a runtime, it does not work when the USR file is not recognized as belonging to the same runtime (it's unfortunately the case when it's a backup file) What 'conversion script function' are you talking about? It seems to me that FM could include the Pro 'engine' code that allows a user to convert the previous version without having to know the binding key. After all, if you DL the FM demo, you don't need to know the 'binding key'. Or, am I missing something? Link to comment Share on other sites More sharing options...
Vaughan Posted May 22, 2012 Share Posted May 22, 2012 I just did a test with FMP 11 runtime (my preview of FMPA 12 just expired and I haven't got a full copy yet). All this is on Mac OS X. I made a runtime for some FMP 11 file I had lying around. Then got an old .fm5 file and dropped it on the runtime engine icon. The engine prompted to rename the file, performed the conversion, then complained that it could not open the file because it was not bound with the same key. However the converted file could be opened in FMP 11 client . So it appears that FMI have left the "conversion" engine in FMP 11 runtime. I'd be surprised if they removed it from FMP 12 runtime. FMP won't allow the runtime to use un-bound files because that's how they choose to make the runtime. However, all the developer needs to do is bind the new version with the same key as the old. Is that really such a hard thing to do? Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 4362 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now