2 Replies Latest reply on Aug 30, 2013 1:11 PM by mikem

    Ways to display a related field on a layout - does it matter?


      Hi Forum,


      I am working with an inherited multi-file database and have noticed something curious. Two different ways have been used to display a global related field in a layout:


      1. Use "Specify Field..." to point the field instance in the layout to the desired related field.


      2. Create a new calculation field in the table used by the layout, and for the calculation, specify only the desired related field. Point the field instance in the layout to this new calculation field.



      It seems to be that method #2 is just more time & effort, and maybe even less performance, for no benefit. But am I missing something? Could there be any advantage to method #2? I am planning to convert all #2s to #1s just to streamline things.


      Thanks much for any thoughts on this,



        • 1. Re: Ways to display a related field on a layout - does it matter?

          Hello, Mike.


          I suspect, since you refer to this being a multi-file database, that you may be dealing with an older solution that was converted from the pre-version 7 days. In earlier releases, you couldn't prohibit field entry using layout options. Hence, some developers resorted to using a calculation field that simply echoed a value out to prevent users from altering it.


          Nowadays, such techniques are obsolete. And you're right; they generally serve no good purpose and contribute to database overhead. The only exceptions are certain, somewhat obscure, instances where you need to echo a field in table A because the value in table B needs to be reflected in related table C (in a portal, for example).



          • 2. Re: Ways to display a related field on a layout - does it matter?

            Thanks Mike. I'm almost sure this was a pre-7 database originally, so what you say makes perfect sense.


            A little more info, in case it helps somebody: the related fields in question are global container fields that hold icons used in buttons in many of the layouts. When I take a copy of the database with all those fields deleted, I get a huge increase in remote performance. I'm next going to try a version with the fields still there but the method #2s converted to #1s. I suspect I'll lose most of the performance gain, but I want to give it a shot. Probably need to find simpler icons or go with text-only buttons (maybe a symbol font), to maintain the big performance jump...


            Thanks again.