Apologies for getting back late on this, I was buried under some assignments clubbed with hectic travel schedule. So, sometime back I had posted this to be solved by you…
Many of you commented on the original post which is here;
And you all gave me interesting tips including Refreshing SSMS, checking for preceding space in from the db name, not to use sp_renamedb, checking the connection, checking permissions, etc. And trust me, even I had looked into all of them and many more when I encountered this for the first time.
But what helped me was to check sys.databases system catalog and PM Shawn (one of the readers) suggested that. But still it was tricky. This is why…
So when I executed select * from sys.databases, I did get HOCBASE listed as follows:
And you can observe that there is a space but SSMS object explorer does not show that.
As I said before things were trickier than it appeared. Knowing that there is a space, I executed sp_renamedb again and explicitly put a space.
Things didn’t work. It was a bit of brain pain before I tried this:
And it worked 🙂
Yes, there was a CRLF (ENTER) between HOC & BASE. But how did that happen? A Junior DBA who believes he is the fastest on keyboard did this 🙂 – and I call this pace without accuracy 😉 – so while renaming the DB, he mistakenly pressed ENTER and executed it. He was fast enough not to notice what he was doing.
There could be other ways of identifying that there was a CRLF in the database name but I did not know of any and sys.databases showed a space. If there is a way you know, do let the readers know by commenting.
Hope you enjoyed this 🙂
11 Comments on “SQL Server – Strange things do happen, but why are they allowed in the first place – THE ANSWER”
It’s pretty easy to parse a column of strings, and determine the ASCII value of each character. The characters for CRLF are 13 and 10. Here’s an example using [sys].[databases]
;WITH — generate a quick tally table. Better to use one that already exists, but this will do for demo purposes
T0 AS (SELECT 0 as [n] UNION ALL SELECT 0 ), –2
T1 AS (SELECT .[n] FROM T0 , T0 ), –4
T2 AS (SELECT .[n] FROM T1 , T1 ), –16
T3 AS (SELECT .[n] FROM T2 , T2 ), — 256
T AS (SELECT ROW_NUMBER() OVER (ORDER BY .[n]) [n] FROM T3 )
[db].[name] as [database_name],
SUBSTRING([db].[name], [t].[n], 1) as [letter],
ASCII(SUBSTRING([db].[name], [t].[n], 1)) as [ascii]
[sys].[databases] [db], [t]
LEN(SUBSTRING([db].[name], [t].[n], 1)) > 0
Perhaps in the future you should deploy a DDL trigger that prevents database names from using unprintable characters. Just listen for the CREATE_DATABASE and ALTER_DATABASE events, parse out the name from EVENTDATA() and if the name has an unprintable character, just rollback. This will prevent database names from having unprintable characters. Permit only ASCII character values 48-57 (characters 0-9), 65-90 (characters A-Z) and 97-122 (a-z).
Then it doesn’t matter how fast your DBA types.
You don’t have to go to such extremes as listing all the ASCII values of all the letters. When using SSMS to display results in a grid, all special ascii characters are converted to a space when you display as a grid. Display as text will give you the exact result. Even a carriage return without a linefeed would show up, but you’d have to use special character techniques to copy it. This would have solved the original problem by using a straight copy/paste:
SELECT ”” + name + ”” FROM sys.databases WHERE name LIKE ‘HOC%BASE’
That’s assuming you didn’t put a “‘” in the name.
Just goes to show first responses aren’t best. This would work if only one DB would be caught and can be executed as many times as you like with any kind of special characters used:
DECLARE @db sysname
SELECT @db=name from sys.databases WHERE name LIKE N’HOC%BASE’
IF (@@ROWCOUNT > 0) EXEC sp_renamedb @db, ‘PRODHOCBASE’
Ken & Mark, thanks for the responses. Good inputs !
Ken, i tried your solution. works good. nice learning here. Thanks again !
Great Sir, i like it 🙂
changing the SSMS grid mode to text also will help you to find out the new line breakers
Strange things happen for certain. I had just read this article yesterday and was creating a linked server connection today. I tested the connection using the 4 part name to the database that would be queried as standard due diligence before giving the green light to the end user (even though the test connection succeeded and the catalog was there). It failed. After re-checking everything required, this article recalled to mind. Sure enough, a previous DBA had added a space at the end of the database name. A simple [dbname ] change to my query later and success.
Ken’s suggested format of SELECT ”” + name + ”” FROM sys.databases WHERE name LIKE ‘HOC%BASE’ (using a truncated ‘dbname%’) helped to confirm that a space existed easily.
if i understand well youre case why you dont try simply to rename your database by right clik and rename its easy fast and effective 🙂