Jason,

I really sorry to do this but...

While I can see how your request could provide for input into the SP
from a variety of sources. I can't see how this approach would
manipulate/perform an action on multiple tables (expect the obvious case
where there are multiple tables statically specified and updated by the
SP). How would the "operation" of the SP be changed to allow for the
operation of the SP to be changed?

I suspect that there is something which you haven't verbalized, yet,
that goes directly to the source of my ongoing 'misgivings'. Perhaps a
crude outline of your APROCEDURE might help.


Sean

-----Original Message-----
From: Jason Wharton [mailto:jwharton@...]
Sent: Friday, June 16, 2000 12:19 PM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Enhanced handling of EXECUTE
PROCEDURE statement

Markus,

I would have to say because it allows one to take action on multiple
tables.
If I were just dealing with one table and needed to do various
manipulations
I would just use a trigger.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Markus Kemper" <mkemper@...>
To: <IB-Architect@egroups.com>
Sent: Friday, June 16, 2000 7:11 AM
Subject: Re: [IB-Architect] Enhanced handling of EXECUTE PROCEDURE
statement


>
> Jason,
>
> Is your request more desirable to you than the insert statement
> because the input params sent to the procedure are being manipulated
> or inserted into multiple tables?
>
> Markus
>
> Jason Wharton wrote:
> >
> > I would like to suggest an enhancement to the SQL capabilities of
InterBase
> > and wonder what the architectural feasibilities of them are.
> >
> > In the same way you can do this:
> >
> > INSERT INTO ATABLE ( <list of columns> )
> > SELECT <list of columns>
> > FROM ANOTHERTABLE
> > WHERE <record selection criteria>
> >
> > I would like to be able to do this:
> >
> > EXECUTE PROCEDURE APROCEDURE ( <list of columns> )
> > SELECT <list of columns>
> > FROM ANOTHERTABLE
> > WHERE <record selection criteria>
> >
> > What has to be done right now is to write an additional stored
procedure
> > with a FOR SELECT and then in it's loop call the EXECUTE PROCEDURE
> > statement. This is really a pain to have to do and not only that you
cannot
> > dynamically adjust the where clause of the SELECT that determines
the
> > records filtered into the stored procedure because that part is
actually
in
> > a stored procedure too.
> >
> > This seems like it should be a simple allowance but I wonder if
there is
> > anything more to it than meets the eye. I suspect it might have
something to
> > do with the EXECUTE PROCEDURE construct being able to return results
whereas
> > the INSERT statement does not.
> >
> > All comments and suggestions appreciated.
> >
> > Jason Wharton
> > CPS - Mesa AZ
> > http://www.ibobjects.com
> >
> >
------------------------------------------------------------------------
> > Best friends, most artistic, class clown Find 'em here:
> > http://click.egroups.com/1/5533/4/_/830676/_/961115474/
> >
------------------------------------------------------------------------
> >
> > To unsubscribe from this group, send an email to:
> > IB-Architect-unsubscribe@onelist.com
>
>
------------------------------------------------------------------------
> GIVE YOUR WIFE A BREAK! Lowest prices on maids, lawn care, carpet
> cleaning, painting and remodeling services in your area at our new
FREE
website.
> http://click.egroups.com/1/5572/4/_/830676/_/961165224/
>
------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>


------------------------------------------------------------------------
Get a FREE "YourName.Com" Web Address,
E-Mail, and Home Page...TODAY! CLICK HERE!
http://click.egroups.com/1/5460/4/_/830676/_/961172554/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com