Hi all,
I have a big ol' stored proc (about 6,000 lines), written in T-SQL. I want to debug this stored proc using something other than a bunch of PRINT statements. I tried using the Visual Studio debugger (Server Explorer - Database - Stored Proc - "Step Into Stored Procedure"), but this is behaving erratically.
The "Current statement" yellow cursor is rarely on the line that is currently being executed. It is usually between 2 and 100 lines above the actual current statement. It seems that the further down the code I get, the bigger the distance (in lines) between the yellow cursor and the actual current statement. Maybe something related to comments or multi-line statements?
I have heard of a similar problem with older versions of Visual C++ related to line feeds and return carriages (CR, LF vs. CRLF) but this doesn't seem to be the problem.
Has anyone had similar problems?
Thank you,
Vince
Might be experiencing something similar. I am used to working in SQL Server. I create my stored procedures in the query editor in SQL Server 2005. Sometimes I want to debug the procedure, so I have to go into VS, open up the object explorer, make sure that the debugging setting it on, find the stored procedure and step into it.
Well... I am seeiing erradic behavior as well; about 75% of the time, the yellow cursor disappears. Like right now... It thinks it is still debugging but the cursor is gone and the only option available for debuuging is to stop debugging. oh, and the task bar says its running... I can't seem to find out why this is happening, since I am seeing no other reports of this happening to people. Your post is the closest so far. Did you resolve your problem?
|||While I dont have an exact remedy for you, this is not that uncommon. I have used the tools (both VS and SQL) for about two years now since the first public beta whenever that was :)...
I have seen this behavior over the months several times, but not as of late. It usually had to do with referring to old versions of code. Make sure you are referencing the correct Server/DB/Proc and refresh then debug. And check you DB connection properties.
Hope this helps,
Derek
|||I do think it does have something to do with saving the procedure using Visual Studio 2005. It *seems* that if I save it to a project and try debugging it I have less problems...
This leads me to ask about best practices for managing T-SQL and databases. I'm sure my circumstances are not uncommon; I have a single, rather large database that is utilized by multiple applications (many of which can be in a beta development stage requireing frequent changes to the database). I was to implement source control practices for myself and my teams and I favor subversion for source control. When I create a new application, or upgrade an application to VS 2005, how can I best set up my database for change management?
I have the impression that Microsoft wants me to change the way that I work to handle my database, but it is very unclear HOW they want me to work with their products. Sometimes I write stored procedures that are not part of a single application, but that are used by multiple applications - both web and desktop. So, in this case would it be best to create some kind of database project that is seperate from my applications? And if so, how could I organize it to manage change and quality? Ugh.
|||Hi Ryan,
I think you will find SQL Server source control integration a good first step towards acommplishing change management in the database. There have been several 3rd party attempts at the problem of managing change in the database, but those I have used were fair at best.
In general, your database can and should be a seperate entity for all but the most simplest projects aka "mom and pop websites/apps". My dev. team uses VSS (not used Team System so you may want to check into that as well) and each project is self-contained in the repository. We do not mix and match projects of different types. So maybe very simplistically speaking your VSS repository structure...
FRONTEND
-Web
-Desktop
MIDDLETIER
-Classes
-Web Services
DATABASE
-Database X
--Stored Procs
--Functions
--Triggers
DML
DDL
-Database Y
-Database Z
etc...you may enjoy a recent post on my blog regarding the usage of mangement studio's VSS integration...
http://derekcomingore.iuplog.com/default.asp?item=167168
Derek
No comments:
Post a Comment