Any reason to upgrade to FMS12?

[fseipel]

I tried to search the forum but didn't see anything on this.

Have the underlying problems in the DB engine been corrected? Is it necessary to recover files every few months with FMS12 to improve speed or deal with corrupted records? It appears there is still no provision for command line recovery or control. I've read through the specs and a few reviews but they did not seem to address these issues.

[Wim Decorte]

euh... it's never been necessary to recover files to get more speed... not sure where you got that idea? I also haven't heard about FMS12 corrupting records.

Regular maintenance like compacting the files has always been a good idea, that hasn't changed with 12.

Some performance issues were tackled with FMS12v2, some users report that the speed is still not what it was in 11 but it seems to be very solution specific. So the only way to know is to test your solution.

[fseipel]

Thanks for the response, currently we recover and compact files about once every month. My admittedly cursory review of FMS12 (I have not downloaded an eval version) seems to indicate one still can't do either of these functions from the server, and that they can't be automated via the command line? I've read about the speed issues with the client but my concerns lies more with the server. Unfortunately it's a bit awkward to try it due to the file format change. I guess I should re-phrase my question then, are you finding you need to recover/compact more frequently, less frequently, or at the same frequency as with FMS11? BTW we're running FMS 11 and have it set to issue the e-mails if it detects problems with the hosted DB's.

[Wim Decorte]

Recover is not a good maintenance practice.

Save as Compacted is, and it can be fully automated. There is not a simple/single command to do it but you can use the "save a copy as - compacted" script step, call it in each file of your solution from the main file. The tricky part is that you would have to use a copy of FMP on the server if your files are hosted. You would need to use the fmsadmin command line to unhost the files, then use OS-level scripting to open the files with FMP and call the script that does the compacting save, backup the old files, rename the compated files and use the fmsadmin command again to host the new files.

Needless to say this would require a lot of error trapping and handling to make sure that every step of the way is clean.

[2crabs]

I have recently tried to deploy FMS12 (32 bit/Windows) on a converted FM11 app. The results are very disappointing. Put simply, processes are taking twice as long as before. When users move from FM11 to FM12 (just clients) and we benchmark our app on both, again the results are poor. Our application is quite calculation intensive (a costing model). Before we abandon FM12 entirely, does anyone have suggestions as to what we might do to either improve performance or identify the problem(s)? Also, has anyone else converted with similar (unacceptable) results?

Regards,

Will

[liltbrockie]

I have recently tried to deploy FMS12 (32 bit/Windows) on a converted FM11 app. The results are very disappointing. Put simply, processes are taking twice as long as before. When users move from FM11 to FM12 (just clients) and we benchmark our app on both, again the results are poor. Our application is quite calculation intensive (a costing model). Before we abandon FM12 entirely, does anyone have suggestions as to what we might do to either improve performance or identify the problem(s)? Also, has anyone else converted with similar (unacceptable) results?

Regards,

Will

Are you on FM12v2?

[Wim Decorte]

I have recently tried to deploy FMS12 (32 bit/Windows) on a converted FM11 app. The results are very disappointing.

Hi Will, try to post your issue as a separate post since it doesn't add to the this thread. You may get more traction that way.

As to your issue: as I've mentioned in this thread, slowdowns seem to be very solution specific. Are you on v2 of FM12?