unicode ou non-unicode

Bonjour,
comment savoir si ma base de données SQL-SERVER 2005 est en unicode ou non-unicode ?

D'avance merci.

Bonjour,

Code:

---

SELECT sys.databases.name, sys.databases.collation_name FROM sys.databases

---

Vous retourne la collation.


Pour plus d'info sur la collation :
http://msdn.microsoft.com/en-us/libr...v=sql.90).aspx

Bonne journée,

merci pour la réponse et je reçois :

Code:

---

1 2 3 4 5

SELECT sys.DATABASES.name, sys.DATABASES.collation_name FROM sys.DATABASES   Msg 208, Level 16, State 1, Line 1 Nom d'objet 'sys.DATABASES' non valide.

---

Dois-je mettre le nom de ma base pour DATABASES ?

Merci encore.

Re,

peut être un problème de droits.

Pouvez vous vérifier que vous avez les bon droits :

http://msdn.microsoft.com/fr-fr/libr...v=sql.90).aspx

Pour connaitre la liste de vos droits :

Code:

---

1 2 3 4

SELECT * FROM fn_my_permissions(NULL, NULL)   SELECT * FROM fn_my_permissions (NULL, 'DATABASE');

---

Bonne journée,

je me connect en tant que SA alors je devrais avoir tous les droits.

D'avance merci.

Essaye cette commande :

Code:

---

SELECT DATABASEPROPERTYEX('IciTaBase', 'Collation')

---

Tu peux aussi exécuter la commande ci-après en remplaçant DATABASES par databases c-a-d en tout en minuscule, peut être que ta collation est sensible à la casse !

Code:

---

SELECT name, collation_name FROM sys.databases

---

Merci pour la réponse :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

SELECT DATABASEPROPERTYEX('IciTaBase', 'Collation') ---------------------------------- NULL   (1 row(s) affected)   SELECT name, collation_name FROM sys.database name collation_name ---------------------------------------------- master Latin1_General_BIN2 tempdb Latin1_General_BIN2

---

Donc la deuxième requête dit que l'on est en Latin1_General_BIN2. est-ce unicode ou non-unicode ?

Noooon ! ;)
on va recommencer
1. Dans la commande ci-après, tu vas remplacer "maBase" par le nom de ta base de données.

Code:

---

SELECT DATABASEPROPERTYEX('maBase', 'Collation')

---

Donc si tu as une base qui a pour "toto" tu dois exécuter

Code:

---

SELECT DATABASEPROPERTYEX('toto', 'Collation')

---

et si tu as une base qui a pour nom "titi" tu dois exécuter

Code:

---

SELECT DATABASEPROPERTYEX('titi', 'Collation')

---

2.
Par contre les bases master et tempdb que tu montres pour l'autre commande sont des bases systèmes, la requête ne t'affiche que ces 2 bases ? je ne pense pas ! il faut nous en dire plus

Merci encore pour votre patience :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SELECT name, collation_name FROM sys.databases   name collation_name ---------------------------------------------- mabase Latin1_General_BIN     SELECT DATABASEPROPERTYEX('mabase', 'Collation')   ------------------------------------------------- Latin1_General_BIN   (1 row(s) affected)

---

Merci d'avance

A noter ce n'est pas sys.DATABASES, mais sys.databases (en minuscules). Si la collation d’installation du serveur est forte, sys.DATABASES renverra un message d'erreur : objet non trouvé.

A +

oui et merci Frédéric.

Unicode ou non-unicode ?

Citation:

---

Envoyé par big1

Unicode ou non-unicode ?

---

Vous avez mal formulé votre question et du coup on vous a conduit vers une fausse piste : collation, etc ...

unicode ou non-unicode se définit au niveau de la colonne. Et il y a des types de données qui sont prévus pour stocker des données unicode : nchar, nvarchar,...

la collation se définit à différent niveau : instance, base, table et colonne.
Et le choix de la collation influence les opérations de comparaison, de trie,...

il ne faut pas confondre donnée unicode/non-unicode et collation.

Pour plus de détails sur la collation Latin1_General_BIN de ta base

Merci Etienne.

On m'a posé la question : est-ce que la base (SQLSERVER 2005) est UNICODE ou NON-UNICODE.

