If I use a database name with a dot in it in SQL Server (2005 or 2008), something like "MyApp.Sales", will this cause any problems?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
You can, but I wouldn't. You would always have to wrap the DB name with square brackets such as [MyApp.Sales].
So to recap: if you value your sanity, don't do it.
I think it's a very bad idea even if technically possible.
Over the years I found out that many people have trouble understanding the four-part naming convention even though it seems pretty obvious:
Imagine what will happen if they see something like this:
Keeping things simple is important.
In case someone else encounters this question...
Keep in mind that it is not only a bad idea because users might be confused, but also because some tools might get confused.
Even Microsoft itself has problems with this. If you try to connect your database to an excel sheet using Microsoft Query (via ODBC), you get a configuration wizard which lets you choose the database you want to connect to. However choosing a database that contains a dot will produce an error stating that the server could not be found. It seems that the wizard does not check if the values needs escaping and blindly concatenates the identifiers.
There are of course workarrounds, but you save yourself some trouble by not doing this from the start.
There are many characters allowed in names, but, convention and common sense limits special characters usage. '_' (underscore) is the proven safest separator and maintains readability ease.
Do not use period in database names, publication names, user names. And I strongly recommend never to use a period in name (column, table, view, database, etc).
Update: I can confirm, that the minus, dash "-" causes simmilar issues.
Here is what happens:
SQL Server uses scripts for internal usage like system stored procedures. As already mentioned here, the commands you use will sometimes force you to put the name into brackets and that is (seriously microsoft?) not (always) okay for stored procedures usage.
In fact I am not able anymore to cleanup abonnement informations because the stored procedure iterates through all databases and doesn't escape the database names propperly. This iteration is that complex I wasn't able to patch it in over 8 SPs.
Plus I am not able to use MMC or scripts to edit replication conflicts. If you have one (One!) database that has a dot inside its name, these problems will occure on everey db, every publication.
These are the occurences I have. Complex SQL actions are processed in sql language and will work fine, if the base is fine.
These errors may more often be found in 3rd party software, so never ever use dots in every name of anything on sql server.
One of our suppliers has chosen to introduce the schema name: [System.Activities.DurableInstancing]. It's broken our dataload tool, so we now have further development to cope with their weirdness. Just don't do it. Use a '-'.