1 2 Previous Next 15 Replies Latest reply on Mar 8, 2017 4:01 PM by Malcolm

    Go to Portal Row faulting in Webdirect


      Hi all.


      My issue is as follows...


      Firstly, FYI,  this database is sitting in FileMaker Server v15.


      I have a script in a button in a portal and this button overlays all the fields. This is of course a typical method to action an event for that record in the portal. The nett effect of this script is to select a record and bring up more information about that record on the same layout effectively using the portal as a quick navigation method.


      This script does the following:

      I assign the active portal row number to a local variable $portalrow

      I use Go to Related Record on the same layout to perform the main the purpose of the script.

      I then go back to the portal via Go to Object.

      Finally I use Go to Portal Row with calculation $portalrow and Select Entire Contents.


      This script works perfectly in FileMaker Pro, and it is simple enough that it should. However in Webdirect the group of visible rows it navigates to does not include the previously selected row and none of the rows that are visible are highlighted. Using Custom Dialogs or script debugger shows that the $portalrow number stays intact throughout the script in Webdirect as it does in Filemaker Pro.


      Whilst I have been typing this I have been trying workarounds and have more information to offer. Firstly I have discovered (by scrolling up and down) that it does in fact highlight the correct portal row but that particular row is not present in the visible group of rows in the portal. So it highlights row 12345 but we may see rows 12000 to 12010 in the portal. I have some pertinent information and theories which may explain it but it doesn't justify it happening in the first place. Here they are:


      Firstly this database contains over 12000 records. There is a noticeable lag in Webdirect which is not present in FMPro. I am working on this remotely and whilst I have a fast internet speed both ways the other end has a slow upload speed.  Bear in mind that despite this speed discrepancy it does work fine in FMPro.

      Secondly I have screen shared in to the server and repeated this exercise locally on the server machine connecting to it via WebDirect on the server itself and the same problem occurs even though it is local and not over a network or the internet.


      Is Webdirect simply choking on the sheer size of the database perhaps and it redraws the portal too soon, before it has 'caught up'?


      At this point it is too time consuming to test the whole exercise in a version of the database that has been trimmed of a large number of records however if I get no feedback that helps I may have to set this up to confirm my theories.  However this will of course not solve the problem because I need all those records in this portal.


      Welcome your feedback!



        • 1. Re: Go to Portal Row faulting in Webdirect

          I've heard about this issue on one of the German-language forums, but not been able to reproduce it myself.


          Are there any other objects on the layout? Anything "complex"? Any web viewers?

          • 2. Re: Go to Portal Row faulting in Webdirect

            Hi David.  Thanks for your feedback.


            Looking at this layout's complexity is a good idea so here is a precis of what I have.


            Essentially we have the portal which is 12000 records of which only 4 fields are showing and they are all simple text fields, no calculations.  The rest of the data that is populated outside the portal when the portal row is clicked includes an image container (very small thumbnail) a few text fields with passive data and 6 calculated fields that use a relatively simple custom function to parse an xml field to extract the required data. The calculation results are stored and not forced to recalculate. The xml field is less than 1000 chars. There is nothing more complex than that I'm afraid. I forgot to mention that the web direct side does work if you are playing towards the top of the portal which again seems to point to web direct getting choked.


            Gotta love a challenge. If I can't get it working I am going to switch to a two layout solution where you select the line item on a list view layout  which then switches back to another layout with the expanded info. I'd really just like it on one page...



            • 3. Re: Go to Portal Row faulting in Webdirect

              The layout doesn't sound all that complex - it might be the sheer number of rows that is the issue. I don't know the specifics of your case, but it might be that a portal showing 12,000+ records at once isn't the best choice anyway.


              Other than that, have you tested things like removing all other layout objects except the portal? And/or reducing the number of portal records and try to see if there's a cut-off somewhere?


              A workaround I read about that you can try is adding a Pause/Resume[0] script step before each the Go to Object and Go to Portal Row instructions.

              • 4. Re: Go to Portal Row faulting in Webdirect

                Sounds like a good idea about those pauses. Problem with dicky internet speed is how long does one pause?


                I will take that advice and strip the page bare and if it helps then speed then I’ll add ‘em all back one by one!


                In the end I actually think I will implement a search only system and avoid the portal or list views all together.  Good old fashioned searches!  It probably does make more sense because zipping up and down a portal sounds good in theory but via the Web is probably not practical.


                Thanks again


                • 5. Re: Go to Portal Row faulting in Webdirect

                  From what I understand, it's just the Pause instruction you need, with a 0 duration.


                  JörgKöster is the developer who posted about all this - I'm just referring what I believe to have learned from him - so maybe he has something more to add?

                  • 6. Re: Go to Portal Row faulting in Webdirect

                    Cool.  Thanks for the relaying!

                    • 7. Re: Go to Portal Row faulting in Webdirect
                      Benjamin Fehr

                      You refer to the so called FM "Voodoo-Toolbox":

                      - Commit

                      - Refresh

                      - Pause [0,2 seconds]


                      With WebDirect, I was told that Commit AND Refresh is no option since this would prompt a Re-LogIn with your Browser(?).

                      • 8. Re: Go to Portal Row faulting in Webdirect

                        @David: Thank you for relaying


                        @Todd: here my workaround. It works fine in WebDirect.


                        Pause/Resume Script [ Duration (seconds): 0 ]

                        Go to Object [ Object Name: "Sessions_STANDORTE" ]


                        Pause/Resume Script [ Duration (seconds): 0 ]

                        Go to Portal Row [ Select ; With dialog: Off ; $ActivePortalRowNumber ]

                        • 9. Re: Go to Portal Row faulting in Webdirect

                          Fantastic!  Whilst it's bedtime right now I'll put it on my To Do list for tomorrow.  This is one of those situations where the customer has their perception of how they want something to work and somehow you have to make it work


                          Thanks to everyone who responded.

                          • 10. Re: Go to Portal Row faulting in Webdirect

                            If you have 12 of something, you might want to display them. When you have 12,000 of something there is no value in displaying them. You can tell your users that there are 12,000 things associated with the record. You cannot reasonably expect anyone to inspect them all at once.


                            Even if you think you are presenting the full data set you can only display a small set at a time. How many portal rows are you displaying, 12,000 or less? If your portal displays less than the full amount, you are already paging/chunking the data. Get into the spirit of that.


                            Only display the amount of information your user wants or needs. You know that there are 12,000 associated objects. What is the probability that the first few records displayed in the portal are the ones that are pertinent to the user? If it is high, yes, display those few records. Don't use a portal. Do something clever to display them. If it is low, don't even put the portal there. Instead, determine whether they want to see any of those records and which ones they want, i.e., provide good search tools.


                            If you absolutely have to display lots of information in a list the problem could be solved inventively with a virtual list, that displays only a subset of records and a subset of fields. That would reduce your data overheads dramatically. Using the same sort of logic you could also present a invoice-like view, from the context of the related data using a large header area for the parent data. FileMaker automatically controls the data transfer, so you don't get completely hammered The algorithm is, approximately,  the number of records on view, plus a buffer of two dozen on the top and tail. Even so, random browsing through large data sets is the worst way to present information and the worst way to use the web.



                            • 11. Re: Go to Portal Row faulting in Webdirect
                              Benjamin Fehr

                              We don't know about the kind of records and therefor useful search criteria.

                              I would recommend use of a Portal Filter to narrow the portal down to a amount of records a user can deal with.

                              Let's say a search criteria is 'Company_Name'. You can set a Filter by Var $$MyFilter = "A" and a Portal Filter = Left (MyTable::Company-Name; 1) = $$MyFilter to show all companies with name starting with A".

                              You then could add some abc-Buttons at the top of the Popover to alter $$MyFilter to "B", "C", etc.


                              12'000 records means you should improve the user experience anyway

                              • 12. Re: Go to Portal Row faulting in Webdirect

                                Portal filters will only reduce the number of records transferred when you are comparing a constant with a field value. If any calculations have to be performed, every record is downloaded and evaluated. In those cases, the filter acts to display the correct set of records but does not prevent the transfer of unwanted records. Everything comes down the pipe. And this is only a recent optimisation. It doesn't work in earlier versions of FMP.


                                To get this sort of optimisation your filter needs to look like this:


                                "ABC" = MyTable::Company-Name



                                • 13. Re: Go to Portal Row faulting in Webdirect
                                  Benjamin Fehr

                                  means the portal filter would improve the user experience. Maybe some dedicated relations should be built to narrow down data traffic …

                                  1 of 1 people found this helpful
                                  • 14. Re: Go to Portal Row faulting in Webdirect

                                    @jkoester Thank you that works as described. The problem however becomes the 6-8 second lag where it does the final highlighting of the portal row in question.


                                    @Malcom @Benjamin Thank you to you both for that discussion. Yes 12000 records is silly to display, even in chunks of 10 portal rows at a time.  The initial perception was that it would be used as quick skimming method to jump to a particular record or records. Quite workable in FMPro but not via the web. Lesson learnt!


                                    Every record has a status which is one of "No Issue" "Unaddressed issue" "Addressing this issue" or "Issue addressed/resolved)" The idea also was that they sort with click at the top of the appropriate column to bring flagged records of each type to the top but leaving the others in the list further down.  Working with those records at the top of the list was working but scrolling down to a specific item further down is where this became an issue. It would have got worse when the number items in that with a specific status grew over time. Hence the initial discussion.


                                    I intend now to experiment with a simple search field for a specific record along with some fixed buttons that filter  to get one of those non-empty status values. I will then simply alter the customer's perception of how they will interact with this data.


                                    This all adds to the knowledge base in general as well as the specific one that highlights web specific issues, anomalies and things that need to be considered.


                                    Thank you all again. I can now move forward to the next challenges!


                                    PS.  Whilst I am not going to do this I am curious as to the performance difference in using a standard simple list view layout with a click taking you to more info on another layout versus using a portal as described above.  Is the fact that its in a related portal the biggest bottleneck or just that 12000 records shouldn't be listed at all?  Just a question out of curiosity that's all.



                                    1 2 Previous Next