|
|
Posted by Tony Rogerson on 05/15/06 23:39
I think Nasir you've already been told several times how you can do this
with SQL Server.
I don't see a problem setting the database collation to case insensitive and
specifying at a column level the case sensitive option - you need only do it
once at CREATE TABLE time and its no more hassle then writing NOT NULL or
NULL, its COLLATE <collation name>.
I'd suggest you think this through a lot more, consider the problems with
data being case sensitive.
When you type in 'sql server' into google does it only bring back those
results that had 'sql server' in them or do they bring back the 'SQL Server'
ones too, or perhaps Oracle users have some mystical power that allows them
to sense correct case and type it correctly every time....
There is no benefit to case sensitivity unless you are enforcing it in the
real world and to my experience (19+ years of development) there are seldom
cases for case sensitive data.
Tony.
--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"Nasir" <nmajeed@prosrm.com> wrote in message
news:44689aae$0$1010$39cecf19@news.twtelecom.net...
> Thank you all for your commencts on this - I didn't know it is so common
> and relatively painful issue. Certainly, I wasn't expecting it, that ther
> eis no easy solution to this.
>
> My opinion is that table and column name should be insensitive by pretty
> much 80/20 or yet better 99/1 rule (it's a new one:-), the 1 only when we
> are looking for readability of the object or column name. To the contrary,
> we always need to read the data (actual information) from these tables and
> columns, so data got to be sensitive. I don't think people enjoy seeing
> there names in funny cases like mIKe vs Mike, let alone that e.e...example
> which I'm not aware of.
>
> More importatntly, if it is such a pain then why not provide this as an
> option in collation; if SQL server can give you so many other options,
> this one can also be included - specially when SQL server is not the
> leader in DB category.
>
> I think adopting a standard is good - so I'll be forced to use
> SQL_Latin1_General_CP1_CS_AS to keep all sensitive across the board to
> avoid confusions.
>
> chao,
> Nasir
>
>
>
>
> "Alexander Kuznetsov" <AK_TIREDOFSPAM@hotmail.COM> wrote in message
> news:1147491491.272900.168260@y43g2000cwc.googlegroups.com...
>>> With an ORDER BY the result > set is identical.
>>
>> Can you post versions of SQL Server and Oracle and operating systems
>> for which they are identical?
>>
>> In fact it is a well known little obstacle in migrations between
>> Oracle and SQL Server. More to the point, immediately before posting I
>> ran the script and cut and pasted my results. Repeat, the results as
>> harvested from 2 live servers several hours ago are different:
>>
>> SELECT * FROM T1 order by c1;
>>
>> SQL Server:
>>
>> c1
>> ----------
>> A_A
>> AAA
>>
>> (2 row(s) affected)
>>
>> drop table t1;
>>
>> The same script in Oracle running on UNIX (HP-UX) returns rows in a
>> different
>> order:
>>
>> C1
>> ----------
>> AAA
>> A_A
>>
>
>
Navigation:
[Reply to this message]
|