« Return to Thread: Filter an Sort performances
Re: Filter an Sort performances
by Fernand Vanrie
::
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 :)
>
I want to understand how the Base application is building the SQL
statements based on the command, filter and sort properties an finaly
how "cost" effective is this statement on the the server side. Behind
this question is also a concern, when developing a frontend I must
produce code who will work for more than one Driver. When using a local
network then i sould use the Native MySql-connector when going over the
web then a ODBC connector comes in place. Native MYSQL statements will
work for both drivers , will statements build by the Base application do
alsoo ? =)
thanks for your opinions
Fernand
>
>> 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.
> If you do it by UI, then some database meta data will be queried, but
> we're constantly improving on caching those where possible :)
>
>
>> 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.
>
> Ciao
> Frank
>
>
---------------------------------------------------------------------
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 :)
>
I want to understand how the Base application is building the SQL
statements based on the command, filter and sort properties an finaly
how "cost" effective is this statement on the the server side. Behind
this question is also a concern, when developing a frontend I must
produce code who will work for more than one Driver. When using a local
network then i sould use the Native MySql-connector when going over the
web then a ODBC connector comes in place. Native MYSQL statements will
work for both drivers , will statements build by the Base application do
alsoo ? =)
thanks for your opinions
Fernand
>
>> 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.
> If you do it by UI, then some database meta data will be queried, but
> we're constantly improving on caching those where possible :)
>
>
>> 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.
>
> Ciao
> Frank
>
>
---------------------------------------------------------------------
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 |
