Showing posts with label procedures. Show all posts
Showing posts with label procedures. Show all posts

Sunday, March 25, 2012

Default DATE and uniqueidentifier parameters?

I have several stored procedures and to facilitate getting the output of the stored procedures we have been adding default values for all of the input parameters. This works fine with the exception of DATE and uniqueidentifier parameters. I have defined stored procedures like:

ALTER PROCEDURE [dbo].[proc_GetOrderReasonByOrderGroupId]

@.OrderGroupId uniqueidentifier = NEWID

AS

and

ALTER PROCEDURE [dbo].[proc_shippedPackages]

@.DateFrom datetime = GETDATE,

@.DateTo datetime = GETDATE

but when I execute the following

SET FMTONLY ON

exec proc_shippedPackages

SET FMTONLY OFF

I get

Msg 241, Level 16, State 1, Procedure proc_shippedPackages, Line 0

Conversion failed when converting datetime from character string.

Any suggestions? The same error occurs with setting a uniqueidentifier. I want to create a default parameter that will more of less ensure that the output is empty.

Thank you.

Kevin

You could try the example below.

Beware, though, that if you do need to explicitly set the values of the @.DateFrom and @.DateTo parameters to NULL when calling the stored procedure [as opposed to simply not providing values for these optional parameters] then the parameters will be assigned a value of GETDATE() during execution, which may or may not be what you want. If this does turn out to be a problem then you could use an arbitrary [but unlikely to be used] date as the default value and then check for that value rather than NULL when assigning the value of @.Now.

Chris

Code Snippet

CREATE PROCEDURE [dbo].[proc_shippedPackages]

@.DateFrom DATETIME = NULL,

@.DateTo DATETIME = NULL

AS

--Ensure that both variables are set to

--equal values if defaults are required.

DECLARE @.Now DATETIME

SET @.Now = GETDATE()

IF @.DateFrom IS NULL

BEGIN

SET @.DateFrom = @.Now

END

IF @.DateTo IS NULL

BEGIN

SET @.DateTo = @.Now

END

SELECT @.DateFrom, @.DateTo

GO

|||

It is not bad idea to have NON-NULL values, suppose if you need to store / pass the NULL value from your code the below code wont break.

Code Snippet

Alter PROCEDURE [dbo].[proc_GetOrderReasonByOrderGroupId]

@.OrderGroupId uniqueidentifier = 0x0

AS

Select@.OrderGroupId = Case When @.OrderGroupId = 0x0 Then NewId() Else @.OrderGroupId End

go

Alter PROCEDURE [dbo].[proc_shippedPackages]

@.DateFrom datetime = '1900-01-01 00:00:00.000',

@.DateTo datetime = '1900-01-01 00:00:00.000'

as

SET @.DateFrom = Case When @.DateFrom = '1900-01-01 00:00:00.000' Then GetDate() Else @.DateFrom End

SET @.DateTo = Case When @.DateTo = '1900-01-01 00:00:00.000' Then GetDate() Else @.DateTo End

|||GETDATE and NEWID are functions and require () after them, unlike VB. Try:

@.OrderGroupId uniqueidentifier = NEWID()


@.DateFrom datetime = GETDATE(),

@.DateTo datetime = GETDATE()

|||TPhillips -> You are wrong; SP params only support the constant/NULL value as default value.|||Yes, you are correct. Your method, mentioned earlier, is the way to fix this problem.

However, the () are still needed to execute the functions.

|||

Tom Phillips wrote:

Yes, you are correct. Your method, mentioned earlier, is the way to fix this problem.

However, the () are still needed to execute the functions.

If you check the syntax with the Sql Management Studio it complains if you add the ().

|||

Kevin,

You cannot use the NEWID() and GETDATE() functions as default values in the parameter definition.

DEFAULT value assignments must be deterministic. Non-deterministic functions are not permitted in that context.

If your intent is to make the parameters optional, use '01/01/1900' (or NULL), then in the first lines of the sproc, check the values and if = '01/01/1900' (or NULL), then set the values = getdate().

Your original attempt failed because you are setting the default values to the string constants 'GETDATE' and 'NEWID.

NEWID() and GETDATE() both require parentheses as previously mentioned.

|||

Tom Phillips wrote:

Yes, you are correct. Your method, mentioned earlier, is the way to fix this problem.

However, the () are still needed to execute the functions.

When I include the () I get:

Msg 102, Level 15, State 1, Procedure proc_GetCaseNotesByOrderGroupID, Line 4

Incorrect syntax near '('.

ALTER PROCEDURE [dbo].[proc_GetCaseNotesByOrderGroupID]

@.OrderGroupID uniqueidentifier = NEWID()

AS

|||As mentioned, you have to set the default to a "static", you cannot use a function on a default value.

What your code was doing without the () is equivalent to:

@.OrderGroupID uniqueidentifier = 'NEWID'


I assume you did not want the @.orderGroupID to be a string NEWID. I think this is a bug or at least hold over from Sybase which allows unquoted strings to be invisibly converted to a string.

The best way to do what you want is:

ALTER PROCEDURE [dbo].[proc_GetCaseNotesByOrderGroupID]

@.OrderGroupID uniqueidentifier = NULL -- or some other non-occurring number

AS

IF @.OrderGroupID IS NULL
SET @.OrderGroupID = NEWID()

sql

Wednesday, March 21, 2012

Decrypting Stored Procedures

We have a product that compares databases and generates the scripts to
synchronize them. Need to be able to compare encrypted Stored Procedures - is
there an official route for obtaining the information we need?
xSQL wrote:
> We have a product that compares databases and generates the scripts to
> synchronize them. Need to be able to compare encrypted Stored
> Procedures - is there an official route for obtaining the information
> we need?
Nothing official. They are encrypted, so the procedure text is not
available through normal means. You can decrypt the stored procedures
using some posted code available on the internet, but this will change
the system tables where the encrypted text is stored. There's no way to
read the encrypted text and decrypt on the fly as far as I know using a
schema comparison tool. Decrypting the procedures could be a violation
of any of a number of US and international laws if you are not the
owner.
David Gugick
Quest Software
www.imceda.com
www.quest.com

Decrypting Encrypted Views/Sp/Functions.....?

Hi all,
As all of you are aware you can Encrypt your Triggers/Stored Procedures/Views And Functions
in Sql Server with "WITH ENCRYPTION" clause.recently i came across a Stored procedure on the Net that could reverse and decrypt all Encrypted objects.i personally tested it and it really works.That's fine (of course for some body)
Now i want to know is it a Known Bug for Sql Server 2000 and is there a permanent solution for Encrypting mentioned objects.

Thanks in advance.
Best Regards.

Yes. No.|||

There are huge enhancements with Encrption/Decrption in SQL2005, you may take a look at this article:

