4 Replies Latest reply on Aug 20, 2012 7:13 PM by fmpros

    Changing external references

    fmpros

      I've got an interface file that runs off of typical server files but also references files on the client side. Let's say the interface file is in directory "X". The external files have also been residing in X. But now I want to put the external files in a subdirectory X/Y. I have external references defined to the original external file position in X and I have TO's based on these file positions. If I just physically move the files to X/Y what will I have to do and in what order (to the external reference definitions and TO's) so as to not break anything? My brain is out of synch on this; I did it a couple of times and lost connection to referenced fields on layouts and even putting the files back into X didn't recover the connection.

       

      Thanks for any help,

       

      William

        • 1. Re: Changing external references
          wimdecorte

          I don't have an immediate answer for your question but I'm interested in learning your reasoning for having local files on each workstation.  For me that takes me back to my Access days.  One of the true powers of FM is that you can deploy your solution to a wide set of users without having having to deploy and maintain local files.

           

          Seems to me that there is a business requirement that can be handled differently.....

          • 2. Re: Changing external references
            fmpros

            Hi Wim, greatly enjoyed your talks in Miami.

             

            Actually, I completely agree with what you are saying and that's where I was a while back.  I am using a separation model and originally only had the interface file on the client.  I think that fear of speed issues led me to the current design (although I'm just starting this design so it will be easy to revert).  This is a medical app that relies heavily on reports.  Originally, all reports resided in one file on the server but I have separated them out into groups according to lab accreditation modules so that a "report pack" file holds only the reports associated with a particular medical subject.  This provides easier upgrading of a report design and allows us to sell the app as a modular system, i.e., a lab might only purchase the report pack for cerebrovascular or peripheral arterial rather than one price for all reports, which they may not need.  Since a report file holds no data, only layouts with pointers to the similarly modular data file (on the server) I felt that, speed issues being my bug-a-boo, I would put them also on the client. 

             

            Perhaps I'm not yet completely confident of the newer versions and it's capabilities as I'm rewriting the app from a big multi-file version 6 design.  I want reports to pop open briskly; perhaps this is not an issue to worry about.  And I agree I would rather have them all on the server for easier deployment.  So, I acquiesce and present this question: If speed issues are not an issue anymore, assuming users are running adequate hardware, is there an overwhelming reason to not also put the interface file on the server? I have originally felt that some issues in multi-user systems were solved by at least having the interface file on the client side.

             

            Thanks,

            William

            • 3. Re: Changing external references
              wimdecorte

              Glad you liked the devcon sessions.

               

              The speed issue is something to test before you change your deployment.  Purely from a risk consideration I would avoid having the files locally - makes hacking into the solution so much easier you can get your hands on the physical files.

               

              To answer your original question: I would create the subfolder and put a copy of the files there, then open the solution and change the file references that need changing.  Since the original files will still be where they always have been, the solution will open up fine without breaking anything, and changing the file reference will work because the new target files will be there too.

               

              On the subject of local files: I don't see what mult-user issues would be solved, the data files are still on the server right?  So you still have to cater for record locks in those tables.

              How do you do versionining?  Is there a script in the data files that prevents older versions of the interface file touching the data?

              • 4. Re: Changing external references
                fmpros

                Well, I setup a remote server account and tested what I think is a fairly "heavy" layout re the speed issue.  Can't tell the difference between remote speed and running it on my new iMac or under Windows.  So, since I agree with the security issues and certainly want the easiest deployment and versioning, I will opt for server side files.

                 

                This will be for our worst case scenario customers that have it installed locally on LAN.  For our online customers we run with TS servers and a FMS backend on Rackspace.  Terminal Services works so well and so fast I don't see having speed issues there (plus we control the hardware).  Additionally, using TS, I can run a full featured system on an iPad using PocketCloud, works great and not limited by iOS.

                 

                Thanks for the help Wim.

                 

                William