Re: Slow Retrieval in Forms Multi-Block

From: Todd Owers <toddo_at_gcr1.com>
Date: Mon, 14 Dec 1998 11:18:16 -0600
Message-ID: <753hfs$30h$1_at_nntp.gulfsouth.verio.net>


Ed,

For what it's worth, I use the same structure as you (Post-Query trigger to populate look-up values, rather than an updateable view), with acceptable performance. Two thoughts come to mind:

  1. Have you performed basic SQL tuning (e.g., indexes on WHERE clauses, etc.)?
  2. Perhaps the users need to re-think their desire to navigate through 300-800 records on the screen. Realistically, what is a user going to do with all those records? Even if you display 20 records at a time in a multi-record block, the user will have to mouse-click or press the down arrow 15-40 times to scroll through the entire result set. In an OLTP application, the reason for querying a record and displaying it on the screen is so a user can look at it, mentally process it, perhaps update/delete it, or decide a new record needs to be added. Is it realistic for a user to mentally process 800 records?

Hope this helps.

Todd Owers

Ed Jennings wrote in message <3671CD09.661E60E0_at_mindspring.com>...
>I have a multi-block Form that contains relationships from the primary
>block to four other blocks. In addition, there are three data elements
>in the primary block that are pointers to a reference table. I use a
>POST-QUERY trigger to populate non-database fields with the actual
>values from the reference table, so that the display has more meaning to
>the users.
>
>I don't use a view because I need control of the INSERT/UPDATE/DELETE
>processes. When the users run a query, the first rows come back very
>quickly (1-5 seconds) depending on selection criteria. However, the
>users wanted a way to quickly traverse to the last record in the
>result. I therefore provided a button that executes the LAST_RECORD
>built-in. When the result set is of moderate size, 300-800 records, it
>takes upward of 90 seconds to retrive all of the records.

[snip]

>Do I have a design flaw? Is there a better way to display a primary
>table, 5 related tables, and a reference table more efficiently? I
>don't want to have to use of view because of the update headaches? Any
>suggestions????????
>
>Ed Jennings
Received on Mon Dec 14 1998 - 18:18:16 CET

Original text of this message