Subject | Re: [IBO] Correct usage of RETURNING clause |
---|---|
Author | Robert Martin |
Post date | 2014-05-28T23:38:49Z |
Awesome answer. Also answered my next question which would have been
what do you do when you have parameters with the same name as the field
you want to return !
Tried masons suggestion which works but, asside from the extra code and
overhead, just feels strange :)
Thanks Jason and Mason
Cheers
Rob
On 29/05/2014 11:34 a.m., 'IBO Support List' supportlist@...
[IBObjects] wrote:
what do you do when you have parameters with the same name as the field
you want to return !
Tried masons suggestion which works but, asside from the extra code and
overhead, just feels strange :)
Thanks Jason and Mason
Cheers
Rob
On 29/05/2014 11:34 a.m., 'IBO Support List' supportlist@...
[IBObjects] wrote:
> TIBODataset has singleton output columns, such as you have here, handled
> along with the input parameters. This can be detected by looking at the
> param type of ptInput, ptOutput or ptInputOutput. If you happen to give an
> input and an output param the same name then you will get a parameter of
> type ptInputOutput. When you execute it the input value will be changed to
> the output value.
>
> TIB_Dataset, such as with TIB_Cursor or TIB_Query (the native IBO data
> access components) will not put any output columns in with the Params
> columns. They will be in the Fields columns as you are expecting. Also, you
> can retrieve singleton output values if you like.
>
> Mason's suggestion is also good but it does add in a little extra work to
> have the result delivered via a query that can return potentially multiple
> rows. There is the overhead of opening and closing a server cursor and the
> fetch calls. Doing it the way you were you simply call execute and all of
> the information is handled by that one API call. You can compare the
> difference by looking at the SQL trace monitor to see the difference.
>
> Hope this helps,
> Jason Wharton
> www.ibobjects.com
>
>
>
> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
> Sent: Wednesday, May 28, 2014 6:09 PM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] Correct usage of RETURNING clause
>
> Hi
>
> I am doing an SQL like
>
> UPDATE TableA
> SET Fieldname = 2
> WHERE Fieldname2 = 3
> RETURNING PkField
>
>
> In an IBOQuery I write
>
> Query.ExecSQL;
>
> Showmessage(Query.ParamByName('PkField').AsString);
>
>
> This works, I thought I should have used FieldByName but while this does
> not Error it does not return a result. Is the above correct?
>
> Thanks
> Rob
>
>
> ------------------------------------
> Posted by: Robert Martin <rob@...>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more !
> http://tracker.ibobjects.com - your portal to submit and monitor bug reports
> http://community.ibobjects.com - your portal to purchase and upgradeYahoo
> Groups Links
>
>
>
>
>
> ------------------------------------
> Posted by: "IBO Support List" <supportlist@...>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more !
> http://tracker.ibobjects.com - your portal to submit and monitor bug reports
> http://community.ibobjects.com - your portal to purchase and upgradeYahoo Groups Links
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3950/7580 - Release Date: 05/28/14
>
>