On 6/2/2004 at 3:27 PM Ryan Baldwin wrote:

> The thing is we need to create these stored procedures and canot predict
> in
> advance which ones are required - the number of possible permutations are
> very large but for any given usage the number required is fairly small.
>

<snip>

>
> We can gurantee that our process is the only user of the database - it is
> intended to run embedded in deployment. So hopefully by understanding
> these
> dependancies fully we can manage this.
>

Ryan,

It seems to me that you are trying to shoehorn something into stored procedures that they aren't designed to do. If you are running embedded in deployment, why would you even bother playing with these dynamic stored procedures (especially since you are obviously creating each stored procedure in your application code as you need it)? Is there some reason that you wouldn't simply implement the business logic in your code and issue the SQL calls from your code instead of compiling a stored procedure to do it all for you? Everything you have been describing simply smells far too complicated to me: were I you, I would back off, re-examine my initial assumptions, and see if there isn't a simpler way.

I am certain that you will get far more useful comments out of people here if they aren't having to hold their noses as they read what you are trying to do... I know "I" gagged when I read your first post, and from her comments I'm pretty sure Helen did as well..

HTH,

Dan.