SSMS How do I open a new Query Window using Same Connection Instance of current Window

Question

Coming from Oracle I have discovered that SSMS connects slightly different than Oracle's SQL Developer. Oracle you click ONE connection and then all tabs you open then use that Connection. SSMS creates a completely new Connect/Instance for each window/tab I open. I don't want this. TWO pet peeves come to mind with this behavior I am trying to get around.

1. View affect of Script before COMMIT in another Window

I want to be able to run a script in one window... and in another Window have the ability to Query the Non-Committed data to simply view the results... Currently I have to use the SAME Window I ran the script in order to simply VIEW the affect. (Commit/Rollback buttons come to mind - Oracle I miss you sometimes).

2. View data stored in #TempTable from another Window

I am creating a #TempTable using a script... but want to query it's data from another Window. Currently when I open another window (Unlike Oracle's SQL Developer) it opens the window using a new connection/instance. How do I query the data in #TempTable from another window rather than the window I ran the script in?

The above is just simply for organizational reasons... it's SUCH a pain to run a script... and then from that same tab have to then write in other code when I don't want to edit/add any other code to the page that contains the script I ran.

If I'm doing something wrong or missing some Point please let me know.

Answer 1

View affect of Script before COMMIT in another Window

You can use Table Hints such as WITH (NOLOCK) or WITH (READUNCOMMITTED) to perform dirty reads of uncommitted data between two windows in SSMS.

View data stored in #TempTable from another Window

You can use global temporary tables (##Table instead of #Table) to query temporary tables across sessions. Note that you must create the temporary table as a global temp table to begin with.

The above is just simply for organizational reasons... it's SUCH a pain to run a script... and then from that same tab have to then write in other code when I don't want to edit/add any other code to the page that contains the script I ran.

If I'm doing something wrong or missing some Point please let me know.

A simple way is to write your entire script, including the queries to check/test your data changes, and actually highlight the individual portions you want to run and execute them.

Take the below code sample. I want to insert two records into a table, validate the result and then commit if I am happy or rollback if not:

BEGIN TRANSACTION

INSERT INTO TableA (ID, Value)
VALUES (1, 'Value 1'),
  (2, 'Value 2')

SELECT * FROM TableA

COMMIT

ROLLBACK

I would put the entire code into a single window, highlight lines 1-5 and hit Execute/F5. The data is inserted but not committed, so I then highlight line 7 and hit Execute/F5 and verify the results. If I am happy, I highlight line 9 and hit Execute/F5 to commit the changes or if I want to rollback I highlight line 11 and hit Execute/F5.

Also, note that if IMPLICIT_TRANSACTIONS is OFF (default) then your session is basically using 'autocommit' which means without an explicit BEGIN TRANSACTION, the INSERT statement would commit automatically.

Answer 2

If I'm doing something wrong or missing some Point please let me know.

You're not missing anything. SSMS always has a separate session per tab.

it's SUCH a pain to run a script... and then from that same tab have to then write in other code when I don't want to edit/add any other code to the page that contains the script I ran.

In SSMS the Execute command (F5,Ctrl-e), always runs the highlighted text in the query window, if there is any.

And so the normal way people use SSMS query windows here is to highlight sections of code to run, often separating the main script from the test/debug bits by using multi-line comments.

For instance when developing a stored procedure, then query window might look like:

create or alter procedure SomeProc @param int
as
/*
  declare @p int = 12
  exec SomeProc @p
*/
begin
  ...
end

Then run the whole script to recreate the proc, and highlight the test harness lines and run to test it.