Modifying a table makes it disappear from the tables list
Whenever I modify an existing table, the table disappears from the Object Explorer. If I refresh the tables list in the Object Explorer it reappears...but c'mon, that's ridiculous. The only thing you should be doing to the Object Explorer is marking items that have been modified. If you want to help here, then refresh the list when I add something so it appears (something Microsoft never implemented).
Note: this only happens when you FIRST edit a table (i.e. subsequent edits to the table after your modified icon is on the table icon don't cause this issue).
We have attempted to fix this behaviour a few times now – if it’s still occurring, we would like to investigate this as a bug rather than a feature request. If you have seen this recently, can you please email email@example.com with details?
Daniel Brink commented
I'm having the same problem. If you alter a table using the designer in SSMS (I was removing the auto identity and setting a default value as a function on the primary key) the table disappears from the object explorer tree. You have to manually refresh the tree to see the table again.
I'm using Microsoft SQL Server Management Studio v10.50.4000.0 with SQL Source Control v188.8.131.52
This problem still exists in SSC 3.0.13 and it is grave because after being used the normal behavior of SSMS explorer for many years it is exhausting working with this problem.
Can we get an updated response to the last one at May 25, 2010? What is the status of issue SOC-375?
Daniel Kim commented
Just to chime in .... I'm seeing this also. I really appreciate the fact that new objects now appear (which is definitely an improvement of the native SSMS behavior) but when modifying the data types for columns (as descrived by Stephainie back in May 2010) below, they do disappear.
Is this still an open issue that is targeted to be fixed?
Alexander Harris commented
I am also seeing this issue, and in a large database with many tables this is very irritating and is causing a lot of friction. We have only just adopted SQL Source Control and this is a real disappointment. Is there a fix for this in the works, or is this issue non solvable?
Sometimes the modified table is shown at the bottom of the list, and sometimes it's shown twice or even thrice (depending on how many times it was modified). This has happened to me when an other person has modified a table in the shared db model and I haven't refreshed the object explorer details manually yet.
Yeah, this problem seems to be isolated to tables only (i.e. if I alter an SP, the SP doesn't disappear). I can refresh but with about 50 tables and at least 200 SPs, scrolling around in the Object Explorer and refreshing (since you can only refresh the actual list off the section's header--e.g. Tables, Stored Procedures--to refresh the list), it's an annoying waste of time. I've got to already do it when I create tables and procedures but now with edits it's just dumb since it effectively breaks the existing SMS functionality (not that SMS isn't flawless by any means).
Our internal issue number is SOC-375, but unfortunately, we may not be able to fix this before the v1 release.
The table should not disappear in all instances. For example, adding a column may not cause it to disappear, but changing the datatype of a column seems to cause it to disapear. We think this is because the table is actually being rebuilt behind the scenes. If you refresh the ObjExp or visit the Commit/Get tab, we will add the object back into the ObjExp tree. The Commit/Get tab may put the object at the bottom of the tree, so refreshing is best.
Btw, we do add tables, views, stored procedures and other objects into your object explorer when you create new objects since Microsoft doesn't do this. Please let us know if this is not the case for you. We also update your Object Explorer when you get new objects from source control (if you are working in a dedicated environment).