On 22 Nov 2001, at 5:51, Claudio Valderrama C. wrote:

> "Nando Dessena" <nandod@...> wrote in message
> news:3BFBB915.CE6C07FD@......
> >
> > This is absolutely required, and perhaps Jason's suggestion was
> > directed towards this. I could even accept the engine overwriting
> > anything I could have put in (so, no test for null), but it must
> > give me back the values.
>
> We can borrow the idea from MsSQL, whether good or bad: we keep the
> latest implicit generator's value retrieved in the internal request
> and implement a new item in the isc_database_info API call to get this
> value. Now, it's the responsability of the application to retrieve the
> latest value with the API call before another operation updates the
> latest saved value.
>

Actually I think Jason was right on the ball, if the value has been
"preset" by the application, then we assume that the application
knew what it was doing, and accept that value. I also agree with
Jason that the RETURNING clause has a lot of merit, especially
since the mechanics are already in the engine.

I think that we need to put as much into SQL as possble, not
everyone knows the API, nor do they want to know the API.
However RETURNING should return all values after the relevent
triggers have fired (before and after insert triggers) so if you have a
field affected by triggers you could use the RETURNING values to
update the display. Also RETURNING should be independant of
the actual inserted fields, so if you have a value calculated in a
trigger you can return that value as part of the insert.

Paul


Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com