[quoted text, click to view]

Hi Bob,

As GregO writes, the debugging feature that was included in SQL Server
2000 has been removed from SQL Server 2005. The support is still there,
but you have to use Visual Studio 2005 Pro or Team Suite to use it.

I entered a suggestion on the Microsoft's Product Feedback Center to
bring back the debugging feature in SQL Server. If you feel that this is
important, then let Microsoft know by voting for it. Here's a link
(warning - may wrap due to length)

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK41174

Best, Hugo
--

[quoted text, click to view]

Actually, I'm quite happy with the debugging capabilities in VS2005.

The only thing that really bothers me is that I have my project code in
SSMS, but VS2005 does give you the ability to edit stored procs right from
the database. Maybe if TFS ever gets released, and we can get our hands on
one, I can convince my colleagues to store all of our SQL code in TFS.

I had to adopt a 'practice' to only edit code in my project library and
always run ALTER PROCs to apply the changes. Obviously this is a good thing;
it just took me a moment of awareness, and discipline, to not take the easy
way out by just editing right there in VS2005 while I was debugging.

However, one caveat... there does seem to be some stability problems in
VS2005 in terms of terminating the debugging process. I haven't sorted that
out yet, or even researched it, but it became easier to just let the proc
abend, than to try to terminate the proc when I hit a piece of defective
code.

I just haven't found a way to run queries against the stored proc in debug
mode. Would surely have been nice the past few days to have been able to
query my temp tables while sitting at a breakpoint.

Hi Bob,
You can only debug TSQL or CLR stored procedures from Visual Studio 2005 Pro
or Team Suite. You can not debug from the Management studio or from Visual
Studio 2005 STD.


As to weither or not to use CLR for your stored procedure, that depends on
the type of SP. If you are doing set based operations then you should stay
with TSQl. But if you are doing procedural type functions then you may find
that CLR out performs TSQL


--
kind regards
Greg O
-------
Looking to use CLR in SQL 2005. Try some pre-build CLR Functions and SP
AGS SQL 2005 Utilities, over 20+ functions
http://www.ag-software.com/?tabid=38
[quoted text, click to view]

[quoted text, click to view]

Hi Lawrence,

And I am quite happy with the debugging capabilities in SQL Server 2000.
But when I get around to upgrading to SQL Server 2005, I expect that I
can't justify the cost and effort of buying, installing and learning to
use VS2005, just in order to have a debugging facility. But I do know
that I'll miss it.

The reason I entered the suggestion is that I don't think that people
should be forced to install and use a second product just to get some
functionality that should be included in the first product (and that has
actually been included in the previous version).

It's as if MS would decide to remove the spell check from the next
version of MS Word, and instead start selling a new product (MS
SpillChuck) that handles spell checking from all Office applications.

(snip)
[quoted text, click to view]

I don't think that was possible in the SQL Server 2000 debugger. It
would sure be nice if it was added for the 2005 version, but based on
what you write, I'm afraid it isn't. Too bad!

Best, Hugo
--

[quoted text, click to view]

Never had occasion to use them, to be honest, so it wouldn't be fair for me
to try to make a comparison. Wasn't until this current assignment that
running T-SQL code in a debugger actually became a needful process.

[quoted text, click to view]

I'm thinking that with the installation of the VS2005 IDE shell with the SQL
2005 Dev Edition, that the debugger may not require 'an extra product' to be
purchased. I'll check into this. As for the learning curve.... to use the
debugger... it's not really that great. As noted, I didn't use the debugger
in SQL 2000, but I have some background using the debugger in Access VBA,
and it's pretty much the same interface.

[quoted text, click to view]

I absolutely agree with this point of view, and if I discover that the the
VS2005 IDE installed with SQL Server 2005 does not provide the debugger
capability, I'll be jumping on this bandwagon with you. (I can't make that
eval now because I have a full VS2005 EA installed, so I'll have to look at
installing a standalone SQL 2005 DE and see what happens.)

[quoted text, click to view]

Well..... actually....... they did that a long time ago. All of the MS
Office products use a common spell checking engine that's stored in \Program
Files\Common Files\Microsoft Shared. The only difference is that the product
isn't actually sold as a standalone application.

I do think, however, that it's much more efficient to maintain -one-
debugging engine for -all- code debugging, than to have to maintain it in
separate products. With the availability of the CLR in SQL Server 2005, I
suspect a lot of T-SQL programmers will find themselves writing the
occasional VB or VC# module to replace what might have previously been done
awkwardly in a UDF.

[quoted text, click to view]

Don't take my limited experience as authoritative. It may be that I've
simply not looked in the right place to find it.

Frankly, I would think that merging the debugging engine into the enviroment
and -not- providing a way to execute a real-time SQL query against a
checkpoint would be a severe deficiency.

The next thing I want is to extend VB's new Edit-and-Continue functionality
into the T-SQL debugger. It's a b--ch to have to rerun the whole code module
because the logic two statements after a 3 minute table scan crapped out.
:-)

[quoted text, click to view]