1 2 Previous Next 17 Replies Latest reply on May 28, 2017 5:02 AM by wimdecorte

    Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?

    TonyTrevisonno

      Hi FM community,

      I am working on a new solution in FM 16. I will have a data file and an interface file. I was planning on hosting both files on FM server but I am wondering if there is any benefit (or downside) to storing the interface file on the individual client machines. The reason I am wondering this is because I want to give the client users the ability to store personalized settings and customizations. For example, I want them to store various user defaults, color and layout settings, searches, flag records, store some local data, and probably other stuff too.

       

      I suppose I could host the interface on the server and store a local settings file locally, but then why not go all the way if there is a benefit.

       

      Any thoughts on this?

       

      Thanks.

        • 1. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
          beverly

          For the reasons that you listed, a separate Interface (on the desktop) is quite handy!

           

          If there are many interface elements at all (user defined or not), I've found it better to have the Interface on the desktop.

           

          Beverly

          • 2. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
            Jason Wood

            If you are going to be distributing regular updates to the interface file, this could make it difficult to deploy.

             

            Weigh that difficulty against storing user specific settings in a user table (based on account name), or a workstation table (based on persistent id).

            1 of 1 people found this helpful
            • 3. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
              bigtom

              Speed over slow WAN is the only good reason I see for doing this. You can do all the custom user setup hosted from the server just the same.

               

              Updating the interface file gets more complicated when it is local, but it is doable.

              • 4. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                William-Porter

                I was a devout member of the Church of TSM for years. If I needed to make a grocery list, I had a data file and a UI file. In 2016, I lost my faith. And it had a lot to do with this very question. I'm now building single-file EOTS ("Everything On The Server") solutions. Not 100% sure I'm doing the right thing, but I think so.

                 

                While I was developing my commercial solutions on the separation model, I distributed UI files for use locally, while hosting the data file on the server. It seemed obvious to me that some processing would thus occur locally and perhaps things would be a bit zippier, and indeed, I'd read claims that that is in fact the case. But "obvious" isn't same thing as "true" and I never noticed any significant improvement in having interface file stored locally. The performance problems occur mostly in getting data off the server, and that doesn't change when the UI is stored locally.

                 

                ---

                 

                And having the data file on the user's local device created two other problems, both of which made my users unhappy.

                 

                First, seemed to create more problems with connections. When everything is on the server, if there's an internet glitch of any sort between the client computer and the server, the solution simply won't open. Users will understand that there's a connectivity problem. But when the UI file is local, users had the feeling that the app was opening and then felt that the app was having problems. It wasn't the app at all: It was their internet connection preventing them from pulling data from the server, but the user is in the UI file, so when problems occur, he blames me rather than CISCO or Spectrum or whoever.

                 

                The other problem is kind of ironic. For me the big reason to use TSM is that it makes it easier for me to distribute updates. But it doesn't make things easier for my users. I distribute two vertical market solutions. I very seldom change the schema, so almost all of the changes are in the front-end file: layouts, scripts, etc. I can just put a new version of the front-end file on a server and distribute link to it to my users. Great for me. But it's a pain for users. Even if user only works on one computer, he or she still has to do a download and replace. And if users work on multiple computers and/or on iPhone or iPad, they have to update all those front-end files. In the end, I think it's more important for me to think of the the convenience of my users than my own convenience.

                 

                ---

                 

                So I stopped doing this in late 2016 and I'm working entirely on the "integration model" now (i.e. one-file solutions). Everything on the server. Getting better using PSoS, which is brilliant. WebDirect is also becoming more important and of course that requires having the UI on the server.

                 

                I don't know if I'll continue working this way. Perhaps I'll give up on WebDirect and if I do, I might go back to TSM, and if I do that I might reconsider client/server TSM (as opposed to everything on the server TSM).

                 

                One last point: I also give my users preferences. But I can't think of anything that can't be done with an integrated model solution. If you ask a more specific question about how to implement certain user preferences without using separation model, I'll try to respond and I'm sure others will too.

                 

                I'M NOT SAYING TSM IS WRONG. If it works for you, go for it. But it's no longer as clear to me that TSM is the bee's knees, as I once thought.

                 

                Will

                4 of 5 people found this helpful
                • 5. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                  bigtom

                  If the UI is advanced with a lot of images it makes a big difference. If

                  you are pulling images from the server it can be better to continually

                  copy new images and new versions to the local file.

                   

                  Moving data from the server is where the savings is.

                  • 6. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                    philmodjunk

                    "So I stopped doing this in late 2016 and I'm working entirely on the "integration model"...."

                     

                    So why not use data separation, but keep the UI file on the server? That keeps the update convenience for the developer but eliminates each of the problems that you cite for not using data separation.

                    • 7. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                      wimdecorte

                      Agreed with philmodjunk on this one.

                       

                      Too often I see confusion about TSM (The Data Separation Model) and where the actual files are stored/used form.

                       

                      TSM does not automatically mean that the UI file needs to be on the client's machine.  It can still be hosted.  In fact I almost never choose to deploy a UI file locally to the user's machine.

                      • 8. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                        beverly

                        The client where I use TSM the most is where the bulk of the work is in the field (literally). The Interface is in both places where office staff connect to the server and in the field via the "local copy". A huge difference in speed of access! Development is on the server hosted file. Copy of backup sent to download directory when significant changes have been made.

                         

                        Another client has the interface file only on server and it is Web Direct published. The layouts and functionality are significantly different from the in-office usage to make this a need.

                         

                        Other client solutions with TSM are only server based (no remote and no web access).

                        Beverly

                         

                        Sent from miPhone

                        • 9. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                          DavidZakary

                          This is assuming that the UI file also has your user data layouts in it.

                           

                          Downsides:

                          • You have to make sure that every user has the same version of the UI file, if not you could run into issues
                          • A local UI file would probably be more beneficial for a mature system that does not change often, a system with lots of changes will be a pain to manage
                          • Storing user settings on a server-based system isn't difficult, probably easier than the effort required for version checking a local file and downloading updated files
                          • If a user replaces a local UI file, they'll likely have just overwritten anything stored locally - unless you store everything as an external file which then imports... and you get more and more complexity and places for errors
                          • There are many discussions about the benefits (or lack of) to separated systems - search for them
                          • I use TSM often, my biggest complaints with it are having to duplicate components of the relationship graph, hitting the key commands for management functions but not being in the right file and account management across all the files

                           

                          I'd store everything in a user table on the server. Less management of versions and data integrity issues.

                          • 10. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                            TonyTrevisonno

                            Thanks for all the replies guys. I am not sure yet which way to go on this one but based on your replies I have a few things to think about.

                             

                            In regards to updating a local UI file, I have done this for another solution and it works really well. All the client machines are on the same network so I store the updated file on the server with a revision code on it. Then, I have the local UI file look to see if there is a more recent revision on the server everytime they open their local file. If there is, they are prompted to update their file. Click, and it automatically closes, replaces, and opens, the new file. It also imports the local settings tables. It's pretty straightforward and I have not seen or heard any issues with it.

                             

                            In this new solution, I have a table that builds a BOM on the fly when the user selects an item. If the table is hosted on the server, that table will we processing the BOMs for all the users simultaneously so I have to manage them with user IDs. I tested this out and it works fine -- but I don't like it. The table can get large and I worry about data conflicts.

                             

                            But, if the table is local per user, I don't have to manage multiple users in the table, but performance might be an issue because all the data is on the server. I have to test this out. Currently, with everything on the server, it is surprisingly fast, enough that I don't want to sacrifice a split second. I can build a BOM of 1000 records on the fly in around 5 seconds. A BOM of 100 records in 1 second. If doing this in a local table is slower, I will want to keep it on the server.

                            • 11. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                              bigtom

                              Each individual solution is different.

                               

                              I know you said you don't like it, but when I do something that way I manage by userID and a sessionID. Ran into an issue where a client started running multiple windows and userID alone was an issue.

                              • 12. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                                William-Porter

                                philmodjunk wrote:

                                 

                                "So I stopped doing this in late 2016 and I'm working entirely on the "integration model"...."

                                 

                                So why not use data separation, but keep the UI file on the server? That keeps the update convenience for the developer but eliminates each of the problems that you cite for not using data separation.

                                 

                                Ah, excellent question.

                                 

                                To the OP: I think my earlier points about the problems with placing UI file on the local machine are valid. That's all you asked about and perhaps all I should have responded to.

                                 

                                WARNING: I'm now going to talk about TSM more generally, to respond to philmodjunk's question to me. So the following is a digression and to those who hate digressions, I apologize in advance.

                                 

                                ---

                                 

                                 

                                For many many years I did exactly what philmodjunk suggests: data and UI file were together. I call that "single separation" TSM. Last year I tried switching to moving to "double separation" TSM, viz., UI file on client machine, data file on server, and I ran into the problems I described earlier. If I were smarter, at that point, I might have turned around and gone back to what I had been doing and given the matter more thought. Instead I kept searching for an alternative and the only one left was the fully-integrated/everything-in-one-file approach. This was a way of working I hadn't done for some years and it had a certain appeal. It makes it easier to manage accounts and passwords. And it allows me to take a hands-on approach to the schema, which is refreshing.

                                 

                                The schema problem presented by TSM perhaps deserves some explanation. My approach to TSM had been to over-define the data file, then try to leave it alone for at least a year. That is, I defined more tables than I expected to need and more fields in each table (usually something like 200) in each table. To the extent that I knew what I needed when I created (or a year later updated) the data file, I'd give the tables names (ACCOUNTS, CUSTOMERS, PRODUCTS, LINEITEMS, INVOICES, etc.), and of course I'd define as many of the fields as I could properly. But every database ended up with a lot of tables named something like UNUSEDTABLE23 that hadn't been used for anything yet; and every single table had fields with names like TEXTFIELDRESERVED Copy39 or DATEFIELDRESERVED Copy18. When I'd need a new field or a new table (as of course I did occasionally) I'd simply use one of those pre-defined "reserved" tables or fields in the UI file. If client asks me for a a field to store a person's eye color, I'd just plop the field TEXTFIELDRESERVED Copy41 on a layout and label it "Eye Color." Users wouldn't know the difference unless I gave them access to a sort dialog or a direct export dialog, which I try not to do. (Obviously this meant generally giving up the idea of creating new calc fields in the schema and relying on alternatives, but that was less of a hardship than some might think.)

                                 

                                The serious problem here wasn't giving up option of creating new calc fields. The serious problem was keeping track of every change made to the reserved tables and fields. I really tried hard to keep my master development files (data and UI both) apart from client files and to do development work only on the master files. This allowed me to rename tables and/or fields in the master data file as I needed. But despite my best efforts, occasionally, I got confused about what was the master data file. This would happen usually because something about a client's data was triggering a bug that I couldn't reproduce with my developer data set. When that happened, I'd look at the client file to see what was going on -- and sometimes I'd forget myself and fix the problem in the client's file. Bad bad bad, but it happened. So I had to track every change to master data file in an independent database that I could refer to if I ever ran into a problem (and I did run into problems). I carefully recorded every new table and/or field definition (e.g. so "changed TEXTFIELDRESERVED Copy41's name to Eye Color").

                                 

                                In short, TSM meant that I traded the big, occasional headache of performing updates for nearly daily small headaches working with tables and fields. For a while I thought that was a good trade. Then last year I changed my mind. This is why I've stuck with the integrated approach now for eight to ten months.

                                 

                                ---

                                 

                                In the meantime my response has been to create a fairly goof-proof update process: place empty new file and old file (containing data) into same folder, hit an "update" button, then come back 30-60 minutes later and upload the new file to server. Has the added benefit of providing a fresh copy of the file with every update.

                                 

                                That's where I am officially at the moment. Reserve the right to change my mind about all of this later this afternoon. :-)

                                 

                                Will

                                1 of 1 people found this helpful
                                • 13. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                                  philmodjunk

                                  The process that you use for updating your single file could be used to update just the data file and with data separation, you would need to use that option less often.

                                   

                                  Not all files will update in 30-60 minutes. Plus, your users must be blocked from data entry the entire time.

                                   

                                  That does leave the issue of a more complex security system when you have more than one file. Though this can be mitigated a bit with either scripts or external authentication.

                                   

                                  Please note that I fully agree that data separation does have drawbacks. It's not a panacea. But some of your reasons for not using it aren't ones that I agree with. Plus, the OP should consider data separation with the UI file on the server as an option. Your first post did not indicate that you were even aware of that as an option.

                                  • 14. Re: Is there a benefit to storing the interface file on the client machine instead of hosting it on the server?
                                    srzuch

                                    Several follow-up questions for this discussion:

                                     

                                    Is there a downside in starting with a single file solution (especially if one is just starting to get their feet wet in the FileMaker environment and or will be changing the database schema a lot at the start of the project), and then converting to the separation model?

                                     

                                    Has anyone used a key-logging program with FileMaker to automate the modifications of the FM database schema?

                                     

                                    I have used the separation model in other environments (e.g. Access), but those environments have the ability to manipulate the database schema via code/scripts (e.g. data manipulation language or "DML").  Any rumors, potential for FMI adding DML scripts to their products?

                                     

                                    Thanks for any responses.

                                     

                                    Steve

                                    1 2 Previous Next