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.....
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.
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?
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.