5 Replies Latest reply on Mar 10, 2016 12:16 PM by mardikennedy

    FMS 14 Problems and Improvements - Windows environment

    mardikennedy

      Question asked with my 'corporate hat' on.  We are still running FMS 12 because we only get to have a server upgrade around every 2.5 to 3 years.  It would be nice to upgrade (software cost is negligible) but internal costings make it an expensive exercise requiring careful planning.

       

      Let's imagine that an upgrade could be scheduled any time from, say, late April 2016 on.  Our server hosts a wide range of solutions, each with a different user group, and users are spread across the continent.

       

      Is FMS 14.05 ready for a Windows-based production server?

       

      In a perfect world, we'd have a dev server available, but that's not going to happen until very close to 'switchover time', whenever that is.  In my ideal world, I would rather be doing this with an external hosting company because they tend to have deeper, richer experience with FMS than our IT department (who are specialists in a great many other things but not FMS).  That too is not likely to happen.  (They would also be much more flexible with updates/ upgrades.)

       

      Given the (bizarre) corporate pricing for WD relative to Pro, it is unlikely that we will use WD for the next multiple years, so the pros and cons of that element are not part of the decision.  (Why use a more expensive substitute? We have to get the (internal) installer built anyway, so there's also no install saving.)  Also, there is still no business justification for idevice usage, fun tho' that might be.  (We might get to a 10% usage in the next 12 - 24 months.)

       

      It'll all be about performance.  Most of our users currently have good experiences, a few locations excepted, exacerbated by specific solutions.  If there's a performance deterioration, there will be unhappy users.  How likely is this?

       

      Yes, I know that's a hard question.  Solutions come from various eras and thus, various architectures.  In the first instance, the v12 files will simply be migrated to the new server.  In the meantime, I am rewriting as many of the solutions as possible, to have proper v13+ styling.  The plan would be to shift the solutions to the new server first, and then upgrade them, ie migrate the data etc, perhaps within the next month.

       

      I think it's an option to do the client rollout ahead of the server upgrade, yes?  ie FMP 14 client accessing FMS 12 hosted files?

       

      Are the main problems sorted now - jumping script steps, portal sort crashes?  Any other show stoppers?

       

      Or, should we just keep 'hanging in' for another six months?  With the plan to review the options then?

        • 1. Re: FMS 14 Problems and Improvements - Windows environment
          mardikennedy

          Does anyone want to endorse FMS 14 in a (reasonably complex) production environment?

           

          Or counsel against it?

           

          I'm guessing that ??? 25% of FMS sites have shifted to v14; it sounds as if there are still a lot of 13/12 etc sites out there.

          • 2. Re: FMS 14 Problems and Improvements - Windows environment
            mardikennedy

            I think we just found the 'show stopper' in a Windows environment - 32 bit/ 64 bit incompatibilities with Outlook.

             

            Background:  the network has several thousand workstations (WSs), of which less than 10% have FMP installed.  At the corporate level, the 32 bit version of Outlook is currently deployed although there's an intention to migrate to the 64 bit/ Office 365.  This does not yet have a firm schedule and would probably take some time to implement.  Corollary:  FMP is a winnow in the bigger corporate picture.

             

            If we rolled out FMP 14 now, it would have to be the 32 bit version, but as soon as the 64 bit Outlook is rolled out, the WS would need a new FMP 14 install (or live with Send Mail steps no longer functioning).  Compounding the logistical complications, each of the FMP installers has a significant internal cost, so having two rather than one adds considerably to the overall project expense.  (If only it was like FMP - one installer (profile) that said : if Outlook 64 bit, install FMP 64 bit, etc.)

             

            At this stage, I think it will probably be practical (albeit frustrating) to wait until the Outlook upgrade has been rolled out.  If we'd realised a couple of years back that this situation would arise, it would (with the benefit of 20/20 hindsight) have been more cost effective to have had a VLA rather than an AVLA, but 'logically', the AVLA did seem like a good idea.

            • 3. Re: FMS 14 Problems and Improvements - Windows environment
              itraining

              Hi Mardi

               

              Big thumbs up from me. There have been a few (small) bumps in the road, upgrading to FileMaker Server/Pro 14. However, our experience is the upgrade has been TOTALLY worth it and none of our users want to go back to the previous version.

               

              We upgraded our big University system from FMP11 to FMP14 in September 2015.The system comprises:

              • just over 50 databases
              • file size ranging from 2 Mb to 13 Gb
              • tables range from 5 to 120
              • PHP custom web publishing used on 5 databases
              • users range from 200 staff (FMP)  to 7,000 students (web)

               

              Things move slowly at big universities. We were stuck on FMS/FMP11 but keen to upgrade to FMS/FMP12, then FMS/FMP13 and a little hesitant about FMS/FMP14.

               

              Finally our move to FMS/FMP14 was instigated by a disastrous forced move from our local Mac servers to a data center Windows Server for Semester 1. The IT is being centralised at the uni and we were no longer allowed to look after our own servers but no-one in IT considered the 4 Gb RAM limit of a 32 bit application running in Windows. In the peak period, the two weeks after examinations conclude, our database slowed to a crawl and pissed off every single user. Staff overtime went through the roof for the fortnight as reports took hours instead of minutes to complete. Reports that used to be slow, 4 hours to run, now took 24 hours to complete. It was a very real nightmare!

               

              Like every "good" catastrophe, it provided the impetus and motivation to upgrade and we migrated the system to FileMaker 14 over a single weekend.

               

              Performance-wise, the difference has been mind-blowing. Semester 2 was the smoothest semester EVER! At the end of the Semester 1 catastrophe, the staff were nearly at the point of lighting burning torches and forming a lynch mob. At the end of Semester 2, they were dropping into the office to personally thank us and asking the question: why didn't we upgrade earlier?

               

              Apart from the issues you mentioned, additional issues we have encountered are below. Please see the accompanying screenshots for clarification:

              • some layouts using Value is conditional formatting fail but changing to Formula is and using Self, corrected the issue
              • some calculation fields mysteriously changed from Calculation result is Text to Number

              Please note, the issues above were fine in the local converted databases but once uploaded to the server the change/problem manifested. It is only some layouts and a smaller selection of fields/labels with conditional formatting, the rest are fine. It is only a couple of calculation fields, the rest are fine.

               

               

              Hope this helps.

               

               

              Michael Richards

              Brisbane (Australia)

               

               

              Conditional Formatting - Value is.JPGCalculation Result - Text.JPG

              • 4. Re: FMS 14 Problems and Improvements - Windows environment
                wimdecorte

                mardikennedy wrote:

                 

                 

                Is FMS 14.05 ready for a Windows-based production server?

                 

                 

                Or, should we just keep 'hanging in' for another six months?  With the plan to review the options then?

                 

                The server itself is ready.  If you wait 6 months it is pretty much a given that there will be a new version out; it's been about a year since 14 was released.

                 

                Obviously the solution needs to be scrutinized and tested to see if it behaves well on 14; you've already identified some issues.  Personally I would upgrade the servers to 14 before the clients in your case.  FMS14 is faster and more stable than 12.

                • 5. Re: FMS 14 Problems and Improvements - Windows environment
                  mardikennedy

                  Hi Michael,

                   

                  Thank you so much for that excellent, real life, experience.  Environment is fairly similar to ours, which is even better!  We have a few more databases although our biggest is (only!) 7 or 8 GB.  We also do not have your 7,000 web (PHP/ custom) users (phew).  Roughly 200 FMP users, though rarely more than 40 or 50 simultaneously.  All up, a good comparison.  We've been running FMS 12 for about 2.5 yrs now and yes, the transition from 11 to 12 was smooth.  (In our case, 99.5% Windows.)

                   

                  We moved to an 'IT supported' server some years ago so our server access has limits.  In our case, the 32 bit/ 64 bit thing appears to be internally complicated.  The intention was to shift all Outlook users (thousands) to a 64 bit alternative however the alternative did not impress in the testing cycle, so the shift remains unscheduled.  In our environment, various user groups also use various apps/ custom legacy systems that further muddy the technical waters.  I'd temporarily forgotten FMP's SMTP options so I checked those out a bit yesterday but I don't think that's going to 'solve' things.

                   

                  Your input really helps,

                   

                  Regards,

                  Mardi