Hello,

I have a form which has a dozen or so input fields, and currently I'm 

updating the back-end SQL database by generating the SQL on-the-fly (ie 

concatenating together the INSERT/UPDATE statement).  This works fine.  I 

now understand that stored procedures are generally a better way of doing 

things, but is this still the case if I'm creating lots of parameters and 

passing them along?  Is there some sort of upper-limit on parameters, 

where stored procs become slower and/or too clumsy (in terms of style) 

than other methods?



TIA,

Julio

Hey,



Stored Procedures are genrally faster than regular calls. I have yet to see

when the Stored Procedures are slower, so I can't really tell you. I don't

think any number of arguments sent to a stored procedure would make it

clumsy .. I mean, just think of the readability of an SQL statement with 40

fields to be updated. Stored Procedures are really good for handling that.



Kind Regards,



SWJ.

----- Original Message -----

From: "Julio Allen" <julioallen@y...>

To: "ASP Databases" <asp_databases@p...>

Sent: Friday, January 11, 2002 3:26 PM

Subject: [asp_databases] Stored Procs vs SQL embedded in ASP page





> Hello,

> I have a form which has a dozen or so input fields, and currently I'm

> updating the back-end SQL database by generating the SQL on-the-fly (ie

> concatenating together the INSERT/UPDATE statement).  This works fine.  I

> now understand that stored procedures are generally a better way of doing

> things, but is this still the case if I'm creating lots of parameters and

> passing them along?  Is there some sort of upper-limit on parameters,

> where stored procs become slower and/or too clumsy (in terms of style)

> than other methods?

>

> TIA,

> Julio

>




$subst('Email.Unsub').