When I am composing a script in SQL Server Management Studio v18.10, more often than not, I end up with plethora of recalcitrant Query Editor windows that each test one aspect of the problem (or my patience). Invariably I will need to test this ungovernable lot of scripts on different instances of SQL Server. I recently found out that there is a button to Disconnect All Queries...
...Is there a button to Reconnect All Queries?
Related
Environment: SQL Server 2008 SP3 - using SSMS2008 (local or remote) and SSMS2012 (remote)
Something happened with our SQL Server instance recently. Nobody is able to create a new database through an SSMS (SQL Server Management Studio) interface. Neither SSMS for 2008, or SSMS for 2012.
What happens is they hang (or appear to hang). Sit and spin forever, and then the performance of the SQL instance really starts to tank while it is chewing away. CPU usage skyrockets.
Things I've noticed:
Telling it to create the MDF/LDFs on a local drive or network drive makes no difference.
We've tried disabling the anti-virus tools on both the SSMS machine and SQL instance server, with no change.
We've tried using the SSMS on the SQL instance server itself, and it also just spins. Any SSMS (we've tried three different machines) does the same thing.
If I open Windows Explorer and look at the locations I've told it to put the MDF/LDFs, they are created. I see the MDF and LDF show up.
As soon as I kill the SSMS process (because it feels like it's hanging), it does some cleanup work and the MDF/LDFs go away.
I can successfully use the CREATE DATABASE t-sql script in a query window, and it creates the databases fine, fast as can be, like one would expect.
FILESTREAM is not enabled for the server instance at all. No database uses it in the instance.
This only started happening recently - and the only thing I found with GoogleFu was a hotfix by Microsoft for SQL2008-SP2, that had to deal with microfilters and antivirii. This is SP3, so that fix is rolled into it (as well as we disabled AV on the SQL server and our local machines - to be sure).
Any suggestions or ideas? Is there some trace profile I can start up that would show me what is going on, step by step, to see where the SQL instance seems to be spinning its wheels when I try creating a database through the SSMS interface?
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.
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.
I'm currently working on a reporting tool for a company that conducts the same survey at different clients. So the analysis and report would be the same, except for the conclusions. The ultimate goal of the project would be a tool that automatically extracts, analyses the data and creates the report. SQL Server and Visual Studio are mandatory programs.
I'm completely new to all of this except for the SQL-language. After reading up on this and asking around the usage of stored procedures seemed the best option. If I interpret correct these should be stored in SQL Server and could then be envoked in Visual Studio
However, my problem is, I can't figure out how to connect to the external ODBC-server that holds the data in SQL Server 2005. It seems to me there is no way to connect to a remote server in SQL Server 2005. On the other hand, in Visual Studio 2005 I did manage to connect and extract data from the server.
Is this the right way to achieve my goal (repeatable/automated report)? If so, what am I doing/thinking wrong? If not, please enlighten me.
Thx in advance
Another way to do this is to use bcp...you can check this article to see if there are any answers here for you. There would be no remote server connections if you are able to run the command and the local box that contains the sql server.
You might be able to set up a linked server in SQL Server 2005 to connect to your remote server/database.
Is there a way to step into the stored procedure code in SQL Server Management Studio? I know this is possible with Visual Studio, but I am looking for a dependable debugging solution from within Management Studio
Only with SQL 2008 and SSMS 2008. Select from menu 'Debug\Start Debugging' or press Alt+F5 and will launch the step by step T-SQL debugger.
On 2005 the only way is to attach Profiler and monitor for the SP:StmtCompleted event, which is not exactly debugger step-by-step, but at least you'll see the execution flow. Not to be done on a production machine, obviously.
I have written a pretty detailed blog post about it here:
http://www.diaryofaninja.com/blog/2010/11/23/debugging-sql-queries-function-amp-stored-procedures-with-sql-management-studio
Basically the gist of it is that you enter your sql query to execute your stored procedure, and instead of pressing F5 or hitting the exclamation, you hit the play button and use F10 and F11 to step through and step into your stored procs.
This is very handy but no one seems to use it.
From SSMS 17 onwards version, You can not debug any SQL.
The ability to debug sprocs, which was in Query Analyzer in SQL Server 2000 was not put into SQL Server 2005. Microsoft realized this mistake and put the functionality back in in SQL Server 2008.
In SSMS 2008 you can start the debugger by either clicking the debug button on the toolbar or pressing ALT+F5.
Unfortunately, running SSMS 2008 against a 2005 database will not allow you to debug, so
you'll have to stick with Visual Studio.
Watch out for debugging stored procedures using Visual Studio. The way that this is implemented is to use an incredible amount of locking so that you should never do this on a production system.
Yes, in SSMS 2008 you can definitely step into T-SQL code (code block, stored func, stored proc) and debug it.
See this excellent article Management Studio Improvements in SQL Server 2008 for details - it also deals with debugging (towards the end of the article).