This is not directly a programming question but I ask it anyway because it's related to debugging.
I wonder if it's possible to see exactly what SQL statements that are being executed within a procedure in Microsoft SQL Server Profiler?
For now I just see the procedures being called but due to complicated procedures causing a tricky bug somewhere I would like to see exactly what SQL statement being executed. So it would be nice if anyone has any tip on this.
Yes this is possible.
Add SP:StmtStarting and/or SP:StmtCompleted to the events you are tracing.
Related
I am not that much well versed in SQL Server. I am using SQL Server 2008 R2. I wanted to know if we can get the history of the text of the stored procedures?
I had modified a procedure on the server and now I want to get the previous text of that stored procedure? I know we can get the last modified date or history of the procedure when it was modified. Is there anyway to get the previous text of the procedure?
Any help is highly appreciated.
Unfortunately you cant recover it once you update your stored procedure. One thing to avoid this in the future is save your query before modifying it. SQL SERVER doesnt have a History Feature like JAVA.There are also third party tools which you can use if you want to connect your database to a source control.
Click Here
Information: We are in the process of Testing our upgrade from SQL Server 2005 to SQL server 2012 on staging. In reading the documentation on features that will no longer be supported, COMPUTE (Transact-SQL) going away is going to be an issue for us.
Question: Is there any way to write out our own procedure that will take the place of the compute builtin on SQL Server 2012 that will make it seamless so when Compute is called it will function like SQL Server 2005? The alternative is we will we need to update all the SQL files, UDF's, Triggers, and stored procedures that use this built in with alternative code?
Note I have never tried to recreate a built in function before so any information on this will be very helpful for me and anyone else trying to do this in the future. Also knowing if it can be done is a plus.
Clenup: As always if this is a duplicate post indicate the link below and i will remove my post.
COMPUTE BY is not a function. I don't see how it's effects (generating additional result sets) can be replicated easily.
Replacing COMPUTE BY with a temp table and some looping should be kind of straight forward but it will be a laborious task. It's probably better to change the application so that it does not depend on multiple result sets.
I have made the recommendation of moving to SQL Server 2008 first, this will give us 4 years or so to update all the code and then we can move up to SQL Server 2012.
That sounds reasonable. By then there will be at least SQL Server 2016 so you'll have to see what other features are deleted at that point :)
After much work i've configured my machine (win 7 x64, VS2010, SQL 2008 R2) to be able to debug stored procedures locally from within visual studio. My question is about how the debugging context is supposed to switch as you debug.
an example:
when debugging and I call another vb class the debugger follows and jumps to that class for me to step through. when I hit a sql call is there a way to tell the debugger to follow it there too?
currently the only way I can debug a stored procedure is to right click it and choose "step into" and provide values. Those values I have to determine by running my app, making edits, and writing down my param values I was going to pass into the stored procedure. Then going back and stepping into the stored procedure with those values allows me to track and use intellesense to debug the sql stuff.
What i'm looking for though is to have the debugger do the switching for me. So I don't have to do as much work to step through stored procedures. When I run my application and open one of my stored procedures to view the breakpoint symbols are not loaded but it does say it has auto-attached to the sql process and everything.
Wasn't sure if this was how sql debugging was supposed to go or if I did something incorrectly. Figured someone here might know what was going on. Thanks for looking!
my target framework was dot net 4 client profile. When I swapped to full dot net 4 framework and rebuilt everything started working like I thought it should. My only guess is that some of the sql-clr debugging stuff is trimmed out of the client profile?
Try the following.
The standard workflow to debug a CLR SQL assembly is the following…
Right-Click the project and select ‘Deploy’
Debug | Attach to Process…
Select the Process ‘sqlservr.exe’ and make sure it is the one with a Type of ‘T-SQL, Managed, x86 or x64’
Press the Attach Button
currently I am working inside a company with a really messy information system. I mean: the system administrator does not have a full understanding of all the procedures and processes that daily run on the net they are working on!
We have this kind of problem: every day at 5 am, a filed in a table on one database (SQl Server 2008) is updated without any sense.
My question is: if we exclude the SQL profiler, there are other way to discover major details on the procedure, process, user or application that update the field?
You can try these tools.
Profiler for Microsoft SQL Server 2005/2008
http://www.codeproject.com/KB/database/TSQL-profiler.aspx
I often heard people saying that stored procedures are pre-compiled. What does it mean?
Actually we write the queries into the stored proc and then compile it. If any syntactic error is there, it complains. So if that is the case then the compilation is happening at that point of time.
Then, what does "Pre" refer to?
They are actually pre-parsed and syntax/semantics checked on CREATE and ALTER
"Compilation" to a query plan happens on demand
For an overview of compilation and re-use, see "Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005 "
The terminology (in what you mean) goes back to SQL Server 6.5. The "new" way highlighted in the previous white paper link started with SQL Server 7.0
In Microsoft SQL Server, stored procedures are compiled into a query plan the first time they are run.
At subsequent runs, they are sometimes recompiled from source, but not always. That is why they are called "pre-compiled".
Unless you specify that they should always be recompiled, or when you run sp_recompile to enforce recompilation at the next run time.
The sql content of the stored proc won't be parsed if you run it. The sql parsing can be very time consuming operation.
Precompiled: In Microsoft SQL Server, stored procedures are compiled into a query plan the first time they are run. At subsequent runs, they are sometimes recompiled from source, but not always. That is why they are called "pre-compiled"