Another example of incomplete support of some legal database names

It has already been reported that the View tool in Enterprise Manager
cannot handle databases which have a period in their name (e.g.
"mydomain.com"). It doesn't show the individual field names.
Today I found a second problem: when scheduling a Job under SQL Server
Agent, in the New Step dialog you are prompted for a database name.
Databases with a period in their name are not listed. Tomorrow I'll
use ISQL to schedule the job in Windows Scheduler.
Hopefully MSFT will add these tests to the test scripts for the next
version and service pack (but don't hold your breath).
PS: I inherited this database name. It's too late (read: expensive)
now to fix it.
-Tom.Many of the tools do not support non-standard object names.
Even though SQL Server lets you create objects with invalid
names they aren't really legal names. You can find the rules
for object names in books online under the topic Using
Identifiers
-Sue
On Tue, 23 Mar 2004 19:39:31 -0700, Tom van Stiphout
<tom7744@.no.spam.cox.net> wrote:

>It has already been reported that the View tool in Enterprise Manager
>cannot handle databases which have a period in their name (e.g.
>"mydomain.com"). It doesn't show the individual field names.
>Today I found a second problem: when scheduling a Job under SQL Server
>Agent, in the New Step dialog you are prompted for a database name.
>Databases with a period in their name are not listed. Tomorrow I'll
>use ISQL to schedule the job in Windows Scheduler.
>Hopefully MSFT will add these tests to the test scripts for the next
>version and service pack (but don't hold your breath).
>PS: I inherited this database name. It's too late (read: expensive)
>now to fix it.
>-Tom.|||On Tue, 23 Mar 2004 19:39:31 -0700, Tom van Stiphout wrote:

>It has already been reported that the View tool in Enterprise Manager
>cannot handle databases which have a period in their name (e.g.
>"mydomain.com"). It doesn't show the individual field names.
>Today I found a second problem: when scheduling a Job under SQL Server
>Agent, in the New Step dialog you are prompted for a database name.
>Databases with a period in their name are not listed. Tomorrow I'll
>use ISQL to schedule the job in Windows Scheduler.
>Hopefully MSFT will add these tests to the test scripts for the next
>version and service pack (but don't hold your breath).
Hopefully not. I would prefer that MSFT removes the ability to call a
database "mydomain.com" or other pathological formats.

>PS: I inherited this database name. It's too late (read: expensive)
>now to fix it.
That's too bad.
I presume that you can still write scripts for all of the things that
you can't accomplish via the GUI? If so, then you have the tradeoff
costs of writing everything in scripts versus changing the name of the
database in the application (and all the associated testing).
--
"There is more to life than simply increasing its speed." - Mahatma Gandhi|||On Tue, 23 Mar 2004 21:32:35 -0700, Sue Hoegemeier
<Sue_H@.nomail.please> wrote:
You are correct. To my horror I found that:
sp_renamedb 'pubs', '123'
works, while BOL clearly has strict rules about the first character of
an identifier.
Would it kill MSFT to implement those rules, and not allow identifiers
that it later can't work with?
-Tom.
>Many of the tools do not support non-standard object names.
>Even though SQL Server lets you create objects with invalid
>names they aren't really legal names. You can find the rules
>for object names in books online under the topic Using
>Identifiers
>-Sue
>On Tue, 23 Mar 2004 19:39:31 -0700, Tom van Stiphout
><tom7744@.no.spam.cox.net> wrote:
>|||You could always send your request for this to
sqlwish@.microsoft.com
-Sue
On Wed, 24 Mar 2004 06:56:01 -0700, Tom van Stiphout
<tom7744@.no.spam.cox.net> wrote:
>On Tue, 23 Mar 2004 21:32:35 -0700, Sue Hoegemeier
><Sue_H@.nomail.please> wrote:
>You are correct. To my horror I found that:
>sp_renamedb 'pubs', '123'
>works, while BOL clearly has strict rules about the first character of
>an identifier.
>Would it kill MSFT to implement those rules, and not allow identifiers
>that it later can't work with?
>-Tom.
>