12 Replies Latest reply on Sep 9, 2015 5:52 AM by wimdecorte

    Changing layout on server

    LauraJones

      Hi,

       

      I have already uploaded my database to the FileMaker server but I need to change the layouts because everything has been altered when viewing through a web browser. I will likely need to alter the layouts regularly as people using the database think of new information to add. Do I need to change it using my FileMaker pro software and then upload it again? and if so, does this automatically overwrite the original/previous upload, or do I need to keep uploading the database and deleting the old one? How will this affect the data that has been entered by users?

        • 1. Re: Changing layout on server
          Mike_Mitchell

          Hello, Laura.

           

          You can change layout elements on a hosted database without affecting any data. Users will see the changes after you save them at their next refresh.

           

          Note that, as a best practice, if you have extensive changes to make, it's often a good idea to make all your changes on an offline copy, then shut down the production copy, migrate the data into the new version, and then upload it to the server. This is especially true if you have business logic built into your interface (such as Conditional Formatting that indicates actions to take, hidden elements, etc.). Minor tweaks are usually not a big deal.


          Of course, your question - "as people ... think of new information to add" - makes me think you have more than layout elements in mind. "New information" likely means new fields in the database, or perhaps new scripting elements. This is a slightly different discussion. New fields require opening the Manage Database dialog, and that can create a risk of damaging the database if done while users are actively editing records. (How large of a risk is a matter of some debate.) Minor changes are probably safe. Major changes are probably best saved for offline updates.

           

          There have been several threads over the years discussing the pros and cons of live updates. You can search the forum if you're inclined to see the various implications. Here are a few to get you started:

           

          Updating a live file

          Re: Best Practices for Ongoing Development with a Live Database

          Re: How Does One Do Ongoing Development in a Live Database?

           

          HTH

           

          Mike

          • 2. Re: Changing layout on server
            JonasGysin

            Hi Laura,


            No you don't need to upload it again. You can open the file hosted on FMS In FMP or FMPA, file -> open remote, selec your server and open the file. The modifications will be "live" so it's good to have a backup just in case. You can configure backups on the admin console of FMS. If you want to copy the file manually, you'll have to close the file on the server first.

             

            Jonas

            • 3. Re: Changing layout on server
              LauraJones

              Hi,

               

              Thanks for that, I can now see that when I make changes through FMP it is updating on the server. A major issue I'm having, which is why originally I didn't think it was working, is that the changes I make on FMP are not having the same scale of change on the server. I have attached a file to show the two different views on the web and FMP.

              I can't seem to get all the check box choices to be completely visible on the server copy. I've tried reducing the font, moving the position of the options from the centre to the top and extending the size of the box. I have also tried to reduce the spacing between the choices. I have only made these changes to one of the fields (IUGR) so you can see the difference with the other fields. The changes are negligible on the server version and if I make the box any bigger it just moves some of the other options to the bottom so I'm left with the exact same thing that I can't see the bottom choices completely. Can you please help me understand why this is happening and how to fix it. screen shots.jpg

              • 4. Re: Changing layout on server
                coherentkris

                make sure your using a supported browser, (Chrome, Safari, and IE) and watch this video to understand the stuff you need to know to make webdirect work for you.

                FileMaker 13 WebDirect Overview and Optimization Presentation Tutorial - YouTube

                 

                Unfortunately FM to WebDirect is not 100% pixel perfect translation. In addition each supported browser has quirks that you have to handle.

                • 5. Re: Changing layout on server
                  Mike_Mitchell

                  I suggest you consider using pull-down menus or drop-down lists rather than checkboxes. Checkboxes are rendered using CSS standards on the web, and, as coherentkris points out, will vary, often quite a bit, based on which browser you're using.

                  • 6. Re: Changing layout on server
                    LauraJones

                    I understand that there isn't a perfect translation onto webdirect. I've already had to accept that the check boxes are not displayed as a list in webdirect, making the viewing of a large value lists very difficult. Luckily this database is just for my research team so we can make some allowances for these known bugs. What I want to do is make the appearance of the webdirect version usable. It doesn't matter if this means that I can't see certain things very well on FMP because we can all just use the webdirect version. So how do I make this particular issue work on webdirect? All I want it to be able to see all the checkbox options and I don't care how that makes the FMP version look.

                    • 7. Re: Changing layout on server
                      wimdecorte

                      With a lot of caveats... if you do this on a live system where users are actually working: the moment you commit a layout that layout will be locked while saving and all scripted actions that go to that layout will fail.  So potentially your users may run a script that intends to go that layout but will fail.  If the rest of the scripts adds, deletes or changes records, changes are it will happen on the wrong layout/table/record.

                       

                      Similarly if you make a change to a table or field definition, that table will be locked and any "new record" action on the client will fail.

                       

                      So if you must work on a live system, do it when nobody is on.

                      • 8. Re: Changing layout on server
                        beverly

                        Laura, Is your value list large? is value list based on field? If, so a scroll list (portal, perhaps) may be an other option. Even on the web with 'normal' web publishing multiple checkboxes should not have very many "values".

                         

                        IF the value list is a small set and composed of custom values, I have used the trick of assigning each value to a single 'list'. Then place a duplicate of a field on the layout, but assign one of these single lists to each copy.

                         

                        myField (w/ 'a,b,c' list) ->

                         

                        myField (w/ 'a' list)

                        myField (w/ 'b' list)

                        myField (w/ 'c' list)

                         

                        This is more HTML-like and allows precise placement of each checkbox separately.

                         

                        I'll make a screen shot if this explanation is not clear.

                         

                        beverly

                        • 9. Re: Changing layout on server
                          Mike_Mitchell

                          Just for the record ... I tend to fall on Wim's side of the "work on a live system" debate. It's just when I say so, it tends to attract a lot of argument from the other side, which I was attempting to avoid.  

                          • 10. Re: Changing layout on server
                            wimdecorte

                            I hear ya

                             

                            You can actually make ti save to work on a live system by error trapping and handling the proper errors:

                            300

                            File is locked or in use

                            301

                            Record is in use by another user

                            302

                            Table is in use by another user

                            303

                            Database schema is in use by another user

                            304

                            Layout is in use by another user

                            306

                            Record modification ID does not match

                            307

                            Transaction could not be locked because of a communication error with the host

                            308

                            Theme is locked and in use by another user

                            But I have yet to see a solution that does it properly.  It means you have to test for the available schema lock errors on every single context change (change layout, gtrr,...) and every record manipulation.  It is a lot of work to make a solution safe against live development.

                            Easier to do the work when no users are on....

                            • 11. Re: Changing layout on server
                              Markus Schneider

                              as long as it comes to scripting, You can look for the last error (get(lasterror)) after a 'new record'- or a 'goto layout'-command (etc.) - but You have to make sure that in case of an error the script will revert and sends a message to the user (therefore not possible with server scripts,)

                               

                              could be a wish for the next version...

                               

                              edit: Wim was faster...

                              • 12. Re: Changing layout on server
                                wimdecorte

                                Markus Schneider wrote:

                                 

                                as long as it comes to scripting, You can look for the last error (get(lasterror)) after a 'new record'- or a 'goto layout'-command (etc.) - but You have to make sure that in case of an error the script will revert and sends a message to the user (therefore not possible with server scripts,)

                                 

                                could be a wish for the next version...

                                 

                                edit: Wim was faster...

                                 

                                It's a bit more complex than that.  A message to the user may not be enough.  Sometimes you can just loop and wait (but even that needs an exit condition...) or you have to fully undo what you were doing,... it all depends on the what the business logic was doing at the time.

                                 

                                As to PSoS: those should be modular and report back the error so that you can handle it in the calling script.