Subject | Re: [IBO] RETURNING clause in FB 2.1 |
---|---|
Author | kokok_kokok |
Post date | 2007-09-20T09:22:19Z |
In reality, RETURNING clause is from the FB 2.0, then I understand
that IBObjects may support it but I cannot find the documentation.
Using RETURNING clause, I expect to return from the server to client
all columns that the server has altered in the trigger. In this way I
get 2 improvements:
1-It is more consistent and safer. The generator name is always the same.
2-I do not need to call GEN_ID from the client side, increasing the
network traffic and the source code.
3-I do not need to call explicitly the TClientDataSet.Refresh function
to update the row.
Thank you
that IBObjects may support it but I cannot find the documentation.
Using RETURNING clause, I expect to return from the server to client
all columns that the server has altered in the trigger. In this way I
get 2 improvements:
1-It is more consistent and safer. The generator name is always the same.
2-I do not need to call GEN_ID from the client side, increasing the
network traffic and the source code.
3-I do not need to call explicitly the TClientDataSet.Refresh function
to update the row.
Thank you
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 06:20 PM 20/09/2007, you wrote:
> >In my app, I use TClientDataSet + TIBOQuery
> >
> >A common problem is when I put default values in the table using a
> >trigger (autoinc ID and other default values).
> >
> >I need to send these values to the client side. In the client side, I
> >do not know the row ID, so I cannot refresh the record to reload the
> >new values. In MSQL server I used SCOPE_IDENTITY(), now I see that FB
> >2.1 has RETURNING clause.
> >
> >My question is : Using IBObjects, how do I get the ID value after the
> >TClientDataSet.ApplyUpdates()?
> >
> >
> >I know that I can use GEN_ID to create the ID in the client side, but
> >it is not a good idea. I prefer to put all default values in the
> >server side.
>
> First, IBO doesn't support the features introduced in Firebird
> 2.1. It is a first beta - for field-testing intial implementations -
> and you should not be relying on it for your production work.
>
> Secondly, GEN_ID does *not* create the ID in the client side. It
> makes a call to the database to fetch (and thus secure) the next
> value of the generator. What's more, it is totally a good idea and
> substantially safer than relying on getting the value back *after*
> the record has been inserted, if you need it for applying to foreign
> keys in detail records.
>
> Helen
>