Inspired by the topic above I did a little testing. My idea was to move the database stuff (including strsql building) to a function possibly in a file called inc_sp_functions.asp e.g.
function getCategories
select case strDBType
case “access” ‘build strsql and execute
case “mysql” ‘build strsql and execute
case “sqlserver” ‘don’t build strsql – execute stored procedure instead
end select
As a first step I created about 12 stored procedures (some dynamic but mostly not) which was easy enough to do for default.asp, active.asp, inc_header.asp and search.asp.
For testing purposes, to execute the stored procedures I didn’t change the current code very much, just changed strsql to database.dbo.sproc_name e.g.
As far as I can see getrows is as fast as stored procedures on the forum above and the only real benefit would be the separation of the database specific code from the rest of the forum code.
Note that Getrows and Stored procedures are two very different things. Stored Procedures speed up (sometimes) how quickly the database can collect together the information you request in your query - whereas Getrows speeds up (sometimes) the way ASP handles the data that comes back from the database.
IMO, both only start to produce tangeable speed advantages where large amounts of data are collated (in database) and handled (in ASP). Unless your forums are very large, then I'd be surprised if you saw any benefits.