New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temp table loss due to sudden session change #2996

oappelt opened this Issue Oct 24, 2018 · 1 comment


None yet
2 participants

oappelt commented Oct 24, 2018

After upgrading to 1.1 a few days ago I noticed that temp. tables "vanished" suddenly from my scripts.
I have since upgraded to 1.2.1 but the bug is still present.

  • Azure Data Studio Version: 1.1.3, 1.2.1 (not sure about 1.0, but have been using sqlops 0.x releases since late last year and never before noticed that problem, while using temp tables all the time)
  • on Ubuntu Linux.

Steps to Reproduce:

  1. Create any number of temp table
  2. SELECT @@spid -- note spid
  3. make a mistake, e.g. typo that leads to "invalid object name" or whatever
  4. Note that the temp table is gone
  5. SELECT @@spid -- note that a different spid is shown (explaining why the temp table "vanished")

I think the session change also happened without errors after just time has passed - but not 100% sure about that. I can reproduce it easily with above steps.

This is not happening within a procedure and there are no TRANSACTION statements - SELECT @@TRANCOUNT is 0.

I just made a test with version 0.31.4 on Win10 - everything ok.
Afterwards I upgraded to Version 1.1.3 on Win10 - exact same behaviour as on Linux.

I'm fairly sure that this bug appeared in either Version 1.0 or 1.1.3. I hardly used 1.0, but used all the 0.x versions a lot.


This comment has been minimized.


kburtram commented Oct 24, 2018

@oappelt I think this is related to change we made to reconnect a query editor when a connection exception is thrown. Users were reporting issues of dropped sessions and this was an attempt to try to "hide" connectivity problems from the user. I'll see if we can better scope the reconnect logic to SocketExceptions, or else remove that logic and ask the user to manually reconnect if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment