| Subject | Re: [IBO] Re: ClientSql vs ServerSql |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-11-14T21:03:18Z |
At 03:16 AM 15/11/2008, you wrote:
There isn't always a difference between the two. Between the ClientSQL, that your app presents to the IBO parser, and the ServerSQL, that IBO sends across the wire, there might be several manipulations resulting from run-time activity.
The simplest example is a parameterised statement. The clientsql has Delphi-style placeholders for parameter values, e.g.
select col1, col2 from aTable
where col3 = :aParam
When IBO passes this statement over the wire for a prepare, it passes
select col1, col2 from aTable
where col3 = ?
More complex changes to the statement will occur if you are using the OrderingLinks and OrderingItems mechanisms, i.e., there will be an ORDER BY clause in the Serversql that is not in the Clientsql. Similarly so if your app is using other methods that alter the statement in run-time, such as SQLWhereItems.
These are just some examples of where the parser might change the SQL. There are other run-time things that can result in changed SQL...You can watch what is going on by using a TIB_Monitor.
I hope this is more helpful this time. :-|
Helen
>>Sorry! I didn't notice I was answering an IBO list question! My apologies.
>> There is no "ClientSQL" vs "ServerSQL" distinction. Clients pass
>requests to the server in SQL...
>
>I'm afraid i've not asked accurately... I mean what is the difference
>between ClientSQL and ServerSQL PROPERTIES of TIB_QUERY? :)
There isn't always a difference between the two. Between the ClientSQL, that your app presents to the IBO parser, and the ServerSQL, that IBO sends across the wire, there might be several manipulations resulting from run-time activity.
The simplest example is a parameterised statement. The clientsql has Delphi-style placeholders for parameter values, e.g.
select col1, col2 from aTable
where col3 = :aParam
When IBO passes this statement over the wire for a prepare, it passes
select col1, col2 from aTable
where col3 = ?
More complex changes to the statement will occur if you are using the OrderingLinks and OrderingItems mechanisms, i.e., there will be an ORDER BY clause in the Serversql that is not in the Clientsql. Similarly so if your app is using other methods that alter the statement in run-time, such as SQLWhereItems.
These are just some examples of where the parser might change the SQL. There are other run-time things that can result in changed SQL...You can watch what is going on by using a TIB_Monitor.
I hope this is more helpful this time. :-|
Helen