http://www.sqlservercentral.com/columnists/mcoles/sql2005symmetricencryption.asp

Monday, March 19, 2012

Decrypt store procedures

Good Afternoon,
Does anybody knows how to decrypt store procedures?.
I really appreciate your help.
Frank
*** Sent via Developersdex http://www.examnotes.net ***
Don't just participate in USENET...get rewarded for it!You can find code to do this at many sites.
One place is:
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
-Sue
On Wed, 31 Mar 2004 11:01:15 -0800, Frank Garcia
<fjgarciag4@.hotmail.com.mx> wrote:

>Good Afternoon,
>Does anybody knows how to decrypt store procedures?.
>I really appreciate your help.
>Frank
>*** Sent via Developersdex http://www.examnotes.net ***
>Don't just participate in USENET...get rewarded for it!|||Frank Garcia wrote:
> Good Afternoon,
> Does anybody knows how to decrypt store procedures?.
See for example
Decrypt/Display Large SQL 2000 Stored Procedures v1.00.1
http://www.planet-source-code.com/U...cripts/ShowCode!asp/txtCodeId!7
28/lngWid!5/anyname.htm
sincerely,
--
Sebastian K. Zaklada
Skilled Software
http://www.skilledsoftware.com
This posting is provided "AS IS" with no warranties, and confers no rights.

Sunday, March 11, 2012

declare variables

New to stored procedures. Is it necessary to place a default value into a
variable at the time you declare it?
SAMPLE: “ @.Sec int = 100”
Can @.Sec just be declared?It can just be declared. It will default to NULL:
DECLARE @.SEC INT
SELECT @.SEC
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Rich" <Rich@.discussions.microsoft.com> wrote in message
news:10D3C4D8-9FD7-47E0-B77E-DD1C1A4EE8CA@.microsoft.com...
> New to stored procedures. Is it necessary to place a default value into a
> variable at the time you declare it?
> SAMPLE: " @.Sec int = 100"
> Can @.Sec just be declared?
>|||No, it is not necessary, but until you put a value into it, it's value will
be Null. This can bite you if it's a char() or varChar() because by defaul
t
(there's a setting to change this, but don't use it) the nulls propagate whe
n
you concatenate them... i.e.,
null + 'dsasdasd' is null
"Rich" wrote:

> New to stored procedures. Is it necessary to place a default value into a
> variable at the time you declare it?
> SAMPLE: “ @.Sec int = 100”
> Can @.Sec just be declared?
>|||"CBretana" <cbretana@.areteIndNOSPAM.com> wrote in message
news:548AE03F-A9DD-441E-98AD-5F7416492EB5@.microsoft.com...
> No, it is not necessary, but until you put a value into it, it's value
will
> be Null. This can bite you if it's a char() or varChar() because by
default
> (there's a setting to change this, but don't use it) the nulls propagate
when
> you concatenate them... i.e.,
> null + 'dsasdasd' is null
It's no different with numeric types:
SELECT CONVERT(INT, NULL) + 1
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||Ok, that is good but here is a second part to the question. If I place a
default value in the variable but then at run time, I have a agent that call
s
the stored procedure and pushes a value to it, will the value pushed in
always take priority over the default value?
"Rich" wrote:

> New to stored procedures. Is it necessary to place a default value into a
> variable at the time you declare it?
> SAMPLE: “ @.Sec int = 100”
> Can @.Sec just be declared?
>|||Are you talking about variables within the procedure, or paramaterss to the
procedure?
Variables within the proc, at any given point in code, will have whatever
value was last assigned (if any). Just like any other language. E.g:
DECLARE @.variable INT
-- @.variable is NULL
SET @.variable = 1
-- @.variable = 1
SET @.variable = 2
-- @.variable = 2
Parameters with a default value are different - if you pass the param to the
proc it will have the value you passed (including NULL); if you do not pass
the param it will have the default value. E.g:
CREATE PROC foo (@.i INT = 0) AS
BEGIN
SELECT @.i AS i
END
EXEC foo -- returns 0
EXEC foo @.i = 1 -- returns 1
EXEC foo @.i = NULL -- returns NULL
"Rich" wrote:
> Ok, that is good but here is a second part to the question. If I place a
> default value in the variable but then at run time, I have a agent that ca
lls
> the stored procedure and pushes a value to it, will the value pushed in
> always take priority over the default value?
> "Rich" wrote:
>|||Yes, If the parameter declaration in the Stored Proc has a default value,
and you nevertheless pass in a value, the passed in value will always take
pre3cedence over the default value.
This is true even When the Passed in value is Null, and teh default value
is somethiong other than Null...
"Rich" wrote:
> Ok, that is good but here is a second part to the question. If I place a
> default value in the variable but then at run time, I have a agent that ca
lls
> the stored procedure and pushes a value to it, will the value pushed in
> always take priority over the default value?
> "Rich" wrote:
>|||Hello CB,
perfect, I kind of tested that and found it to be true, I just wanted to
hear it from another programmer!
:)
"CBretana" wrote:
> Yes, If the parameter declaration in the Stored Proc has a default value,
> and you nevertheless pass in a value, the passed in value will always take
> pre3cedence over the default value.
> This is true even When the Passed in value is Null, and teh default value
> is somethiong other than Null...
> "Rich" wrote:
>

Friday, March 9, 2012

Declare @var?

I am trying to get a grasp on the Sql Stored procedures it seems i dont really understnad what DECLARE @.Date DateTime means? I mean i think it means that i am just declaring a varible name Date that will hold a DateTime Value? is that correct or is it more to it?

CREATE PROCEDURE dbo.Tracking_GetStatus
AS
DECLARE @.Date DateTime
DECLARE @.Begining DateTime
DECLARE @.Ending DateTime

SET @.Date = GETDATE()
SET @.Begining = DATEADD(ss,(DATEPART(ss,@.Date)*-1),
DATEADD(mi,(DATEPART(mi,@.Date)*-1),
DATEADD(hh,(DATEPART(hh,@.Date)*-1),@.Date)))
SET @.Ending = DATEADD(ss,-1,
DATEADD(dd,1,DATEADD(ss,(DATEPART(ss,@.Date)*-1),
DATEADD(mi,(DATEPART(mi,@.Date)*-1),
DATEADD(hh,(DATEPART(hh,@.Date)*-1),@.Date)))))

SELECT
Vehicl,
UpdateTi
XCoord,
YCoord,
Status
FROM Track
WHERE UpdateTime >= @.Begining
AND UpdateTime <= @.Ending
RETURN


GO

You are correct. The DECLARE statement declares variables in T-SQL. All variables MUST be declared, and they only are only scoped (available) to the procedure or batch in which they are declared. The variable will initially contain NULL as it's value and needs to be initialized for use, but you did that with each of your SET statements.

