On Monday 27 January 2003 12:30, you wrote:

Hi,

> >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.

Your right of course. As normally there are moany different ways to write an
app.

> 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.

You don't have to commit the SP to get the ID, you can still roll back

> 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...

Not if you do the whole thing in a single transaction, but it all depends on
how you are doing things client side.

Phil
--
Linux 2.4.4-4GB
7:09am up 14 days, 12:58, 1 user, load average: 0.60, 0.28, 0.14