Tuesday, February 14, 2012
character sets, sort order, collations
I see that the output for sp_helpsort has changed, such that it used to be
more helpful than it is now. I guess it changed at some point. On a SQL 7
system, I can easily get the charset and sortorder (below), as well as a
listing of the characters in order.
Character Set = 1, iso_1
ISO 8859-1 (Latin-1) - Western European 8-bit character set.
Sort Order = 52, nocase_iso
Case-insensitive dictionary sort order for use with several We
stern-European languages including English, French, and German
. Uses the ISO 8859-1 character set.
Alternatively, EXEC sp_serverinfo 18: charset=iso_1 sort_order=nocase_iso
charset_num=1 sort_order_num=52
But on some SQL 2000 systems, sp_helpsort returns:
Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive,
width-insensitive
And EXEC sp_server_info 18: charset=iso_1 collation=Latin1_General_CI_AS
How do I confirm that newer systems are 72 - nocase_1252 rather than 52 -
nocase_iso when such descriptive output isn't provided any more?
Dale.these might be of help:
http://msdn.microsoft.com/library/en-us/instsql/in_collation_3oa6.asp
select *
from ::fn_helpcollations()
-oj
<Dale Kerr> wrote in message news:%23GKAhQovFHA.3152@.TK2MSFTNGP12.phx.gbl...
> Just trying to determine character set and sort order for a couple
> servers. I see that the output for sp_helpsort has changed, such that it
> used to be more helpful than it is now. I guess it changed at some point.
> On a SQL 7 system, I can easily get the charset and sortorder (below), as
> well as a listing of the characters in order.
> Character Set = 1, iso_1
> ISO 8859-1 (Latin-1) - Western European 8-bit character set.
> Sort Order = 52, nocase_iso
> Case-insensitive dictionary sort order for use with several We
> stern-European languages including English, French, and German
> . Uses the ISO 8859-1 character set.
> Alternatively, EXEC sp_serverinfo 18: charset=iso_1 sort_order=nocase_iso
> charset_num=1 sort_order_num=52
> But on some SQL 2000 systems, sp_helpsort returns:
> Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive,
> width-insensitive
> And EXEC sp_server_info 18: charset=iso_1 collation=Latin1_General_CI_AS
> How do I confirm that newer systems are 72 - nocase_1252 rather than 52 -
> nocase_iso when such descriptive output isn't provided any more?
> Dale.
>|||Cheers, I'll see if I can get my head around it.
"oj" <nospam_ojngo@.home.com> wrote in message
news:O4k18covFHA.2880@.TK2MSFTNGP12.phx.gbl...
> these might be of help:
> http://msdn.microsoft.com/library/en-us/instsql/in_collation_3oa6.asp
> select *
> from ::fn_helpcollations()
character sets, sort order, collations
I see that the output for sp_helpsort has changed, such that it used to be
more helpful than it is now. I guess it changed at some point. On a SQL 7
system, I can easily get the charset and sortorder (below), as well as a
listing of the characters in order.
Character Set = 1, iso_1
ISO 8859-1 (Latin-1) - Western European 8-bit character set.
Sort Order = 52, nocase_iso
Case-insensitive dictionary sort order for use with several We
stern-European languages including English, French, and German
. Uses the ISO 8859-1 character set.
Alternatively, EXEC sp_serverinfo 18: charset=iso_1 sort_order=nocase_iso
charset_num=1 sort_order_num=52
But on some SQL 2000 systems, sp_helpsort returns:
Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive,
width-insensitive
And EXEC sp_server_info 18: charset=iso_1 collation=Latin1_General_CI_AS
How do I confirm that newer systems are 72 - nocase_1252 rather than 52 -
nocase_iso when such descriptive output isn't provided any more?
Dale.these might be of help:
http://msdn.microsoft.com/library/e...lation_3oa6.asp
select *
from ::fn_helpcollations()
-oj
<Dale Kerr> wrote in message news:%23GKAhQovFHA.3152@.TK2MSFTNGP12.phx.gbl...
> Just trying to determine character set and sort order for a couple
> servers. I see that the output for sp_helpsort has changed, such that it
> used to be more helpful than it is now. I guess it changed at some point.
> On a SQL 7 system, I can easily get the charset and sortorder (below), as
> well as a listing of the characters in order.
> Character Set = 1, iso_1
> ISO 8859-1 (Latin-1) - Western European 8-bit character set.
> Sort Order = 52, nocase_iso
> Case-insensitive dictionary sort order for use with several We
> stern-European languages including English, French, and German
> . Uses the ISO 8859-1 character set.
> Alternatively, EXEC sp_serverinfo 18: charset=iso_1 sort_order=nocase_iso
> charset_num=1 sort_order_num=52
> But on some SQL 2000 systems, sp_helpsort returns:
> Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive,
> width-insensitive
> And EXEC sp_server_info 18: charset=iso_1 collation=Latin1_General_CI_AS
> How do I confirm that newer systems are 72 - nocase_1252 rather than 52 -
> nocase_iso when such descriptive output isn't provided any more?
> Dale.
>|||Cheers, I'll see if I can get my head around it.
"oj" <nospam_ojngo@.home.com> wrote in message
news:O4k18covFHA.2880@.TK2MSFTNGP12.phx.gbl...
> these might be of help:
> http://msdn.microsoft.com/library/e...lation_3oa6.asp
> select *
> from ::fn_helpcollations()
character sets, sort order, collations
I see that the output for sp_helpsort has changed, such that it used to be
more helpful than it is now. I guess it changed at some point. On a SQL 7
system, I can easily get the charset and sortorder (below), as well as a
listing of the characters in order.
Character Set = 1, iso_1
ISO 8859-1 (Latin-1) - Western European 8-bit character set.
Sort Order = 52, nocase_iso
Case-insensitive dictionary sort order for use with several We
stern-European languages including English, French, and German
. Uses the ISO 8859-1 character set.
Alternatively, EXEC sp_serverinfo 18: charset=iso_1 sort_order=nocase_iso
charset_num=1 sort_order_num=52
But on some SQL 2000 systems, sp_helpsort returns:
Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive,
width-insensitive
And EXEC sp_server_info 18: charset=iso_1 collation=Latin1_General_CI_AS
How do I confirm that newer systems are 72 - nocase_1252 rather than 52 -
nocase_iso when such descriptive output isn't provided any more?
Dale.
these might be of help:
http://msdn.microsoft.com/library/en...ation_3oa6.asp
select *
from ::fn_helpcollations()
-oj
<Dale Kerr> wrote in message news:%23GKAhQovFHA.3152@.TK2MSFTNGP12.phx.gbl...
> Just trying to determine character set and sort order for a couple
> servers. I see that the output for sp_helpsort has changed, such that it
> used to be more helpful than it is now. I guess it changed at some point.
> On a SQL 7 system, I can easily get the charset and sortorder (below), as
> well as a listing of the characters in order.
> Character Set = 1, iso_1
> ISO 8859-1 (Latin-1) - Western European 8-bit character set.
> Sort Order = 52, nocase_iso
> Case-insensitive dictionary sort order for use with several We
> stern-European languages including English, French, and German
> . Uses the ISO 8859-1 character set.
> Alternatively, EXEC sp_serverinfo 18: charset=iso_1 sort_order=nocase_iso
> charset_num=1 sort_order_num=52
> But on some SQL 2000 systems, sp_helpsort returns:
> Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive,
> width-insensitive
> And EXEC sp_server_info 18: charset=iso_1 collation=Latin1_General_CI_AS
> How do I confirm that newer systems are 72 - nocase_1252 rather than 52 -
> nocase_iso when such descriptive output isn't provided any more?
> Dale.
>
|||Cheers, I'll see if I can get my head around it.
"oj" <nospam_ojngo@.home.com> wrote in message
news:O4k18covFHA.2880@.TK2MSFTNGP12.phx.gbl...
> these might be of help:
> http://msdn.microsoft.com/library/en...ation_3oa6.asp
> select *
> from ::fn_helpcollations()
character sets in SQL server
My client has a need to be able to store Japanese characters in their
PeopleSoft database. So we need to change the character set from from
Latin1_General (1252) to Japanese character set (932) on SQL Server
2000 Enterprise. I have 2 questions:
1) I would like to know if in SQL Server, the character set is machine
specific or is it defined at the database instance level?
2) Can multiple installs of SQL Server co-exist on a single server with
different default character sets?
Thanks
VishalVishal (vverma2@.gmail.com) writes:
> My client has a need to be able to store Japanese characters in their
> PeopleSoft database. So we need to change the character set from from
> Latin1_General (1252) to Japanese character set (932) on SQL Server
> 2000 Enterprise. I have 2 questions:
> 1) I would like to know if in SQL Server, the character set is machine
> specific or is it defined at the database instance level?
> 2) Can multiple installs of SQL Server co-exist on a single server with
> different default character sets?
First, you did not say which version of SQL Server you are using. The
answer is not same for SQL 7 and SQL 2000.
On SQL 7, you can only have one single sortorder - and a sortorder implies
a character set - on the server.
On SQL 2000, you can have multiple collations - as the terminolgy is on
SQL 2000 - on the same same server. In fact, every column have its own
collation. Thus, in theory you could create the PeopleSoft database to
use a suitable collation. Problem is if Peoplesoft does make use of
temp tables, in which case you will get collation conflicts when you
join temp tables with regular tables. Use of temp tables is quite common...
So in practice you is likely to have to change the collation for tempdb,
and that means that you have to rebuild the master database. (And this is
about as close as reinstallation of SQL Server you can come.) If you are
setting up a new server for PeopleSoft, this is not much of an issue anyway.
If you have several instances of SQL Server running on the same box,
they can use completely different collations, they are entirely
independent of each other.
Now, whether PeopleSoft supports the Japanese stuff, I don't know, but
I assume you've sorted that out with PeopleSoft already.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
character sets in SQL server
My client has a need to be able to store Japanese characters in their
PeopleSoft database. So we need to change the character set from from
Latin1_General (1252) to Japanese character set (932) on SQL Server
2000 Enterprise. I have 2 questions:
1) I would like to know if in SQL Server, the character set is machine
specific or is it defined at the database instance level?
2) Can multiple installs of SQL Server co-exist on a single server with
different default character sets?
Thanks
Vishal
Vishal (vverma2@.gmail.com) writes:
> My client has a need to be able to store Japanese characters in their
> PeopleSoft database. So we need to change the character set from from
> Latin1_General (1252) to Japanese character set (932) on SQL Server
> 2000 Enterprise. I have 2 questions:
> 1) I would like to know if in SQL Server, the character set is machine
> specific or is it defined at the database instance level?
> 2) Can multiple installs of SQL Server co-exist on a single server with
> different default character sets?
First, you did not say which version of SQL Server you are using. The
answer is not same for SQL 7 and SQL 2000.
On SQL 7, you can only have one single sortorder - and a sortorder implies
a character set - on the server.
On SQL 2000, you can have multiple collations - as the terminolgy is on
SQL 2000 - on the same same server. In fact, every column have its own
collation. Thus, in theory you could create the PeopleSoft database to
use a suitable collation. Problem is if Peoplesoft does make use of
temp tables, in which case you will get collation conflicts when you
join temp tables with regular tables. Use of temp tables is quite common...
So in practice you is likely to have to change the collation for tempdb,
and that means that you have to rebuild the master database. (And this is
about as close as reinstallation of SQL Server you can come.) If you are
setting up a new server for PeopleSoft, this is not much of an issue anyway.
If you have several instances of SQL Server running on the same box,
they can use completely different collations, they are entirely
independent of each other.
Now, whether PeopleSoft supports the Japanese stuff, I don't know, but
I assume you've sorted that out with PeopleSoft already.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Character sets
to this, but would like some confirmation. I am running SQL Server 2000 on a
Windows 2003 server machine. The database is installed with the standard
English collation. Is it possible for me to insert Japanese characters into
the database like in, perhaps the name field so that I have English and
Japanese characters within the same field in the same table? I know I can do
some special characters (like an umlaut or grave etc.), but haven't had any
luck with double byte characters, and perhaps I am just beating my head
against the wall? Thanks for any information you can help me with.
WillieYou can use a Unicode datatype (e.g. nvarchar) in order to store both
English and Japanese characters in the same column. Values will be stored
using UCS-2 encoding.
Hope this helps.
Dan Guzman
SQL Server MVP
"Willie Bodger" <williebnospam@.lap_ink.c_m> wrote in message
news:uKddbr1rGHA.1592@.TK2MSFTNGP02.phx.gbl...
> So, I've looked around, read what I can find and I think I know the answer
> to this, but would like some confirmation. I am running SQL Server 2000 on
> a Windows 2003 server machine. The database is installed with the standard
> English collation. Is it possible for me to insert Japanese characters
> into the database like in, perhaps the name field so that I have English
> and Japanese characters within the same field in the same table? I know I
> can do some special characters (like an umlaut or grave etc.), but haven't
> had any luck with double byte characters, and perhaps I am just beating my
> head against the wall? Thanks for any information you can help me with.
> Willie
>
Character sets
to this, but would like some confirmation. I am running SQL Server 2000 on a
Windows 2003 server machine. The database is installed with the standard
English collation. Is it possible for me to insert Japanese characters into
the database like in, perhaps the name field so that I have English and
Japanese characters within the same field in the same table? I know I can do
some special characters (like an umlaut or grave etc.), but haven't had any
luck with double byte characters, and perhaps I am just beating my head
against the wall? Thanks for any information you can help me with.
WillieYou can use a Unicode datatype (e.g. nvarchar) in order to store both
English and Japanese characters in the same column. Values will be stored
using UCS-2 encoding.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Willie Bodger" <williebnospam@.lap_ink.c_m> wrote in message
news:uKddbr1rGHA.1592@.TK2MSFTNGP02.phx.gbl...
> So, I've looked around, read what I can find and I think I know the answer
> to this, but would like some confirmation. I am running SQL Server 2000 on
> a Windows 2003 server machine. The database is installed with the standard
> English collation. Is it possible for me to insert Japanese characters
> into the database like in, perhaps the name field so that I have English
> and Japanese characters within the same field in the same table? I know I
> can do some special characters (like an umlaut or grave etc.), but haven't
> had any luck with double byte characters, and perhaps I am just beating my
> head against the wall? Thanks for any information you can help me with.
> Willie
>