Everything looks fine. Are you having a problem?

Saturday, February 25, 2012

debugging with sql query analyzer, cannot get it to break

Using SQL Server 2000 SP3
I go into SQL Query Analyzer, expand Stored Procedures for my database,
right click the SP I want and select Debug...
It prompts me for the parameters. I enter them.
This seems to execute the procedure and give me @.RETURN_VALUE = 0.
I go through the procedure and set breakpoints at every line. I hit F5 for
GO and it runs right through it again and gives me the return value. It
does not break at my break points. The Step Into, Step Over, Step Out, and
Run to Cursor buttons are greyed out and the associated shortcuts don't work
either.
Anyone have an idea why I can't debug my SPs?
Thanks,
JamesIt's usually from a permissions issue. Take a look in BooksOnline under
"troubleshooting SQL Server, Transact-SQL debugger" and make sure to follow
all the steps.
--
Andrew J. Kelly
SQL Server MVP
"James" <capricorn@.nospam.com> wrote in message
news:Ojpa0yGsDHA.2252@.TK2MSFTNGP09.phx.gbl...
> Using SQL Server 2000 SP3
> I go into SQL Query Analyzer, expand Stored Procedures for my database,
> right click the SP I want and select Debug...
> It prompts me for the parameters. I enter them.
> This seems to execute the procedure and give me @.RETURN_VALUE = 0.
> I go through the procedure and set breakpoints at every line. I hit F5
for
> GO and it runs right through it again and gives me the return value. It
> does not break at my break points. The Step Into, Step Over, Step Out,
and
> Run to Cursor buttons are greyed out and the associated shortcuts don't
work
> either.
> Anyone have an idea why I can't debug my SPs?
> Thanks,
> James
>|||Hi James,
Thank you for using MSDN Newsgroup! It's my pleasure to assist you with this issue.
From your description, I understand that you met with some problem when debugging a stored
procedure.
As Andrew has point out that you should have proper permission when you perform a debug
on stored procedures in QA. The greyed out button symptom are mostly caused by this
permission issue, but I'm really puzzled (maybe it's also a permission issue) that the execution
didn't break at the break points you set in advance. So please ensure yourself the proper/full
permission first to see if you can debug the SP in a normal way.
Based on my experience, the symptom can also be casued by the duplicated store
procedure names.
If you have two stored procedures with the same name, one owned by the database owner
(DBO) and the other owned by a non-DBO user (for example, dbo.test_proc and
xyz.test_proc), when trying to debug the xyz.test_proc procedure, neither the DBO nor the xyz
user can step through the stored procedure using the T-SQL debugger from SQL Server 2000
Query Analyzer.
The stored procedure will execute immediately under the T-SQL debugger when run from
Query Analyzer. Breakpoints can be set after the first execution, but none of the step-through
buttons are available. The problem disappears after the DBO-owned stored procedure is
dropped, and reappears when it is re-created.
If this addresses your problem, you can use any of the following workaround:
1. Rename the stored procedure owned by the non-DBO user.
2. Write a wrapper stored procedure to call the stored procedure owned
by the non-DBO user, and use the T-SQL debugger to step into the called
procedure.
3. Use the debugger from Microsoft Visual Interdev instead of from Query
Analyzer.
James, please let us know if this helps solve your problem. If there is anything more we can
do to assist you, please feel free to post it in the group
Best regards,
Billy Yao
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||Replying to both Andrew and Billy,
First, I am the system Admin on the machine I am developing on and the
system where the database resides. When I am using Query Analyzer, I am the
same account that is the dbo that is sa and that created the stored
procedures. Andrew, I haven't gone through the list of things there is for
me to do that you pointed out yet, but I can't see how its a permissions
issue given that I have complete permissions on every machine and database
instance involved. I will look up the issue in Books Online that you
pointed out and see if that helps.
Billy, as noted above, I have full permissions when I am debugging in Query
Analyzer. Also, I know for a fact that there are no duplicated SP names.
All stored procedures are created by the same account. I've absolutely
confirmed that this can't be the problem.
I also can't use the Visual Studio .NET debugger to step into the procedure,
now that you bring it up. I get the following error message: "Cannot debug
stored procedure because the SQL Server database is not setup correctly or
user does not have permission to execute master.sp_sdidebug. Run SQL Server
setup or contact database administrator." In response to this error, first,
EVERYONE including guest and public has rights to execute
master.sp_sdidebug, and again, I am the dbo and sa, so permission can't
possibly be the problem. In addition, Visual Studio .NET Enterprise
Architect is setup on the server where SQL Server 2000 is installed WITH all
of the remote debugging options checked. I go through the documentation,
stepping through all the steps, even reinstalling software to let it
configure itself again, and I continue to get this error. This is why I
went to Query Analyzer to try to debug the SP and encountered the problem
that started this thread.
Any help would be greatly appreciated.
James
""Billy Yao [MSFT]"" <v-binyao@.online.microsoft.com> wrote in message
news:JEb7U0lsDHA.1248@.cpmsftngxa07.phx.gbl...
> Hi James,
> Thank you for using MSDN Newsgroup! It's my pleasure to assist you with
this issue.
> From your description, I understand that you met with some problem when
debugging a stored
> procedure.
> As Andrew has point out that you should have proper permission when you
perform a debug
> on stored procedures in QA. The greyed out button symptom are mostly
caused by this
> permission issue, but I'm really puzzled (maybe it's also a permission
issue) that the execution
> didn't break at the break points you set in advance. So please ensure
yourself the proper/full
> permission first to see if you can debug the SP in a normal way.
> Based on my experience, the symptom can also be casued by the duplicated
store
> procedure names.
> If you have two stored procedures with the same name, one owned by the
database owner
> (DBO) and the other owned by a non-DBO user (for example, dbo.test_proc
and
> xyz.test_proc), when trying to debug the xyz.test_proc procedure, neither
the DBO nor the xyz
> user can step through the stored procedure using the T-SQL debugger from
SQL Server 2000
> Query Analyzer.
> The stored procedure will execute immediately under the T-SQL debugger
when run from
> Query Analyzer. Breakpoints can be set after the first execution, but none
of the step-through
> buttons are available. The problem disappears after the DBO-owned stored
procedure is
> dropped, and reappears when it is re-created.
> If this addresses your problem, you can use any of the following
workaround:
> 1. Rename the stored procedure owned by the non-DBO user.
> 2. Write a wrapper stored procedure to call the stored procedure owned
> by the non-DBO user, and use the T-SQL debugger to step into the called
> procedure.
> 3. Use the debugger from Microsoft Visual Interdev instead of from Query
> Analyzer.
>
> James, please let us know if this helps solve your problem. If there is
anything more we can
> do to assist you, please feel free to post it in the group
>
> Best regards,
> Billy Yao
> Microsoft Online Support
> ----
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only. Thanks.
>
>|||Hello James,
Thanks for your update and the detailed information.
It seems that the issue is not related to permission and it'salso not a tool issue. Could you help
check the following article in case it addresses your problem:
329282 INFO: Minimum Permissions for Debugging Applications in Visual Studio
http://support.microsoft.com/?id=329282
170496 INF: Tips for Debugging Stored Procedures
http://support.microsoft.com/?id=170496
For more information on how to troubleshoot and debug stored procedures in Visual
Studio.NET, you can reference these step by step articles:
817178 INFO: Troubleshooting Tips for T-SQL Debugger in Visual Studio .NET
http://support.microsoft.com/?id=817178
316549 HOW TO: Debug Stored Procedures in Visual Studio .NET
http://support.microsoft.com/?id=316549
If there is anything more I can do to assist you, please feel free to post it in the group
Best regards,
Billy Yao
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.

