On 17 Oct 2001, at 17:35, Ann W. Harrison wrote:

>
> > > At 10/16/2001 07:31 PM (Tuesday), Sandeep wrote:
> > > > > select * from tableA a
> > > > > where a.Field = select outputParam from MyStoredProc( Val );
> > > >
> > > >That's what I use right now and I was trying to get away from writing
> > > >[ select outputParam from MyStoredProc( Val ) ]
> > > >everytime i want to get that value.
>
> >On 16 Oct 2001, at 20:32, Doug Chamberlin wrote:
>
> > > My first reaction to this is: May I ask why? Looks perfectly good to me.
>
> At 02:13 PM 10/17/2001 +1300, Sandeep wrote:
> >Imagine a procedure with that line repeated in where clause more
> >than 50 times, now what if it was replaced by function call. Well it
> >makes the code look much neater and easy to debug.
>
> Let me see if I understand. You have a function that transforms
> an input value. You use the result of that function in a stored
> procedure to select rows from some table and produce a result
> from that data. The result of the stored procedure is used to
> qualify rows in tableA.

No I have a stored procedure and that has following line

[ select outputParam from MyStoredProc( Val ) ]

repeated more than 50 times. If I replace it with a function call like
functionA then the code becomes much eaiser to read.

> That query that has more than 50 conditions in the where clause.
> I'm really impressed - in my several years of database programming,
> I don't think I've gone beyond 10 conditions, and that only when I
> need to compare nulls. Without knowing anything about your application,
> I wonder if there may not be some other way to approach the problem.
>
> Have you considered using a view to encapsulate all this?

All I trying to find out is there a way to declare a function which
executes a stored procedure and returns the result

regards


Sandeep

Software Developer
CFL
sandeep@...
http://www.cfl.co.nz