[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 432
  • Last Modified:

sp_executesql

current proc:
exec database.dbo.procname @parm1='A', @parm2='XC', @parm3='dv1', @parm4='CC', @parm5=date
the parms are all optional, if the proc is fired w/out parms, i am just returning top 50 from max date available

syntactically, what is the correct way to use sp_exeuctesql to fire this procedure, as opposed to simply exec ?
0
dbaSQL
Asked:
dbaSQL
  • 3
  • 2
2 Solutions
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
you have to note the differences:

EXEC something
-> something needs to be a procedure name

EXEC ('sql')
-> will run the sql statement

exec sp_Executesql N'sql'
-> will run the sql statement


so, to run a procedure, you have only 1 option, unless you want to do like this:
exec sp_Executesql N' exec your_procedure '
which would be "nonsense"...
0
 
Ashish PatelCommented:
so you mean you want to execute a procedure using he sp_executesql ?
0
 
Ashish PatelCommented:
In other words: Why do you want to use sp_executesql here? Why not just execute the procedure, as
is?

I agree with angelIII
0
[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

 
dbaSQLAuthor Commented:
hmmm... ok.  then this is of no use.  i have a rather large table, against which only 1 procedure (aside from all my back end maintenance stuff) is run.  one day, all combinations of the optional parms come back lightening quick, perfectly.  the very next day, they come back 10 to 12 to 15 minutes greater in runtime.  next day, lighteninq quick yet again.  next day, runtimes are in the pooper.  
i figure it must be my indices, yet every single version of the proc I mentioned up there, when fired against the index tuning wizard against comes back saying
'No index recommendations for the workload and the chosen parameters.'

there is no fragmentation whatsoever, scan density is 100%, 'no indexes are recommended'
absolutely nothing is hitting this database except me
sp_who2 gives me no blkby, nothing runnable, everything quiet, so to speak
still, the procedure is taking for-freaking-ever to come back to me

so, i hit this page: http://www.sql-server-performance.com/tips/stored_procedures_p3.aspx
and am reading gup about the use of sp_executesql over EXEC

now, i'm not at all sure how to proceed

angelll, do you have any suggestions, or direction?
this is horribly, horribly pressing.  we put all this time into development, the proc was super, everything looked great, they deployed.  and now, nobody can use it, everybody is looking at me
0
 
dbaSQLAuthor Commented:
potentially i misinterpretted the read on sp_executesql.  that's the reason for this post.  still, are either of you able to advise?  be it indices, procedure, i'm not sure.  everything by itself looks fine.  but collectively, something is messing w/me now, and i cannot determine the reason for these hugely increased procedure runtimes
0
 
dbaSQLAuthor Commented:
well, my problem more than persists.  but, i think it is outside the sp_executesql bo, as you both have clarified for me.  i will award and close.
thank you for the input
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now