When working with the separation model, is there a benefit to having the UI file local as opposed to hosted?
Sure. Not a big fan of it myself for the obvious deployment and security hassles but it can make things faster.
If you do have performance issues and looking at this as a cure; I would personally try to tackle those in the design of the solution before I decide to deploy the UI locally.
Note that your parent file does not have to be a separation model to deliver separation model GUIs to others. You can create user specific GUIs that access only certain areas of the main file. Leaving the main file intact as one solves a lot of issues that keep developers from using the separation model.
Since these GUIs will be password protected, you can kill them simply by deleting their privilege set or account from the main file. At least off the cuff I think that would work. You should test this as once delivered, they can't be recalled.
Another trick is to limit password access to a specific computer, specific network, time of day, etc. These features would be verified after the login. The question is how to use this information when the GUI is doing the work? Maybe a PSOS to check the identity and return a value used by Get(scriptresult)? Or a table to handle verified login data?
Thanks to you both. Some additional information, I'm in the planning phase of re-writing a large solution. I had made some assumptions (turns out to be incorrect) regarding where the GUI file should live. To your point wimdecorte, performance is a concern here but it's 90% a result of the current design and ~10% a result of the version of FM they have employed. Both issues will be corrected shortly so I think I'll avoid the security and deployment headaches with a host GUI.
The two file method can be an annoyance when you have to go to the table half to add fields, create TOs, etc and the script half to do scripts.
Using one file as the hosted file eliminates these problems. The second half can be created separately and work just as if you started with two parts.
The annoyance factor can go the other way. It's not any harder to make schema changes in a "separated" data file than in an all-in-one file. But it is more annoying to have to import into data tables, when it's the interface that has the most changes.
I found that trying to add fields to a table or tables to the data part required opening a window to that file. In other words to edit the portions of either of the tables, you have to have that table open in the front most window. Not a big deal but I always had the wrong window frontmost...
The next question is how do this work with GO? I think a separation model file would confuse GO owners who use it locally.
The main benefit of separation aside from local WAN speed is that you can spend time reworking a UI and it is easy deploy (without touching the data file). If you have data that needs to be accessible by employees or an outside service 24/7 then separation is a good idea.
I use separation for UI elements like images and it is especially useful for Go when managing many large images. A few different variations of this. One is to have a launch layout file that only holds images and the datafile references back to those images when they are needed most of the UI is still from the Data file. Another is to not have any UI in the Data file.
It is a case by case situation but I generally do something where I keep local image thumbnails in the UI file and they are downloaded and stored in the UI file as needed from the data file. When a record is opened it compares the modify stamp or version number of the image in the UI to the one in the data file and if a new on is available it is updated in the local UI. Full size images are always pulled from the data file and never stored in the UI. clients seem to be pretty happy with the performance. Transferring 2GB of thumbnails every time the file was opened was not a good idea.
Using the iOS SDK with a 3 file solution (launcher, UI and data) is a something I have been thinking of using in regular FM solutions.
I should think that those coming from OLD FM (one table per database/file) would not have a problem being in the correct file to make changes to the schema.
beverly wrote: I should think that those coming from OLD FM (one table per database/file) would not have a problem being in the correct file to make changes to the schema.
I would think so! What problems are you having that I could help you with?
bigtom wrote: The main benefit of separation aside from local WAN speed is that you can spend time reworking a UI and it is easy deploy (without touching the data file). If you have data that needs to be accessible by employees or an outside service 24/7 then separation is a good idea.
I have mentioned several times the benefits of having a separate dedicated GUI file for various privilege sets and how eliminating access to booking data for sales, warehouse, etc. is a good idea.
I've also pointed out how a separate GUI file can be made for a one file hosted file even when it is not a data separation type.
If it is a single person file, the benefits are less of course.
Unfortunately, the answer to your question, Jack:
What problems are you having that I could help you with?
has been copywrited and only bigtom can told.
lol...I don't think it was bev who revealed they had a problem being in the correct file.
As wimdecorte mentioned, it could speed up the solution, but unfortunately it can't use external authentication what held me back of using it.
You've copyrighted your problems? Wow...
I was thinking of patenting mine... Then I could sue everyone who experiences the same problem and asks for help.
External authentication is one of the reasons we've decided to go with a hosted GUI file. To give a brief history, I'm working on a solution that's been in use since ~FM8. It's been worked on by various developers of varying skill levels. We've decided on the separation model for when the re-write actually begins.
Retrieving data ...