ARGH! - SQL Debugging in the IDE

L

Luther Miller

I am trying to get SQL Debugging working in VS.NET 2003 so that I can
step into stored procedures. I have gotten this to work in the past on
another machine, but I am not having luck with this one yet.

* Windows XP Pro
* VS.NET 2003
* SQL Server 2000 SP3a and most recent patch
* Query Analyzer stored proc debugger works perfectly (I can step
through code)
* Step Into ... does NOT work from VS.NET IDE
* Breakpoints are not hit in stored procs either... they become
question marks when I run and the tooltip text says "The breakpoint
will not currently be hit. Unable to bind SQL breakpoint at this time.
Object containing the breakpoint not loaded."
* I have followed ALL instructions in the help under "Setting up SQL
Debugging" -- http://msdn.microsoft.com/library/d...s/vsdebug/html/vxlrfsettingupsqldebugging.asp
* I have followed ALL instructions in the help under "SQL Debugging
Setup Errors and Troubleshooting" --
http://msdn.microsoft.com/library/d...ngsqldebuggingsetuperrorreportingonserver.asp
* I have granted myself EXEC permissions on sp_sdidebug -- GRANT EXEC
on master..sp_sdidebug to [MYDOMAIN\ME]
* I have run -- exec sp_sdidebug 'legacy on'
* Of course SQL Debugging is turned on ....

Grrr.... anyone have any more ideas?
 
W

William \(Bill\) Vaughn

I'm having the same problem and I'm at a loss as to what to do next. Oops, I
forgot to get the Brahman Priest to bless the system. Perhaps that's it.

I was able to get it to work on the host system (running the SS) after
setting the exec sp_sdidebug 'legacy on', but it still does not work on a
workstation connected to the server on the same domain.

http://support.microsoft.com/?id=328151 was helpful... but did not solve
the problem.

MS, if you are listening (and I know you are... ;) ) the MSDN online content
is stuffed with KB articles on this--but too many of them focus on old
(sometimes very old) versions of SQL Server. They need to be cleaned out or
marked more clearly as to which version they're trying to discuss.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
M

Mark Pearce

Hi Luther,

Here's a SQL debugging checklist that I've found useful - I've removed the
sections that you've already covered in your post:

* Sqlle.dll and sqldbreg2.exe must exist on your debugging workstation. The
former library is the SQL language engine for the debugger.
* Sqldbg.dll must exist on both the database server and the debugging
work-station. This library is the SQL debugging proxy.
* Mssdi98.dll must exist in the \binn subfolder of every SQL Server instance
on the database server.
* If you're running the full version of SQL Server, Visual Studio installs a
version of mssdi98.dll in the appropriate location, correctly overwriting
the version that SQL Server installs by default. If you're using the desktop
edition of SQL Server 2000 together with the Professional version of Visual
Studio, the Professional edition of Visual Studio doesn't install
mssdi98.dll in the correct folder. Instead, you need to copy the library
manually to the \binn folder of every SQL Server instance on the database
server.
* In addition, if Visual Studio isn't installed on the same machine as the
desktop edition of SQL Server, you should copy sqldbg.dll to the following
folder on the SQL Server machine:
\Program Files \Common Files \Microsoft Shared \SQL Debugging
Once you've copied this library to the correct location, you need to
register it with the following command at the command line:
regsvr32.exe sqldbg.dll
* You might also want to check that your domain account has permission to
the master database itself. It's not unknown for a DBA to give permission to
the sp_sdidebug stored procedure, but not to the master database.
* Remember that the sp_sdidebug 'legacy on' switch isn't persistent - you
need to re-execute this every time you reboot your SQL Server.
* You should turn on SQL debugging for every project in your VS solution -
this seems to be a regular VS problematical quirk.
* Debugging a stored procedure may not work more than once if connection
pooling is being used, which is the default behaviour. Connection pooling
attempts to improve performance by keeping old database connections in a
pool for potential reuse later. However, if a database connection is reused,
SQL debugging is not re-enabled on that connection. To avoid this
limitation, you can disable pooling by setting the Pooling switch in the
database connection string to false.

HTH,

Mark
--
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128


I am trying to get SQL Debugging working in VS.NET 2003 so that I can
step into stored procedures. I have gotten this to work in the past on
another machine, but I am not having luck with this one yet.

* Windows XP Pro
* VS.NET 2003
* SQL Server 2000 SP3a and most recent patch
* Query Analyzer stored proc debugger works perfectly (I can step
through code)
* Step Into ... does NOT work from VS.NET IDE
* Breakpoints are not hit in stored procs either... they become
question marks when I run and the tooltip text says "The breakpoint
will not currently be hit. Unable to bind SQL breakpoint at this time.
Object containing the breakpoint not loaded."
* I have followed ALL instructions in the help under "Setting up SQL
Debugging" --
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/vxlrfsettingupsqldebugging.asp
* I have followed ALL instructions in the help under "SQL Debugging
Setup Errors and Troubleshooting" --
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/vxtbstroubleshootingsqldebuggingsetuperrorreportingonserver.asp
* I have granted myself EXEC permissions on sp_sdidebug -- GRANT EXEC
on master..sp_sdidebug to [MYDOMAIN\ME]
* I have run -- exec sp_sdidebug 'legacy on'
* Of course SQL Debugging is turned on ....