Debugging TSQL Stored Procedures

Running SQL Server Express is there a way to debug TSQL stored procedures?I also have Visual Studio .NET 2003, can I use it to debug the TSQL stored procedures?

Thanks in advance,

Mark

No you need VS 2005 to debug SQL 2005.|||T-SQL Stored Procedure in 2005 can only be done with VSS 2005? Aargh

... I agree, this is a step backawards. Looking at my machien, I see

our company base install has included VSS, but it seems only for

Integration Services, Analysis Services and Reporting Services.

What do I need to do to get it to include the SQL 'component' into VSS?|||

I think you mis-read Euan's post, he said you need VS 2005, as in Visual Studio. Only one "S"; different that VSS for Visual Source Safe. Different thing altogether.

Mike

|||

I know ... you under-estimate the power of the typo and the rushing poster :-)

I was rushing the post, and didn't check what I was typing too clearly - a bad habit! I do know (and have used) Visual Source Safe ... and do have VS 2005 installed.

Now I just need to understand what I need to do to get it to open the SQL solution I have created - when I try to open projects, the extensions listed cover Integration Services, etc. etc. but not SQL project.

Thanks for trying to help me back onto the path - and again, sorry for the mistaken acronyms...

|||If you only have the BI Projects then you just have the BI version of VS, you need the Pro SKU or higher for SQL Projects.|||

Euan Garden wrote:

If you only have the BI Projects then you

just have the BI version of VS, you need the Pro SKU or higher for SQL

Projects.

Thanks Euan. Going to arrange that now.

Debugging T-SQL Codes

Hi,
How can I use query analyzer to debug my codes and stored procedures. I need
something like debug tools of VB(watching line by line execution). Are such
tools available for SQL server?
Thanks,
AminYes, for stored procedures., In Query Analyzer, Object Browser, right-click
the procedure and you'll find the debugger.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Amin Sobati" <amins@.morva.net> wrote in message
news:%23gTTEiECEHA.3788@.TK2MSFTNGP10.phx.gbl...
> Hi,
> How can I use query analyzer to debug my codes and stored procedures. I
need
> something like debug tools of VB(watching line by line execution). Are
such
> tools available for SQL server?
> Thanks,
> Amin
>|||In Query Analyzer, open the object browser. In the object
browser, go down to the stored procedures in a database,
select a stored procedure, right click and select debug.
-Sue
On Fri, 12 Mar 2004 19:12:08 +0430, "Amin Sobati"
<amins@.morva.net> wrote:

>Hi,
>How can I use query analyzer to debug my codes and stored procedures. I nee
d
>something like debug tools of VB(watching line by line execution). Are such
>tools available for SQL server?
>Thanks,
>Amin
>

Debugging triggers, how?

I could find that its possible to debug stored procedures in SQl server
2000, but did not find any place in BOL where it was explained if it was
even possible to debug (step through and verify values obtained as well as
detect programming errors other than syntax errors) triggers. Is it
possible, if so where do I find Info on how?
Thanks fir any help,
BobBob,
I believe the Transact-SQL Debugger does not work directly with triggers.
However, I believe I read somewhere that it will work if the stored
procedure is being debugged and it fires the trigger.
Other possible options may include embedding additional t-shooting code in
the trigger i.e., RAISERROR or SELECT (INSERTED/DELETED).
HTH
Jerry
"Bob" <bdufour@.sgiims.com> wrote in message
news:OSET%23QQ0FHA.460@.TK2MSFTNGP15.phx.gbl...
>I could find that its possible to debug stored procedures in SQl server
>2000, but did not find any place in BOL where it was explained if it was
>even possible to debug (step through and verify values obtained as well as
>detect programming errors other than syntax errors) triggers. Is it
>possible, if so where do I find Info on how?
> Thanks fir any help,
> Bob
>|||On Fri, 14 Oct 2005 17:13:09 -0400, Bob wrote:

>I could find that its possible to debug stored procedures in SQl server
>2000, but did not find any place in BOL where it was explained if it was
>even possible to debug (step through and verify values obtained as well as
>detect programming errors other than syntax errors) triggers. Is it
>possible, if so where do I find Info on how?
>Thanks fir any help,
>Bob
>
Hi Bob,
Jerry is right:
1. Create a procedure that performs an insert, update or delete that
would fire the trigger.
2. Debug the stored procedure
3. Step into the trigger.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Jerry is correct.
You can't debug triggers directly but if you are debugging a stored proc and
a trigger is fired, then it will step in debug mode inside the trigger.
Yosh
"Jerry Spivey" <jspivey@.vestas-awt.com> wrote in message
news:eURZtZQ0FHA.664@.tk2msftngp13.phx.gbl...
> Bob,
> I believe the Transact-SQL Debugger does not work directly with triggers.
> However, I believe I read somewhere that it will work if the stored
> procedure is being debugged and it fires the trigger.
> Other possible options may include embedding additional t-shooting code in
> the trigger i.e., RAISERROR or SELECT (INSERTED/DELETED).
> HTH
> Jerry
> "Bob" <bdufour@.sgiims.com> wrote in message
> news:OSET%23QQ0FHA.460@.TK2MSFTNGP15.phx.gbl...
>|||Excellent suggestion Hugo!
This would work perfectly.
Yosh
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:qnc0l1d6bke8sv0pcpl9feb1qbkmbjtumr@.
4ax.com...
> On Fri, 14 Oct 2005 17:13:09 -0400, Bob wrote:
>
> Hi Bob,
> Jerry is right:
> 1. Create a procedure that performs an insert, update or delete that
> would fire the trigger.
> 2. Debug the stored procedure
> 3. Step into the trigger.
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)|||Thank you all,
Bob
"Bob" <bdufour@.sgiims.com> wrote in message
news:OSET%23QQ0FHA.460@.TK2MSFTNGP15.phx.gbl...
>I could find that its possible to debug stored procedures in SQl server
>2000, but did not find any place in BOL where it was explained if it was
>even possible to debug (step through and verify values obtained as well as
>detect programming errors other than syntax errors) triggers. Is it
>possible, if so where do I find Info on how?
> Thanks fir any help,
> Bob
>

