3 Replies Latest reply on Feb 11, 2015 12:35 PM by Mike_Mitchell

    Webviewer inside portal row


      Hi All,


      I currently have a solution for a calendar that has portal rows. I built in some conditional formatting so that users could color code the calendar record entries. Problem is, over WAN its incredibly slow. I think the reason is I have to have a seperate condition for every color thats available as an option. And of course each one has its own calculation.


      So I set out to find a better way. My first attempt: A web viewer inside the portal row.


      I am using my same Execute SQL calc as before, but its not pulling my colors. Do webviewers take their context into consideration? I need the webviewer to know what record its sitting on for this to work.



        • 1. Re: Webviewer inside portal row
          After further investigation, it looks like webviewer calculations dont work inside portal rows.   So I guess that leaves me with either adding a container field or stacking a bunch of colored boxes on top of each other.  Is there any other options I am missing?
          • 2. Re: Webviewer inside portal row

            madmike6537 wrote:

            Do webviewers take their context into consideration?


            They do if you reference context-dependent data – but that point is moot, since you can't have a Web Viewer in each portal row; see here:


            Selecting and working with portals

            • 3. Re: Webviewer inside portal row

              You might consider backing up and reconsidering your basic setup. You mentioned two things so far that might hurt your performance: Portals and ExecuteSQL ( ).


              Portals can hurt performance over the WAN in some cases because of the record-fetching FileMaker has to do to display them. If you've sorted the portal or the relationship, FileMaker has to fetch all the related records (all fields) over the WAN, and that can slow you down. Another potential bottleneck with portals is portal filtering, which also can hurt you for the same reason (it has to fetch the records to figure out which ones to display).


              ExecuteSQL ( ) is a wonderful tool, but not necessarily your best friend performance-wise. This is because FileMaker has to translate the SQL statement into its native binary query language before it can execute. It'll never be as fast, therefore, as native FileMaker functionality.


              So if you can recast the solution without these two elements, you might see some performance gains.


              Other options include using a Virtual List technique (which will avoid some of the record-fetching problem), using Hide Object When to push unneeded objects out of view (and therefore prevent their being evaluated), or perhaps letting us take a look at your calculations for optimization purposes.