Grrr.... anyone have any more ideas?
 
W

William \(Bill\) Vaughn

Thanks. There are a couple of points here that are new to me. I can see that
I need to lobby the MS team to get that "feature" turned off. I can easily
see how a connection can be orphaned and replaced during debugging.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Mark Pearce said:
Hi Luther,

Here's a SQL debugging checklist that I've found useful - I've removed the
sections that you've already covered in your post:

* Sqlle.dll and sqldbreg2.exe must exist on your debugging workstation. The
former library is the SQL language engine for the debugger.
* Sqldbg.dll must exist on both the database server and the debugging
work-station. This library is the SQL debugging proxy.
* Mssdi98.dll must exist in the \binn subfolder of every SQL Server instance
on the database server.
* If you're running the full version of SQL Server, Visual Studio installs a
version of mssdi98.dll in the appropriate location, correctly overwriting
the version that SQL Server installs by default. If you're using the desktop
edition of SQL Server 2000 together with the Professional version of Visual
Studio, the Professional edition of Visual Studio doesn't install
mssdi98.dll in the correct folder. Instead, you need to copy the library
manually to the \binn folder of every SQL Server instance on the database
server.
* In addition, if Visual Studio isn't installed on the same machine as the
desktop edition of SQL Server, you should copy sqldbg.dll to the following
folder on the SQL Server machine:
\Program Files \Common Files \Microsoft Shared \SQL Debugging
Once you've copied this library to the correct location, you need to
register it with the following command at the command line:
regsvr32.exe sqldbg.dll
* You might also want to check that your domain account has permission to
the master database itself. It's not unknown for a DBA to give permission to
the sp_sdidebug stored procedure, but not to the master database.
* Remember that the sp_sdidebug 'legacy on' switch isn't persistent - you
need to re-execute this every time you reboot your SQL Server.
* You should turn on SQL debugging for every project in your VS solution -
this seems to be a regular VS problematical quirk.
* Debugging a stored procedure may not work more than once if connection
pooling is being used, which is the default behaviour. Connection pooling
attempts to improve performance by keeping old database connections in a
pool for potential reuse later. However, if a database connection is reused,
SQL debugging is not re-enabled on that connection. To avoid this
limitation, you can disable pooling by setting the Pooling switch in the
database connection string to false.

HTH,

Mark
--
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128


I am trying to get SQL Debugging working in VS.NET 2003 so that I can
step into stored procedures. I have gotten this to work in the past on
another machine, but I am not having luck with this one yet.

* Windows XP Pro
* VS.NET 2003
* SQL Server 2000 SP3a and most recent patch
* Query Analyzer stored proc debugger works perfectly (I can step
through code)
* Step Into ... does NOT work from VS.NET IDE
* Breakpoints are not hit in stored procs either... they become
question marks when I run and the tooltip text says "The breakpoint
will not currently be hit. Unable to bind SQL breakpoint at this time.
Object containing the breakpoint not loaded."
* I have followed ALL instructions in the help under "Setting up SQL
Debugging" --
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/vxlrfsettingupsqldebugging.asp
* I have followed ALL instructions in the help under "SQL Debugging
Setup Errors and Troubleshooting" --
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/vxtbstroubleshootingsqldebuggingsetuperrorreportingonserver.asp
* I have granted myself EXEC permissions on sp_sdidebug -- GRANT EXEC
on master..sp_sdidebug to [MYDOMAIN\ME]
* I have run -- exec sp_sdidebug 'legacy on'
* Of course SQL Debugging is turned on ....

Grrr.... anyone have any more ideas?
 
F

Frank

I had the same problem,after i read the link
http://support.microsoft.com/?id=328151
everything works fine. If i understood VS.NET 2003 is an old
client an could not connect anymore without setting

Exec sp_sdidebug 'legacy_on'
to the sqlserver, right?
That i didn't found some information earlier is a suprise, everyone
who installed SP 3 should have the same trouble. That newsgroup isn't
full of messages, or this happens only on some machines? What
i want to know is if everybody who installed SP3 has these troubles and
must execthis stored procedure?

Frank
--
---------------------------
To send an eMail remove NOSPAM
William (Bill) Vaughn said:
I'm having the same problem and I'm at a loss as to what to do next. Oops, I
forgot to get the Brahman Priest to bless the system. Perhaps that's it.

I was able to get it to work on the host system (running the SS) after
setting the exec sp_sdidebug 'legacy on', but it still does not work on a
workstation connected to the server on the same domain.