Debugging Tips and Help

Hi. I need some help or guidance for debugging stored procedures and
fuctions. I would say I have intermediate knowledge/skills but wanted
to know if anyone has any suggestions on how I can improve my skills.
I know that QA is the tool to use and like I said I do have knowledge
as I have a programming background but since I am new to sprocs I need
all the help I can get. :) So any and all assistance will be greatly
appreciated.
JulesHi
Once you have identified that the stored procedure is disfunctional, the
first step is usually to find out what parameters are being passed. The
easiest way to do that is to use SQL Profiler. Once you know the values to
put into the parameters, you can start QA. You may then want to paste the
stored procedure call from SQL profiler into a new windows and run it
"manually". Depending on whether you can easily spot the line of code causin
g
the problem or not (the error message may give a line number or some
information that allows you to track down what is wrong) you may find that
you want to step through the stored procedure and see more how the code is
traversed.
To do this you can run the debugger, by opening up the object browser window
(F8) and find the procedure required. Then right click the procedure and
choose debug from the menu. This will give you a dialog where you can put in
the values for the parameters, you then choose execute and the debugger
should stop at the first line of code inside the procedure. There are then
buttons to allow you to step over/step next etc..
HTH
John
"Jules" wrote:

> Hi. I need some help or guidance for debugging stored procedures and
> fuctions. I would say I have intermediate knowledge/skills but wanted
> to know if anyone has any suggestions on how I can improve my skills.
> I know that QA is the tool to use and like I said I do have knowledge
> as I have a programming background but since I am new to sprocs I need
> all the help I can get. :) So any and all assistance will be greatly
> appreciated.
> Jules
>|||John,
Thank you for helping me out and I will use your help as I think it
will be EXTREMELY beneficial to and for me!
Jules|||Hi
Glad to hear that, remember that books online is an extreemly useful source
of information. It is quite often worth browsing through and reading when yo
u
have a spare moment. If you don't have the latest version they can be
downloaded from
http://www.microsoft.com/sql/techin...000/books.mspx.
SQL Profiler is possibly is also a wonderful gem and quite often under used.
It is worth checking the different things you can log and what they mean. Yo
u
may want to see Tony's blog casts on http://www.sqlserverfaq.com/ for an
introduction to SQL Profiler. There is also one on the Index Tuning wizard..
.
John
"Jules" wrote:

> John,
> Thank you for helping me out and I will use your help as I think it
> will be EXTREMELY beneficial to and for me!
> Jules
>

Debugging Stored Procedures with Visual Studio.net has stopped working

Hi, I used to be able to debug stored procedures via Visual Studio.net 2003. However, this has stopped working. It does not produce an error just simply doesn't work anymore i.e. the breakpoints are by-passed.
I have the correct settings in the Debug configuration section. If any-one knows how to rectify this your help would be appreciated.
I have thought about re-installing the remote debugging functionality on the server. However, our Visual Studio.net discs are with a developer who is away at present.

Thanks in advance
LeeIf any-one else has the same problem, we've solved it. Here's how and why it happened.

We installed Service pack 3 of SQL server and overlooked some of the release notes. This installation was the culprit. To get debugging back working again we needed to execute the statement.

sp_sdidebug legacy_on

via Query Analyzer on our sql server.

Cheers
Lee|||Hi, i try to debug a store procedure in SQL Server. I do an example.
1.Open Server Explorer.

2.Under the Servers node in Server Explorer, expand the SQL Server machine name, expand the SQL Servers node, expand the SQL Server instance, expand the Northwind database node, and then expand the stored procedures node.

3.Right-click the CustOrderHist stored procedure and then click Step Into Stored Procedure.

4.The Run stored procedure dialog box opens, which lists the parameters of the stored procedure. Type ALFKI as the value for the @.CustomerID input parameter and then click OK.

5.In the Visual Studio design environment, a window opens that displays the text of the stored procedure. The first executable line of the stored procedure is highlighted. Press F11 to step through the stored procedure to completion.

6.In the Output window, the following message is displayed, which indicates successful execution:
The program 'SQL Debugger: T-SQL' has exited with code 0 (0x0)

But in step 5, the first executable line of the stored procedure is not highlighted, so I can't press F11 to step through.

Please help me

Debugging stored procedures in SQL2005

I am getting following error message while trying to step into stored procedue:

"Unable to start T-SQL Debugging. Could not connect to computer 'xxx'. The referenced account is currently locked out and may not be logged on to"

I use VS 2005 Professional edition. SQL Server Authentication is used to create data connection in Server Explored. SQL/CLR debugging is enabled for the connection. I followed all steps from this article:

Setting Up SQL Debugging http://msdn2.microsoft.com/en-us/library/s4sszxst(VS.80).aspx

Any help?

Thanks

Slava

It sounds like your password has expired. You can change your password using SQL Server management studio, or you can ask a system administrator to do it for you.

Debugging stored procedures in SQL 2000

Please can someone tell me how to get this working. It seems impossible.
I just want to debug my stored procedures remotely, from a client PC.
Surely I don't have to physically sit at the server to debug the stored
procedures?
Owen
http://www.binarybaby.co.uk :: home-made electronic musicCan't you term in?
At our office we use terminal services or remote desktop - of course it
depends on your network setup and permissions. You have to set up the
server to allow such connections as well.
Perhaps you could clarify what your specific situation is network wise.

Debugging stored procedures

I have complete error handling and printing the error after every insert or update statements or after calling another procedure.

But somehow when executing the proc it is not printing the error.

The query analyzer shows a general message 'Query batch completed with errors'

All the logic seems to be working properly, but this message is bothering me. Why is this message displayed if everything is run correctly [or] is something wrong ?

Example:

[code]

/*************************************************************
** Error Handling
**************************************************************/

SELECT @.rowcount = @.@.rowcount
,@.error = @.@.error
,@.short_msg = 'Error Creating MCTM. - AG_SP_FAC_MCTN_INSERT'
,@.long_msg = 'Error in executing proc AG_SP_FAC_MCTN_INSERT'
,@.resolution_msg = 'Stored procedure error. Contact Technical Support for fix'
,@.log_cd = 'AG.CONV.ERR' + convert(char,@.exec_seq_no)
,@.log_level = 'O'
,@.log_severity = 3

IF (@.error <> 0)
BEGIN

