SQL Server 2005 stored procedure fast in SSMS slow from VBA

Question

I have a stored procedure which when run from SQL Server Management Studio consistently takes 5 seconds to run when called like this.

exec dbo.MyStoredProc           


        

Answer 1

I believe I have the same problem as Steve Homer. In addition to this SO question I also found this thread on eggheadcafe.com Very slow SP execution when using .net - very fast in Management Studio - totico

The answers say it's about parameter sniffing and how that affects which execution plan is used. The answers there specifically mentions the arithabort set option and how that affects the selection of plan.

Now I just need to find out how to change the set options from VBA...

Finally thanks to this forum entry on social.msdn.com i managed to get it right. First, set multiple connections to false:

connectionObject.Properties("Multiple Connections") = False

and then use the following function on your connection to set arithabort on ...

Private Sub OptionSet(ByRef cnn As adodb.Connection)
  Dim cmd As adodb.Command

  Set cmd = New adodb.Command
  With cmd
    Set .ActiveConnection = cnn
    .CommandType = adodb.CommandTypeEnum.adCmdText
    .CommandText = "set arithabort on"
    Call .Execute
  End With
  Set cmd = Nothing
End Sub

Answer 2

Thanks I'll take a look at the trace tools.

In reply to the comments on the original question

Are you using the exact same parameter values?

Yes exactly the same.

How much data is being returned (roughly) - number of rows and columns (and are any of them particularly big)?

Under 200 rows, perhaps 15 fields mostly ints with a couple of 20 character varchars.

Can you run SQL profiler and confirm if the sql is the issue or the remains of the macro in excel ?

The SQL is pretty ugly, as is the underlying database schema, and unfortunately is under NDA so I can't post it. If the query were the issue then wouldn't it be slow in management studio too though?

Answer 3

Everything you need to know about this topic: Slow in the Application, Fast in SSMS? Understanding Performance Mysteries

Answer 4

Use SQL Server Profiler

• Set up a trace on your database.
• Limit the trace only to the stored procedure object in question
• Limit to the username used by the VBA code

An introduction to SQL Server Profiler

In particular, check the SET options used by the connection and compare these with the defaults used when running the stored procedure in SSMS.

I have come across scenarios before where the SET options were different between calling code and within SSMS and the difference in performance was HUGE.