Nope, I can't share it due to policy reasons.
But in a general case, the SP performance itself isn't so much the problem (at least not when I execute it from within SSMS).
Why would dynamic SQL perform better?
/F
I have an SP that takes 23 parameters, and the result set depends (of course) on the parameters.
In this particular scenario (i.e. with a specific set of values for the parameters) the SP returns 30 000 rows, with around 150 columns.
When I run the SP directly from the query window in SSMS, the SP executes at around 50 secs (completely, with output result in the result window). The "Reads" columns in the profiles states 1927431 reads.
When I execute the SP from VB.NET, it now takes more than 20 minutes, and the "Reads" column states a much greater value (unfortunately I don't have right now, but it's at least 100 times greater).
In VB.NET, I call ExecuteReader. For testing purposes, I have removed the code that iterates over the IDataReader which is returned. In other words, I dont pull much data from SQL Server to the VB.NET process (or at least that's the way I think it works).
The VB.NET executable lives on the same machine as SQL Server, whereas SSMS and SQL Server are on different machines (separated with a slow network)
Note that I THINK that the call from VB.NET sometimes executes at around the same time as from within SSMS (under a minute). I am not sure, since I haven't worked with this code for long myself.
Any ideas what can cause the performance difference?
Perhaps I am completely wrong, but to me it looks like SQL Server picks different execution plans, when I perform the call from SSMS v.s. when I call from VB.NET. (Because of the big difference in number of reads).
Thanks!
/Fredrik
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
see if that can help: http://omnibuzz-sql.blogsp
acperkins: I agree that the amount of data being returned is large, but there isn't much I can do about it without modifying the client code and that is not feasable.
Still, 50 seconds is ok for our use of the SP (it runs in a batch over-night) but 20 minutes is not.
I still don't understand why it takes so much longer to run exactly the same SP from ADO.NET compared to running from SSMS. Also, I still don't know why dynamic SQL would help. And, not so important perhaps, I don't know what SOL means...
Thanks anyway,
Fredrik
emoreau: Thanks for the link, interesting. I will try the work-around when I get a chance (Monday). I doubt it will help though, since when I run the same SP with the same values of the parameters from SSMS it is so much faster than from ADO.NET. To me, it doesn't look like that is the same problem described in the article. Can't hurt to try it, though.
/Fredrik
emoreau: The times compared should be reasonably compatible. The code in VB.NET is basically this
- Start timer
- ExecuteReader
- Stop timer
And, since the ExecuteReader returns a forward-only cursor, I assume that the measured time is between the start of the SP to (approximately) the time the first row of data is available.
BTW, I am not loading the data into a datagrid, this is a non-visual application that analyses the data.
Actually, I don't think that is the way it works - the ExecuteReader represents a stream of data. When the client calls Next, data is pulled from SQL Server (with some buffering). That's why the reader's connection is not available for other operations until Close is called.
Anyway, it really doesn't matter. The time to execute AND return all data in SSMS is much less than the time to execute and return a fraction of the data.
The problem was indeed a cached plan which, for some combinations of the values of the SP parameters, was very inefficient.
I added WITH RECOMPILE to the SP, which took the execution time from both SSMS and VB.NET down to ~40 seconds. The extra overhead of recompiling the SP each execution is minimal, about 10 ms.
Business Accounts
Answer for Membership
by: aneeshattingalPosted on 2009-11-06 at 06:37:24ID: 25759423
can you paste the sp here , if you can change the sp to use dynamic sql it will perforrm better