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: [email protected]
For additional commands, e-mail: [email protected]