EXEC amgrp_conv..AG_SP_LOG
@.LOG_CD = @.log_cd
,@.LOG_DTM = @.log_dtm
,@.LOG_LEVEL = @.log_level
,@.LOG_SEVERITY = @.log_severity
,@.APP_NAME = @.app_name
,@.SHORT_MSG = @.short_msg
,@.LONG_MSG = @.long_msg
,@.RESOLUTION_MSG = @.resolution_msg
,@.MAIN_STORED_PROC_NAME = @.main_stored_proc_name
,@.STEP_STORED_PROC_NAME = @.step_stored_proc_name
,@.SYBASE_CD = @.error

PRINT 'ERROR=' + convert(varchar(255),@.error)

ROLLBACK TRANSACTION TRAN_PRAC_PAR
CLOSE prac_par_cursor
DEALLOCATE prac_par_cursor
RETURN @.failure

END

[/code]

IF (@.@.error <> 0) --this should be @.@.error @.error from previous statement is unreliable
BEGIN

EXEC amgrp_conv..AG_SP_LOG
@.LOG_CD = @.log_cd
,@.LOG_DTM = @.log_dtm
,@.LOG_LEVEL = @.log_level
,@.LOG_SEVERITY = @.log_severity
,@.APP_NAME = @.app_name
,@.SHORT_MSG = @.short_msg
,@.LONG_MSG = @.long_msg
,@.RESOLUTION_MSG = @.resolution_msg
,@.MAIN_STORED_PROC_NAME = @.main_stored_proc_name
,@.STEP_STORED_PROC_NAME = @.step_stored_proc_name
,@.SYBASE_CD = @.error

PRINT 'ERROR=' + convert(varchar(255),@.error)

ROLLBACK TRANSACTION TRAN_PRAC_PAR
CLOSE prac_par_cursor
DEALLOCATE prac_par_cursor
RETURN @.failure

END

|||

Not quite getting it.

Does this mean @.@.error may not return anything. My understanding is it will be '0' if success and any other number if its an error

In other words, the following doesn't work ?

declare @.error int

select @.error = @.@.error

if (@.error <> 0)

begin

end

|||

QUOTED:

Not quite getting it.

Does this mean @.@.error may not return anything. My understanding is it will be '0' if success and any other number if its an error

In other words, the following doesn't work ?

declare @.error int

select @.error = @.error + (other select clause ) --<-- what if the error lies in here

if (@.error <> 0)

begin

end

|||

thanks joeydj,

ok i see...

@.@.error is for select statements too ?

i can check the selects, but its a standard select as shown above and there seems to be no error there.

|||

thats a wild guess anyway.

|||

can you please check if this line is valid

,@.log_cd = 'AG.CONV.ERR' + convert(char,@.exec_seq_no)

|||

still not getting it try this. this one should do it.

hahaha

declare @.error int

select @.error=0

SELECT @.rowcount = @.@.rowcount
,@.error = @.@.error
,@.short_msg = 'Error Creating MCTM. - AG_SP_FAC_MCTN_INSERT'
,@.long_msg = 'Error in executing proc AG_SP_FAC_MCTN_INSERT'
,@.resolution_msg = 'Stored procedure error. Contact Technical Support for fix'
,@.log_cd = 'AG.CONV.ERR' + convert(char,@.exec_seq_no)
,@.log_level = 'O'
,@.log_severity = 3

IF (@.error <> 0)
BEGIN

EXEC amgrp_conv..AG_SP_LOG
@.LOG_CD = @.log_cd
,@.LOG_DTM = @.log_dtm
,@.LOG_LEVEL = @.log_level
,@.LOG_SEVERITY = @.log_severity
,@.APP_NAME = @.app_name
,@.SHORT_MSG = @.short_msg
,@.LONG_MSG = @.long_msg
,@.RESOLUTION_MSG = @.resolution_msg
,@.MAIN_STORED_PROC_NAME = @.main_stored_proc_name
,@.STEP_STORED_PROC_NAME = @.step_stored_proc_name
,@.SYBASE_CD = @.error

PRINT 'ERROR=' + convert(varchar(255),@.error)

ROLLBACK TRANSACTION TRAN_PRAC_PAR
CLOSE prac_par_cursor
DEALLOCATE prac_par_cursor
RETURN @.failure

END

debugging stored procedures

