Frank Schönheit - Sun Microsystems Germany wrote:
Hi Fernand,
Can someone confirm the following "performance" options:
When using the API and basic to load the data in a form based on a SQL
command, I suppose that it sould be better to include the filter options
directly in the the SQL statement and not using the filter and sort
properties off the form. I suppose that OO after changing the sort or
filter property simply rebuild the SQL statement and send a new request
to the server ?
A new statement is built and sent as soon as you call the form's
load/reload (resp. execute) method. So, it doesn't really matter whether
you set the Filter/Sort at the respective properties, or directly in the
SQL command: The subsequent re/load call will compose the statement
(which you would need to do, too) and send it to the server (which you
would need to do, too).
I think however - and I think that Frank's response answers it - that
the question is one of 'best practices'.
There is a form that is about to be displayed to the user, the form will
have some filter appended to the SQL command saved with the form at
design time. How do I do so in the most efficient manner?
1 - Open the form on the desktop - update the filter property - call reload
2 - Alter the SQL statement prior to opening the form.
Good question!
Which is faster (more efficient)
- 2 looks like a better answer, doesn't it. This might then lead one to
conclude that it would be better to base your form on a QueryDefinition
rather then an embedded SQL command, since doing so allows you to easily
implement the workflow expressed in line 2 above.
Truth is though that Opening, Updating and Saving a query definition has
a cost also. If Im'm not mistaken, unless that querydefinition is set to
'run sql direct' then this cost includes a trip to the server. So, when
does one out weigh the other?
Other questions come to mind in thinking about how to answer what I
think is your real question.
Do you really want to close every form when the user is done with it?
When would it be better to hide form instead?
Is using a QueryDefinition the only way to achieve the workflow in line 2?
Can you use call back procedures (my term for assigning listeners, sorry
old habit) to catch the form load event, prior to the dataform actually
loading data, and add the filter condition at that point?
Anyway - is this (these) the question here?
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
