At 09:46 AM 27/01/2003 +0000, you wrote:

>On Monday 27 January 2003 11:31, HeLen wrote:
>
>Hi,
>
> > CREATE PROCEDURE insertRecord (In_Name varchar(10))
> > RETURNS (out_ID integer)
> > as
> > begin
> > out_ID = GEN_ID(gen_MyTable_ID, 1);
> > INSERT INTO myTable (id, name)
> > VALUES (:out_ID, In_Name);
> > end ^
> >
> > Normally, we don't get the generator value this way.
>
>I do <g>
>
>Certainly in 2-tier apps, I normally have an add/edit/view/delete stored
>procedure for each entity (e.g. Customer). It allows a very thin client, and
>tends to make maintenance a lot easier IMO. But I suppose it depends on how
>you develop your client app and what 'toolset' you use to connect to FB.

As always, of course. <g>

But, if you need the ID in your app for a new master-detail structure, and
you want it to be roll-backable, then you need to have that ID *before* you
either commit the entire structure as a whole. Hence my comment.

In the case where you are merely inserting rows and don't require to know
the ID back in the application, one would use a trigger...

So, generating the ID in the SP seems (to me) necessary only where you are
inserting a row and your application wants to know it *immediately after
committing* the SP. This timing is too late for an integral master-detail
insertion, if you don't want to be left with the master row when the user
decides to cancel...

heLen