I have a user that is db_owner for the a database in development on a SQL 7
SP 4 server. The user is attempting to debug a stored procedure and getting
the error:
Server: Msg 229, Level 14, State 5, Procedure sp_sdidebug, Line 1
[Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE permission denied on
object 'sp_sdidebug', database 'master', owner 'dbo'.
I saw this error listed on the support site at
http://support.microsoft.com/default.aspx?scid=kb;en-us;328173&Product=sql2k
. The site says:
This behavior is a design change in SQL Server 2000 SP3 to enhance security.
This design change includes the following changes:
a.. A database users can only step into stored procedures that they own.
b.. A database owner (DBO) can debug any stored procedure in the database
that the DBO owns. (A DBO owns the database and, therefore, all its stored
procedures.)
c.. Members of the SysAdmin server role can debug any stored procedure in
any database on the server. (A member of the SysAdmin server role owns the
server and, therefore, all its databases.)
For more information about Transact-SQL Debugging, see the "Using
Transact-SQL Debugger" and "Troubleshooting the Transact-SQL Debugger"
topics in SQL Server Books Online.
Does the user need to be the dbo ( creator) of the database to get the
debugger to work and not just a member of db_owner role (this does not
appear to work)? Is there a work around so that my user can debug his
stored procedures without me having to debug every stored procedure for the
several development servers in house?I hope you have DB_DDLAdmin permissions on the database,
Just add your user account in the master database and
grant em Execute permissions to SP_SDIDEBUG system
procedure
HTH
Saleem Hakani
>--Original Message--
>I have a user that is db_owner for the a database in
development on a SQL 7
>SP 4 server. The user is attempting to debug a stored
procedure and getting
>the error:
>Server: Msg 229, Level 14, State 5, Procedure
sp_sdidebug, Line 1
>[Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE
permission denied on
>object 'sp_sdidebug', database 'master', owner 'dbo'.
>I saw this error listed on the support site at
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;328173&Product=sql2k
>.. The site says:
>This behavior is a design change in SQL Server 2000 SP3
to enhance security.
>This design change includes the following changes:
> a.. A database users can only step into stored
procedures that they own.
> b.. A database owner (DBO) can debug any stored
procedure in the database
>that the DBO owns. (A DBO owns the database and,
therefore, all its stored
>procedures.)
> c.. Members of the SysAdmin server role can debug any
stored procedure in
>any database on the server. (A member of the SysAdmin
server role owns the
>server and, therefore, all its databases.)
>For more information about Transact-SQL Debugging, see
the "Using
>Transact-SQL Debugger" and "Troubleshooting the Transact-
SQL Debugger"
>topics in SQL Server Books Online.
>Does the user need to be the dbo ( creator) of the
database to get the
>debugger to work and not just a member of db_owner role
(this does not
>appear to work)? Is there a work around so that my user
can debug his
>stored procedures without me having to debug every stored
procedure for the
>several development servers in house?
>
>.
>|||Hi,
You need to add the same user in Master database and then grant Execute
permission to that user on SP_SDIDEBUG procedure.
Thanks
Hari
MCDBA
"Stacy Hein" <sthein5@.rockwellcollins.com> wrote in message
news:ePOiKaO8DHA.3360@.tk2msftngp13.phx.gbl...
> I have a user that is db_owner for the a database in development on a SQL
7
> SP 4 server. The user is attempting to debug a stored procedure and
getting
> the error:
> Server: Msg 229, Level 14, State 5, Procedure sp_sdidebug, Line 1
> [Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE permission denied
on
> object 'sp_sdidebug', database 'master', owner 'dbo'.
> I saw this error listed on the support site at
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;328173&Product=sql2k
> . The site says:
> This behavior is a design change in SQL Server 2000 SP3 to enhance
security.
> This design change includes the following changes:
> a.. A database users can only step into stored procedures that they own.
> b.. A database owner (DBO) can debug any stored procedure in the
database
> that the DBO owns. (A DBO owns the database and, therefore, all its stored
> procedures.)
> c.. Members of the SysAdmin server role can debug any stored procedure
in
> any database on the server. (A member of the SysAdmin server role owns the
> server and, therefore, all its databases.)
> For more information about Transact-SQL Debugging, see the "Using
> Transact-SQL Debugger" and "Troubleshooting the Transact-SQL Debugger"
> topics in SQL Server Books Online.
> Does the user need to be the dbo ( creator) of the database to get the
> debugger to work and not just a member of db_owner role (this does not
> appear to work)? Is there a work around so that my user can debug his
> stored procedures without me having to debug every stored procedure for
the
> several development servers in house?
>
>|||Thanks for the input. That is the answer I already had. I was hoping there
was a less granular way to apply those permissions.
I set up a role for the debugging in the master database and assigned the
users to that.
Thanks again.
Stacy Hein
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:eMUInmR8DHA.360@.TK2MSFTNGP12.phx.gbl...
> Hi,
> You need to add the same user in Master database and then grant Execute
> permission to that user on SP_SDIDEBUG procedure.
> Thanks
> Hari
> MCDBA
> "Stacy Hein" <sthein5@.rockwellcollins.com> wrote in message
> news:ePOiKaO8DHA.3360@.tk2msftngp13.phx.gbl...
> > I have a user that is db_owner for the a database in development on a
SQL
> 7
> > SP 4 server. The user is attempting to debug a stored procedure and
> getting
> > the error:
> >
> > Server: Msg 229, Level 14, State 5, Procedure sp_sdidebug, Line 1
> > [Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE permission denied
> on
> > object 'sp_sdidebug', database 'master', owner 'dbo'.
> >
> > I saw this error listed on the support site at
> >
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;328173&Product=sql2k
> > . The site says:
> >
> > This behavior is a design change in SQL Server 2000 SP3 to enhance
> security.
> > This design change includes the following changes:
> > a.. A database users can only step into stored procedures that they
own.
> > b.. A database owner (DBO) can debug any stored procedure in the
> database
> > that the DBO owns. (A DBO owns the database and, therefore, all its
stored
> > procedures.)
> > c.. Members of the SysAdmin server role can debug any stored procedure
> in
> > any database on the server. (A member of the SysAdmin server role owns
the
> > server and, therefore, all its databases.)
> > For more information about Transact-SQL Debugging, see the "Using
> > Transact-SQL Debugger" and "Troubleshooting the Transact-SQL Debugger"
> > topics in SQL Server Books Online.
> >
> > Does the user need to be the dbo ( creator) of the database to get the
> > debugger to work and not just a member of db_owner role (this does not
> > appear to work)? Is there a work around so that my user can debug his
> > stored procedures without me having to debug every stored procedure for
> the
> > several development servers in house?
> >
> >
> >
>

debugging stored procedures

Hello,

I am doing a lot of work with stored procedures at work now and am wondering
if there is a way that I can step through the code line by line and set
breakpoints on it like I do in VB/VBA to test variables/parameters.

Regards,

JayneOn Tue, 08 Mar 2005 21:38:46 +0000, Little PussyCat wrote:

>I am doing a lot of work with stored procedures at work now and am wondering
>if there is a way that I can step through the code line by line and set
>breakpoints on it like I do in VB/VBA to test variables/parameters.

Hi Jayne,

In Query Analyzer, hit F8 to bring up the object browser. Find the
stored procedure, right-click it and select "Debug".

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)|||Hugo Kornelis (hugo@.pe_NO_rFact.in_SPAM_fo) writes:
> On Tue, 08 Mar 2005 21:38:46 +0000, Little PussyCat wrote:
>>I am doing a lot of work with stored procedures at work now and am
>>wondering if there is a way that I can step through the code line by
>>line and set breakpoints on it like I do in VB/VBA to test
>>variables/parameters.
> In Query Analyzer, hit F8 to bring up the object browser. Find the
> stored procedure, right-click it and select "Debug".

That's the theory.

In practice it appears that there is always something that prevents it
from working. To start with SQL Server must be running from a domain
account, and not local server. If you have Windows XP SP2 on the client,
you need at least 8.00.944 or the beta of SQL 2000 SP4, and you must
apply it on server and client. On top of that you must open port 135
in Windows firewall for the SQL box. (Do NOT open this port generally.)

And when all is done, you sysadm may get the idea that the Windows users
under which SQL Server runs is not permitted access to the workstations.
This how the last attempt ended in our shop.

I should add if you run SQL Server on your own machine, debugging
usually works.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||You can also step into T-SQL stored procs from the VB or .NET development
environment. But personally, I have not found stepping into stored procs to
be all that useful since I could not see a way to examine the result sets of
queries. I have found using SQL profiler to be extremely useful for seeing
what parameters the calling app is passing in and which statements are
getting executed within the procedure. However, I think you need SA rights
to run profiler. To examine the result sets of queries, I usually just run
the guts of the procedure in Query Analyzer and use select statements to
dump the intermediate results. .

"Little PussyCat" <SPAMSPAM@.NOSPAM.com> wrote in message
news:ccm1g2-n1c.ln1@.tiger.sphynx...
> Hello,
> I am doing a lot of work with stored procedures at work now and am
wondering
> if there is a way that I can step through the code line by line and set
> breakpoints on it like I do in VB/VBA to test variables/parameters.
> Regards,
> Jayne|||Miss Livvy (XeveryidiwantistakenX@.yahoo.com) writes:
> You can also step into T-SQL stored procs from the VB or .NET
> development environment. But personally, I have not found stepping into
> stored procs to be all that useful since I could not see a way to
> examine the result sets of queries.

Yeah, I agree. Occassionally if a I have procedure with lot of procedural
logic, single-stepping through it can be helpful. The same is true if
want to look at the values of some variables.

But often I find too much hassle to start the debugger, so I rather
modify the procedure with some debug SELECT:s in strategic places.

Also, if your procedure raises an error and you want to debug that
happens after the error, the debugger does not appear to be very
co-operative.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Debugging Stored Procedures

Hello,
I've recently upgraded to SQL2005 standard edition and
I'm struggling to find how to debug stored procedures.
I fire up the accompanying Visual Studio and goog-ahem
MSN search suggests that I need to start up a Database
Project. This is missing in my VS. What do I need to do to
get this template? Or is there another mechanism similar to
SQL2k's debug functionality?
Thanks,
John
Tibor Karaszi wrote:

> I believe you need a certain edition of VS, possibly Professional.
Hmm this is what I feared... how frustrating.
Thanks Tibor!
John
|||John Nolan wrote:

> Tibor Karaszi wrote:
>
> Hmm this is what I feared... how frustrating.
> Thanks Tibor!
> John
Does the Developer edition of SQL Server 2005 come with a VS
that includes the Database template?
I don't want to buy VS out right as its not my development
platform.

|||Tibor Karaszi wrote:

> I'm pretty certain that it doesn't. The only project types you get
> from the SQL Server installation are "Business Intelligence", things
> like Reporting Services, SSIS and Analysis Server. I can't say 100%
> as I do have "real" VS installed, but, again, I'm pretty certain of
> it...
Just to confirm that I've installed SQL Server 2005
Developer Edition and the Visual studio that comes with it
does not include the Database template.
It seems that in their wisdom Microsoft have deemed that
debugging database stored procedures out of the scope of
database developer.

debugging stored procedures

I have a user that is db_owner for the a database in development on a SQL 7
SP 4 server. The user is attempting to debug a stored procedure and getting
the error:
Server: Msg 229, Level 14, State 5, Procedure sp_sdidebug, Line 1
[Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE permission denied on
object 'sp_sdidebug', database 'master', owner 'dbo'.
I saw this error listed on the support site at
http://support.microsoft.com/defaul...3&Product=sql2k
. The site says:
This behavior is a design change in SQL Server 2000 SP3 to enhance security.
This design change includes the following changes:
a.. A database users can only step into stored procedures that they own.
b.. A database owner (DBO) can debug any stored procedure in the database
that the DBO owns. (A DBO owns the database and, therefore, all its stored
procedures.)
c.. Members of the SysAdmin server role can debug any stored procedure in
any database on the server. (A member of the SysAdmin server role owns the
server and, therefore, all its databases.)
For more information about Transact-SQL Debugging, see the "Using
Transact-SQL Debugger" and "Troubleshooting the Transact-SQL Debugger"
topics in SQL Server Books Online.
Does the user need to be the dbo ( creator) of the database to get the
debugger to work and not just a member of db_owner role (this does not
appear to work)? Is there a work around so that my user can debug his
stored procedures without me having to debug every stored procedure for the
several development servers in house?Hi,
You need to add the same user in Master database and then grant Execute
permission to that user on SP_SDIDEBUG procedure.
Thanks
Hari
MCDBA
"Stacy Hein" <sthein5@.rockwellcollins.com> wrote in message
news:ePOiKaO8DHA.3360@.tk2msftngp13.phx.gbl...
> I have a user that is db_owner for the a database in development on a SQL
7
> SP 4 server. The user is attempting to debug a stored procedure and
getting
> the error:
> Server: Msg 229, Level 14, State 5, Procedure sp_sdidebug, Line 1
> [Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE permission denied
on
> object 'sp_sdidebug', database 'master', owner 'dbo'.
> I saw this error listed on the support site at
>
http://support.microsoft.com/defaul...3&Product=sql2k
> . The site says:
> This behavior is a design change in SQL Server 2000 SP3 to enhance
security.
> This design change includes the following changes:
> a.. A database users can only step into stored procedures that they own.
> b.. A database owner (DBO) can debug any stored procedure in the
database
> that the DBO owns. (A DBO owns the database and, therefore, all its stored
> procedures.)
> c.. Members of the SysAdmin server role can debug any stored procedure
in
> any database on the server. (A member of the SysAdmin server role owns the
> server and, therefore, all its databases.)
> For more information about Transact-SQL Debugging, see the "Using
> Transact-SQL Debugger" and "Troubleshooting the Transact-SQL Debugger"
> topics in SQL Server Books Online.
> Does the user need to be the dbo ( creator) of the database to get the
> debugger to work and not just a member of db_owner role (this does not
> appear to work)? Is there a work around so that my user can debug his
> stored procedures without me having to debug every stored procedure for
the
> several development servers in house?
>
>|||Thanks for the input. That is the answer I already had. I was hoping there
was a less granular way to apply those permissions.
I set up a role for the debugging in the master database and assigned the
users to that.
Thanks again.
Stacy Hein
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:eMUInmR8DHA.360@.TK2MSFTNGP12.phx.gbl...
> Hi,
> You need to add the same user in Master database and then grant Execute
> permission to that user on SP_SDIDEBUG procedure.
> Thanks
> Hari
> MCDBA
> "Stacy Hein" <sthein5@.rockwellcollins.com> wrote in message
> news:ePOiKaO8DHA.3360@.tk2msftngp13.phx.gbl...
SQL
> 7
> getting
> on
>
http://support.microsoft.com/defaul...3&Product=sql2k
> security.
own.
> database
stored
> in
the
> the
>

Friday, February 24, 2012

debugging SQL stored procedure

Hi

I have a simple windows application which uses two stored procedures at the backend to fetch the data and display it in the grid of UI

I wanted to debug these stored procedures line by line like using run time storage dump for various variable and statements used in the procedures as we do it in Visual studio using functional keys etc.

or

Any way to do this using SQL server 2000 query analyzer? The stored procedures contains nearly five hundred lines of code in sql.

Early reply is much appreciated.

Thanks!

In query analyzer, show object browser. then select your stored proc, and right click.

Select debug.

For more, look at this article http://www.15seconds.com/Issue/050106.htm

|||

Thanks for your help. This debug option is not available in sql2k5. I do not see any debug option available for sql2k5 when I right click the stored proc. Is there any option to do in sql2k5?

Thanks!

Santhosh