http://support.microsoft.com/?id=328151 was helpful... but did not solve
the problem.

MS, if you are listening (and I know you are... ;) ) the MSDN online content
is stuffed with KB articles on this--but too many of them focus on old
(sometimes very old) versions of SQL Server. They need to be cleaned out or
marked more clearly as to which version they're trying to discuss.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Luther Miller said:
I am trying to get SQL Debugging working in VS.NET 2003 so that I can
step into stored procedures. I have gotten this to work in the past on
another machine, but I am not having luck with this one yet.

* Windows XP Pro
* VS.NET 2003
* SQL Server 2000 SP3a and most recent patch
* Query Analyzer stored proc debugger works perfectly (I can step
through code)
* Step Into ... does NOT work from VS.NET IDE
* Breakpoints are not hit in stored procs either... they become
question marks when I run and the tooltip text says "The breakpoint
will not currently be hit. Unable to bind SQL breakpoint at this time.
Object containing the breakpoint not loaded."
* I have followed ALL instructions in the help under "Setting up SQL
Debugging" --
http://msdn.microsoft.com/library/d...s/vsdebug/html/vxlrfsettingupsqldebugging.asp
* I have followed ALL instructions in the help under "SQL Debugging
Setup Errors and Troubleshooting" --
http://msdn.microsoft.com/library/d...ngsqldebuggingsetuperrorreportingonserver.asp
* I have granted myself EXEC permissions on sp_sdidebug -- GRANT EXEC
on master..sp_sdidebug to [MYDOMAIN\ME]
* I have run -- exec sp_sdidebug 'legacy on'
* Of course SQL Debugging is turned on ....

Grrr.... anyone have any more ideas?
 
W

William \(Bill\) Vaughn

Right. The new security restrictions in SP3 brought this on. It was about
time they made those changes. We'll see that trend continue in the future as
the security leaks are plugged.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Frank said:
I had the same problem,after i read the link
http://support.microsoft.com/?id=328151
everything works fine. If i understood VS.NET 2003 is an old
client an could not connect anymore without setting

Exec sp_sdidebug 'legacy_on'
to the sqlserver, right?
That i didn't found some information earlier is a suprise, everyone
who installed SP 3 should have the same trouble. That newsgroup isn't
full of messages, or this happens only on some machines? What
i want to know is if everybody who installed SP3 has these troubles and
must execthis stored procedure?

Frank
--
---------------------------
To send an eMail remove NOSPAM
I'm having the same problem and I'm at a loss as to what to do next.
Oops,
I
forgot to get the Brahman Priest to bless the system. Perhaps that's it.

I was able to get it to work on the host system (running the SS) after
setting the exec sp_sdidebug 'legacy on', but it still does not work on a
workstation connected to the server on the same domain.

http://support.microsoft.com/?id=328151 was helpful... but did not solve
the problem.

MS, if you are listening (and I know you are... ;) ) the MSDN online content
is stuffed with KB articles on this--but too many of them focus on old
(sometimes very old) versions of SQL Server. They need to be cleaned out or
marked more clearly as to which version they're trying to discuss.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
http://msdn.microsoft.com/library/d...ngsqldebuggingsetuperrorreportingonserver.asp
* I have granted myself EXEC permissions on sp_sdidebug -- GRANT EXEC
on master..sp_sdidebug to [MYDOMAIN\ME]
* I have run -- exec sp_sdidebug 'legacy on'
* Of course SQL Debugging is turned on ....

Grrr.... anyone have any more ideas?
 
C

Chip Johansen

I am having the exact same symptoms as listed by Luther below and have same
machine setup expect that I am running Win2000 Server sp3 and VS.Net 2003
and Sql 200 sp3 all on same machine.

I have tried all of the suggestions listed by all of the posters in this
section and have verified that all files are where they should be, all
proper permissions have been granted and Sql Debugging is turned on for my
project. I have wasted almost a full day and at a point where I am about to
give up and say "sql debugging does not work yet in VS.Net 2003 and Sql
2000, maybe in next version of IDE and Sql...".

If anyone has been in this same situation and actually found a remedy for it
I would greatly appreciate it.
 
L

Luther Miller

Well, if its any consolation, I STILL haven't gotten it to work. I had
it working with VS2002 about a year ago... but that doesn't do either
of us any good now.
 
C

Chip Johansen

Thanks for the reply Luther. I have not gotten it to work either and have
given up on it at this point. Maybe it will work in Whidbey.
 
C

Chip Johansen

Thanks Eric, but that is one of the previous suggestions I have already
tried. There were a lot of very good suggestions and I have tried them all
and it still doesn't work. Someone had suggested that the sql debugging
won't work if the IDE and Sql are on the same machine. I have not tried
connecting from another machine yet but who knows?
 
L

Luther Miller

This is, in fact, one of the 500 things I have tried in order to get
this working again. Thanks for the though, but unfortunately it didn't
seem to help ;-(
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top