[Bush2000]

Please. There is no way that database statements embedded in code (which make programs harder to maintain, BTW - since you have to touch your code every time there is a database change) will run faster than compiled stored procedures.

Don't waste your time with Harr: It's obvious that he doesn't know what he's talking about. As you've correctly pointed out, stored procedures are faster precisely because they're precompiled and the SQL engine doesn't have to build a query plan -- it's done in advance, at the time you add the stored proc to the database. Likewise, stored procs are not susceptible to SQL injection attacks because all of the incoming data is considered literal and not part of the query semantics.

[Dominic Harr]

As you've correctly pointed out, stored procedures are faster precisely because they're precompiled and the SQL engine doesn't have to build a query plan -- it's done in advance, at the time you add the stored proc to the database.

You've never done any DB work, so you probably don't realize that the delay is the actual processing of the data. The DB has to build temporary tables and does all the number crunching in a very, very inefficient manner, processing data relationally.

In an language like C# or Java, you do number crunching in an OO manner, optimized to the specific report to be churned.

For any complex report, the DB will be the absolute slowest way to number crunch possible.