« Return to Thread: Filter an Sort performances
Re: Filter an Sort performances
by drewjensen
::
Rate this Message:
Frank Schönheit - Sun Microsystems Germany wrote:
> Hi Drew,
>
>
>> I think however - and I think that Frank's response answers it - that
>> the question is one of 'best practices'.
>>
>
> Actually, I am not completely sure what the original question was :)
>
>
>> 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.
>>
>
> Yes.
>
>
>> 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.
>>
>
> If you update a query definition programmatically, no server traffic
> should happen.
>Excellent...hmmm, that old saying comes to mind...Trust but Verify.
This would be a good point to interject - Base supports, at least for
JDBC connectors, a logging mechanism that could be employed here for
profiling purposes..I think. Specifics of using this are on the wiki.
http://wiki.services.openoffice.org/wiki/Logging_JDBC_Activity
>
>> 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?
>>
>
> The XRowSetApproveListener might come handy here: It's called before the
> actual execution of the RowSet/Form happens, and it should be possible
> to modify the statement/filter/order/other in this callback.
>
>
Again, Excellent...now if we could do that with Sun Report Builder
generated reports that would just be supper.. or can we? (didn't see
that one coming did you...)
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
> Hi Drew,
>
>
>> I think however - and I think that Frank's response answers it - that
>> the question is one of 'best practices'.
>>
>
> Actually, I am not completely sure what the original question was :)
>
>
>> 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.
>>
>
> Yes.
>
>
>> 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.
>>
>
> If you update a query definition programmatically, no server traffic
> should happen.
>
This would be a good point to interject - Base supports, at least for
JDBC connectors, a logging mechanism that could be employed here for
profiling purposes..I think. Specifics of using this are on the wiki.
http://wiki.services.openoffice.org/wiki/Logging_JDBC_Activity
>
>> 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?
>>
>
> The XRowSetApproveListener might come handy here: It's called before the
> actual execution of the RowSet/Form happens, and it should be possible
> to modify the statement/filter/order/other in this callback.
>
>
Again, Excellent...now if we could do that with Sun Report Builder
generated reports that would just be supper.. or can we? (didn't see
that one coming did you...)
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: Filter an Sort performances
| Free embeddable forum powered by Nabble | Forum Help |