Pour moi avoir connu ORACLE c'est une caracteristique générale pour la base et dépend du CHARCTERSET. Voici extrait du documentation peoplesoft pour le base de données Oracle.
D'après PeopleTools 8.52 Installation for Oracle

Citation:

---

To create an Oracle Unicode database, you must specify the character set as either AL32UTF8 or UTF-8

---

Et pour les bases MSSQLSERVER :

Citation:

---

Using Non-Unicode Databases
Use these considerations for environments that support one language: The suggested collation for most
PeopleSoft databases is Latin1_General_Bin. This supports Western European languages (English, Danish,
Dutch, Finnish, French, German, Italian,
...................

---

J'en conclus que puisque en Latin1_General_Bin donc nous sommes en non-unicode.
Cordialement.

Que dit la documentation peoplesoft pour la base de données SQL SERVER ?

Citation:

---

Envoyé par big1

Et pour les bases MSSQLSERVER :

Citation:

---

Using Non-Unicode Databases
Use these considerations for environments that support one language: The suggested collation for most
PeopleSoft databases is Latin1_General_Bin. This supports Western European languages (English, Danish,
Dutch, Finnish, French, German, Italian,
...................

---

J'en conclus que puisque en Latin1_General_Bin donc nous sommes en non-unicode.
Cordialement.

---

Vous n'avez pas encore bien compris que la collation (classement) n'a rien avoir avec des données unicode/non-unicode !
Autrement dit sous SQL Server IL N'Y A PAS DE COLLATION UNICODE ! ça ne veut rien dire et ça n'a de sens !
Par contre vous pouvez définir des colonnes pour stocker des données de type UNICODE : nchar, nvarchar

La collation (classement) sert pour des opérations de comparaisons et de trie.

Bonjour,

Citation:

---

Envoyé par zinzineti

Vous n'avez pas encore bien compris que la collation (classement) n'a rien avoir avec des données unicode/non-unicode ! ... La collation (classement) sert pour des opérations de comparaisons et de trie.

---

Hé oui !

Ce qu'il faut retenir c'est :

- si l'on a besoin de stocker des caractères non-Latins (langues Asiatiques, Arabes, ...) alors vous allez être obligé d'utiliser une colonne de type nchar ou nvarchar : celles-ci utilisent Unicode pour stocker ces caractères, puisqu'Unicode le supporte (et pas ASCII). Les valeurs de chaîne que vous stockerez occuperont 2 octets par caractère.

- si l'on n'a besoin que de stocker des caractères Latins, ASCII est amplement suffisant pour cela, et le recours aux types de données char et varchar est approprié. Ici les valeurs de chaîne occuperont 1 octet par caractère.

- les collations n'influencent que la façon dont sont ordonnés les résultats d'une classement sur des chaînes de caractère (ORDER BY, GROUP BY, ...), et rien d'autre.

Vous pouvez donc utiliser n'importe quelle collation en combinaison avec des colonnes qui supportent l'Unicode ou seulement l'ASCII.
Le tri et le stockage de telles valeurs sont deux notions distinctes.

@++ ;)

oui en fait en Oracle la notion de collation n'est pas courante.

Alors difficile à saisir.
Autrement je conclus que une base MSSQLSERVER est à la fois UNICODE et NON-UNICODE.

Ai-je bien compris ?

Merci encore.

merci à tous.

J'aurai plutôt dit que SQL Server supporte à la fois l'ASCII et l'Unicode.
Il suffit d'adapter le type de données à ce que l'on souhaite stocker.

@++ ;)

Oracle supporte mal la notion de collation et propose un truc hors norme et peu pratique, le NLS.

Une collation est une propriété d'un type de données de nature littéral.
L'encodage est une autre caractéristique.

Vous pouvez avoir des littéraux encodés en ASCII donc CHAR(n) et VARCHAR(n) et des littéraux encodés en UNICODE, donc NCHAR(n) et NVARCHAR(n).
Le N signifiant NATIONAL.

De même une valeur chaine de caractères peut être ASCII ou UNICODE :
'toto' => chaine ASCII
N'toto' => chaine UNICODE.

A +