June 29, 2010 at 6:12 am
One of our developers was working on one of our 2008 tables, owned by dbo.
He happened to double click on the table name, I will call the table "batch", which caused SSMS to think he wanted to
change the table name. He entered the table name again and once he did and did a refresh
the table disappeared.
Doing a select from sysobjects showed only one row, with just batch.
After recreating the table and doing the same select from sysobjects
2 rows appeared, one with dbo.batch and the other just batch.
doing a select on batch returned an error, doing a select on dbo.batch returned zero
rows, which is correct, since the table was just created.
Nowhere in the database was the table batch found.
Doing a select on dbo.[dbo.batch] returned all the rows from the original table.
What caused this and why did SQL Server add an extra dbo.
We have since changed ownership of dbo.[dbo.batch] to dbo.batch and all is good,
but just curious why this happened.
Any clues would be appreciated.
Thanks,
Keith
June 29, 2010 at 6:15 am
it looks like developer renamed dbo.[batch] as dbo.[dbo.batch]
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.June 29, 2010 at 6:21 am
He was using the GUI, so all he did was put back in the name of the table "batch", not dbo.batch.
June 29, 2010 at 10:27 am
Keith Underwood (6/29/2010)
He was using the GUI, so all he did was put back in the name of the table "batch", not dbo.batch.
Well, there are two possibilities:
1) There is a bug in SSMS that nobody else has noticed that sometimes causes the table rename to behave strangely.
2) The developer simply entered dbo.batch when he was trying to renamne the table back to its original name. He then forgot about what he was doing or for some reason does not want to admit that he did something wrong.
I know which alternative my money is on. 😎
June 29, 2010 at 10:33 am
Stefan_G (6/29/2010)
Keith Underwood (6/29/2010)
He was using the GUI, so all he did was put back in the name of the table "batch", not dbo.batch.Well, there are two possibilities:
1) There is a bug in SSMS that nobody else has noticed that sometimes causes the table rename to behave strangely.
2) The developer simply entered dbo.batch when he was trying to renamne the table back to its original name. He then forgot about what he was doing or for some reason does not want to admit that he did something wrong.
I know which alternative my money is on. 😎
Take my 100£ on 2nd one, please 😀
June 29, 2010 at 10:50 am
Eugene Elutin (6/29/2010)
Stefan_G (6/29/2010)
Keith Underwood (6/29/2010)
He was using the GUI, so all he did was put back in the name of the table "batch", not dbo.batch.Well, there are two possibilities:
1) There is a bug in SSMS that nobody else has noticed that sometimes causes the table rename to behave strangely.
2) The developer simply entered dbo.batch when he was trying to renamne the table back to its original name. He then forgot about what he was doing or for some reason does not want to admit that he did something wrong.
I know which alternative my money is on. 😎
Take my 100£ on 2nd one, please 😀
Agreed! 😀
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.June 29, 2010 at 10:53 am
I vote for option 2 also, the developer says he may have but does not remember,
so the matter is closed.
The good thing is we got the production table back and all is well.
Thanks all for viewing and posting.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply