Is there a way using sql 2008 Management Studio to look at the queries that hit the server? I'm trying to debug a program and I get messages like "Incorrect syntax near the keyword 'AND'". Since the queries are being dynamically generated it's a hassle to figure out what is going to the server.
Any help is appreciated!
There is a tool called Profiler that will tell you all information that you'll need. MSDN: http://msdn.microsoft.com/en-us/library/ms187929.aspx
I'm not aware of any method to do this using SQL Server Management Studio, but if you installed SSMS then you probably also installed the SQL Profiler. If you fire that up and run the TSQL_SPs profiler template, you can see every statement that's hitting the database.
Since the queries are being dynamically generated it's a hassle to figure out what is going to the server.
Why not just put the query that's generated into a message box, or print it to the console, or webpage, etc. ??
Trying to catch it at the DB server seems to be the long-way-around to debugging some simple ad-hoc queries.
Go to Management...Activity Monitor in the object explorer.
It's not live though, you will have to refresh it manually.
start up profiler from SSMS (Tools-->SQL Server Profiler), run a trace and select the T-SQL events
One option is to use SQL Server Profiler to run a trace. However, in some shops SQL Server permissions are set so only DBAs can run traces.
If you don't have sufficient rights to run a trace, then another option is to view the network traffic between the application that generates the SQL and box SQL Server is running on. WireShark works great for that.
Related
I am executing a very long SQL script in SQL Server Management Studio, normally it takes a few second to be done.
But this time it is taking forever and never completes. Other people running this script has no problem.
So I wonder if there is anyway I could debug in SQL Server Management Studio to see which line in this long SQL Script is currently executing and taking forever?
Easiest way is to fire up SQL Server Profiler and trace your SQL with that. As a bonus, you'll get a lot more useful information than simply which line is causing the problem.
If Profiler doesn't give you what you want, have a go with the Activity Monitor. Find your session in the Processes part, and then pull up the details to see the last T-SQ command batch.
I have a DLL, for which I do not have the source code. It is making calls to a stored procedure in a SQL Server 2005 database. I need to know what values it is passing in as the parameters of the call.
Is there a free tool, or one that comes with SQL Server that is able to monitor and record the calls into a database?
Thanks.
You can use for this SQL Server Profiler which comes with SQL Server.
If you have an access to Microsoft SQL Server Management Studio, you find it by clicking Tools → SQL Server Profiler.
When it starts, click Connect. On Trace properties dialog, click Run. It then collects every call to the SQL Server and displays the summary at the top, and the query with its parameters at the bottom of the window.
You can also:
Pause or stop the profiler (icons in the toolbar),
Clear the current trace.
Do not forget to clear the trace before launching the action which will call the stored procedure and do not forget to pause/stop the profiling after you get the results to avoid getting too much information to analyze.
As pointed in the comments, if you are using SQL Server Express, the profiler may be missing. You may want to install a third party profiler for SQL Express instead.
Check the [Tools] menu in SQL Server Management Studio:
If you don't see this option, you most likely have SQL Server EXPRESS which does not come with Profiler.
I want to be able to see all the queries that has been executed on the server last 2 days etc.
see the script, date of execution, sender etc.
is there any way?
I am using SQL X 2005.
I don't believe it's possible without SQL Server Profiler running.
Yes you can use SQL-Trace to log each command submitted to the server. It's the same mechanism used by the profiler, but you do not have to have the profiler or any other tool to use it.
There are two modes in which SQL Trace can run - in-memory buffer and disk file. The former is only used by profiler, is not documented and should not be used. Use the disk-file mode. The file can later on be opened on the same or different machine and even loaded into a table for analysis.
To learn more go to this page: http://msdn.microsoft.com/en-us/library/ms191511.aspx and search for section titled "To perform monitoring tasks with SQL Trace by using Transact-SQL stored procedures"
Here is a free, open-source Profiler tool that might help.
Profiler for Microsoft SQL Server 2005/2008 Express Edition
I have this c# web app that relies heavily on two dll files that i can't see nor edit. The rest of the app is visible and editable.
The app generates SQL exceptions, and i would like to see the queries sent from the DLLs. Is there a way to do that?
You can use SQL Profiler to see the queries that goes to your database.
For SQL Server 2005/2008 Express you can try AnjLab's SQL Profiler.
Another way to see what is running is SP_WHO2 'active' combined with DBCC INPUTBUFFER(SPID) or query the [sys.dm_exec_requests].
The SQL Profiler mentioned above is the preferred method.
In a project of mine the SQL statements that are executed against a SQL Server are failing for some unknown reason. Some of the code is already used in production so debugging it is not an easy task. Therefore I need a way to see in the database itself what SQL statements are used, as the statements are generated at runtime by the project and could be flawed when certain conditions are met.
I therefore considered the possibility to monitor the incoming statements and check myself if I see any flaws.
The database is running on a SQL Server 2005, and I use SQL server management studio express as primary tool to manipulate the database. So my question is, what is the best way to do this?
Seeing how you use the Management Studio Express, I will assume you don't have access to the MSSQL 2005 client tools. If you do, install those, because it includes the SQL profiler which does exactly what you want (and more!). For more info about that one, see msdn.
I found this a while ago, because I was thinking about the exact same thing. I have access to the client tools myself, so I don't really need to yet, but that access is not unlimited (it's through my current job). If you try it out, let me know if it works ;-)
Best way is to fire up profiler, start a trace, save the trace and then rerun the statements