Search

SQL Server Management Studio 2008 R2 query window caches disconnected servers by Jason M Anderson

Closed
as Won't Fix Help for as Won't Fix

1
0
Sign in
to vote
Type: Bug
ID: 772557
Opened: 11/28/2012 10:41:36 AM
Access Restriction: Public
0
Workaround(s)
0
User(s) can reproduce this bug
I had two SQL Server Instances connected in my Object Explorer (A and B, both with identical database names and schema but different data - test and production).

When I ran a query in the query window on my A instance, then disconnected from A and ran the query again it continued to pull results from A despite having already disconnected.

This created a lot of confusion because it appeared that I was connected to the intended instance B but was returning results from a previously closed connection. A simple solution was to close the old query window and open a new one but this wasn't very obvious and took a while to figure out.

A nice fix would be to display a message to the user saying that the connection to that server instance was already closed or have it automatically switch to the only remaining connection if the names are the same.
Details (expand)

Product Language

English

Version

SQL Server 2008 R2 SP1

Category

Developer Tools (SSDT, BIDS, etc.)

Operating System

Windows Server 2008 (all editions)

Operating System Language

US English

Steps to Reproduce

Create 2 SQL Server Instances with identical databases.
Insert different records in both databases.
Connect to both in SQL Management Studio.
Run a query from the first and disconnect.
Run the query again and it still pulls results from closed connection.

Actual Results

Results from closed connection.

Expected Results

Results from remaining open connection.

Platform

X64

Virtualization

Other (e.g. VM Ware, specify in Description)
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 2/6/2013 at 12:03 PM
Hi!, thanks for writing in to Microsoft and reporting this bug.

We took a look at this bug and triaged it against several others and unfortunately, it did not meet the bar to be fixed. Please consider using SSMS 2012 which improves this specific scenario.

Regards,
Sanjay Nagamangalam, SQL Server Manageability
Posted by Sethu Srinivasan on 11/29/2012 at 8:33 AM
Thanks for reporting this issue. Could you please check if you see the same issue in SQL 2012 SP1 as well?

Thanks
Sethu Srinivasan [MSFT]
SQL Server
Sign in to post a workaround.