2 Replies Latest reply on Feb 26, 2012 3:34 PM by HOnzaKoudelka

    Optimization Retrieve Records

    Fagreement

      Title

      Optimization Retrieve Records

      Post

      Hi,

      I have a FM application with SQL as database. in the main page of my application I have a portal where i displayed the total records of a table. the issue is that I have more than 9000 records, so when i open the application i have to wait around 3 minutes to have the portal displayed all the records.

      How can I optimized this process?

      is there any workaround to retrieve records "on demand" ? I explain, on open FM will bring only the 100 firdt records, and then like "Next page" FM will bring the next 100 pages.

      any idea?

        • 1. Re: Optimization Retrieve Records
          philmodjunk

          You might try portal filtering or a filtered relationship.

          Say you have a serial number that uniquely identifies each record and the order of the records in the portal lists them with this field in increasing order.

          PortalTable::SerialNumberField < GetNthRecord ( PortalTable::SerialNumberField ; $$SetCount * 100 ) AND
          PortalTable::SerialNumberField > GetNthRecord ( POrtalTable::SerialNumberField ; $$SetCount * 100 - 99 )

          Should filter your portal down to just sets of 100 at a time, and a script can increment/decrement $$SetCount to bring up different sets of 100 records. If this doesn't seem to work, you may find you need to refresh the window and you may need to add a second occurrence of the PortalTable with an identical relationship so that you can base the portal on one occurrence and refer to the other with GetNthRecord.

          I also do not know if this will update much faster than your current set up. You'll need to experiment and see.

          • 2. Re: Optimization Retrieve Records
            HOnzaKoudelka

            Portal filtering won't help as it happens on the client side.

            Portal pagination utilizing filtered relationship seems to be the best option in most cases.

            I would also suggest using a multikey (such as "1¶2¶3¶4¶5" to display records 1 thru 5) rather than comparative operators.

            See this article to learn about portal pagination: http://24usw.com/2e0o0q

            See this LinkedIn discussion for more about the danger of using comparative operators: http://24usw.com/5vrime