For me, quoted idenfiers is only for column names in select.
In table, constraint, etc, etc, names? Complete madness of
SQL Standard.

And even that use in column names I prefer to not use.
Is nothing more than a source of headache... If someday
I hire a DBA and see him/her starting doing what Kjell
talks, I send him/her a message: "If like the job, get
rid of that quoted idenfiers except the ones that you have
a very strong reason to do that way. And ask my permission
before use quote on those exceptions".

Clientes, CLIENTES, ClIeNtEs e clientes are the same thing.
Automóvel, Automovel, automóvel e AutoMovel are that same
thing - so call it AUTOMOVEL. Not accent sensitive, not
case sensitive, not *nothing* sensitive.

I would economize hundreds of hour of useless meetings
if I had followed it and the column names are just the
field names.

And yes, I'm radical about this point. Identifiers are
pure ascii. String *data* is what that is stored in
national chars. No trouble, no mess.

On Sat, 19 Mar 2005 18:47:25 +0100, Kjell Rilbe wrote:

>
>Martijn Tonies wrote:
>
>>>>In SQL Server, there was this system table INDEXES. It was
>>>>defined as "indexes". Guess what happens on a server with a
>>>>Turkish collation as the server wide collation?
>>>>
>>>>indexes uppercased becomes ÍNDEXES because the small
>>>>character "i" becomes "Í" and not "I".
>>>
>>>On the other hand, since quoted identifiers are case sensitive, this
>>>wouldn't be a problem.
>>
>> I wasn't talking about quotes, I was talking about nationalization.
>
>Yes, but they go hand in hand. At least *I'm* not asking for support for
>national characters in *un*quoted identifiers. But in *quoted* ones, YES!
>
>Kjell
>--
>--------------------------------------
>Kjell Rilbe
>Adressmarknaden AM AB
>E-post: kjell.rilbe@...
>Telefon: 08-761 06 55
>Mobil: 0733-44 24 64
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>