Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" <testwindows@discussions.microsoft.com> a écrit dans le
message de news: 77B05462-0A8C-481E-BC13-058C5FC30A9F@microsoft.com...
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Il faut vraiment être sûr de l'avenir!
br
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Il faut vraiment être sûr de l'avenir!
br
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:O0OGWOj7HHA.5160@TK2MSFTNGP05.phx.gbl...
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" <testwindows@discussions.microsoft.com> a écrit dans le
message de news: 77B05462-0A8C-481E-BC13-058C5FC30A9F@microsoft.com...
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Il faut vraiment être sûr de l'avenir!
br
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Il faut vraiment être sûr de l'avenir!
br
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Il faut vraiment être sûr de l'avenir!
br
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:O0OGWOj7HHA.5160@TK2MSFTNGP05.phx.gbl...
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" <testwindows@discussions.microsoft.com> a écrit dans le
message de news: 77B05462-0A8C-481E-BC13-058C5FC30A9F@microsoft.com...
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Il faut vraiment être sûr de l'avenir!
br
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" <testwindows@discussions.microsoft.com> a écrit dans le
message de news: 77B05462-0A8C-481E-BC13-058C5FC30A9F@microsoft.com...
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
"test windows" a écrit dans le
message de news:Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page Windows
que le serveur SQL; au présent et dans le futur. Prenez pas exemple une
personne vivant en Grèce. Pensez-vous vraiment que son choix de vie est de
toujours avoir un code page français sur sa machine?
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page Windows
que le serveur SQL; au présent et dans le futur. Prenez pas exemple une
personne vivant en Grèce. Pensez-vous vraiment que son choix de vie est de
toujours avoir un code page français sur sa machine?
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page Windows
que le serveur SQL; au présent et dans le futur. Prenez pas exemple une
personne vivant en Grèce. Pensez-vous vraiment que son choix de vie est de
toujours avoir un code page français sur sa machine?
Sylvain Lafontaine wrote:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son choix
de vie est de toujours avoir un code page français sur sa machine?
?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !
Un Windows asiatique dont le charset par défaut serait GB-2312 pourra très
bien accéder et afficher les données d'un varchar contenant des données en
français dans une table dont la collation est en windows-1252 !
Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée sur
cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.
Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.
Sylvain Lafontaine wrote:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son choix
de vie est de toujours avoir un code page français sur sa machine?
?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !
Un Windows asiatique dont le charset par défaut serait GB-2312 pourra très
bien accéder et afficher les données d'un varchar contenant des données en
français dans une table dont la collation est en windows-1252 !
Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée sur
cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.
Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.
Sylvain Lafontaine wrote:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son choix
de vie est de toujours avoir un code page français sur sa machine?
?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !
Un Windows asiatique dont le charset par défaut serait GB-2312 pourra très
bien accéder et afficher les données d'un varchar contenant des données en
français dans une table dont la collation est en windows-1252 !
Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée sur
cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.
Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.
Première des choses, vous ne pouvez pas avoir une table dont la collation
est en Windows-1252. Il y a bien des collations 1250 telles que
SQL_Latin1_General_CP1250_CI_AS mais quand MS a introduit la collaton 1252
afin de tenir compte du symbole Euro, cet ajout ne semble pas avoir été
introduit dans les vieilles collations de compatibilité de SQL-Server.
Cependant, je peux me tromper sur ce point particulier surtout que pour
moi, l'utilisation du symbole Euro n'a pas vraiment d'importance.
Pour ce qui est du charset par défaut de l'environmment, il n'y a en pas
un mais deux: il y a l'OEM (à ne pas confondre avec la vente de matériel
OEM et les versions OEM de Windows) et la Windows. Certains clients vont
utiliser l'OEM et d'autres (la majorité) la Windows. Pour ceux qui vont
utiliser la Windows, certains vont encoder les caractères et d'autres pas
et parmi ceux qui vont le faire, certains pourront le faire de façon
facultative selon le choix du mode d'affichage utilisé. Même pour ceux
qui ne touchent pas à l'encodage, certains pilotes pourront faire ou non
l'encodage, de façon obligatoire ou facultative seront un paramètre de
configuration. (Cet encodage par les pilotes est une des raisons majeures
pour utiliser le préfixe N' ). Lorsqu'il y a un paramètre de
configuration, ce dernier peut être situé quelquefois dans la chaîne de
connexion; quelquefois dans la base de registres et quelquefois dans les
deux. Il y a aussi les paramètres dans la base de registres pour d'autres
programmes qui peuvent influencer le tout (voilà quelques années, cela m'a
pris plusieurs jours afin de déterminer pourquoi l'importation à partir de
fichiers Excel ne fonctionnait pas correctement sur les machines sur
lesquelles Interbase (la bdd de Borland) avait aussi été installé avant de
trouver qu'Interbase modifiait un paramètre dans la base de registres pour
JET et que la méthode utilisée pour importer les données à partir d'Excel
utilisait JET ODBC.
Vous dites que vous avez toutes les couches intermédiaires pour réaliser
les transcodages nécessaires; j'en suis bien content pour vous! Le
problème est, j'ai déjà appelé en consultation pour régler des problèmes
d'encodages sur des systèmes pour lesquelles le ou les développeurs me
disaient qu'il était impossible qu'il y ait le moindre problème puisqu'ils
avaient supposément toutes les couches nécessaires. S'il est impossible
qu'il y ait un problème, alors pourquoi y en a-t-il un???
La principale raison évoquée pour se casser la tête (et quelquefois les
coui**es) avec l'ANSI sur SQL-Server en est un de performance: on dit
souvent que cela va aller plus vite. Dans la plupart des cas, la
différence est imperceptible ou inutile (la seule différence notable que
je connaisse est avec l'utilisation de l'opérateur LIKE '%xxxx%' et même
là, vous êtes généralement mieux avec l'utilisation d'une deuxième colonne
inversée que de vous fier sur ANSI) et généralement, si vous avez un
problème de performance quelconque, vous êtes mieux d'analyser et de
corriger votre design que de vous fiez sur ANSI à la place d'Unicode.
La seule chose que j'ai vu dans le passé pour ceux qui s'obstinaient à
vouloir conserver l'ANSI à la place d'Unicode a été une perte de temps (et
considérable le plus souvent qu'autrement).
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Pierre Goiffon" wrote in message
news:46dd0f06$0$9225$Sylvain Lafontaine wrote:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son
choix de vie est de toujours avoir un code page français sur sa machine?
?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !
Un Windows asiatique dont le charset par défaut serait GB-2312 pourra
très bien accéder et afficher les données d'un varchar contenant des
données en français dans une table dont la collation est en windows-1252
!
Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée
sur cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.
Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.
Première des choses, vous ne pouvez pas avoir une table dont la collation
est en Windows-1252. Il y a bien des collations 1250 telles que
SQL_Latin1_General_CP1250_CI_AS mais quand MS a introduit la collaton 1252
afin de tenir compte du symbole Euro, cet ajout ne semble pas avoir été
introduit dans les vieilles collations de compatibilité de SQL-Server.
Cependant, je peux me tromper sur ce point particulier surtout que pour
moi, l'utilisation du symbole Euro n'a pas vraiment d'importance.
Pour ce qui est du charset par défaut de l'environmment, il n'y a en pas
un mais deux: il y a l'OEM (à ne pas confondre avec la vente de matériel
OEM et les versions OEM de Windows) et la Windows. Certains clients vont
utiliser l'OEM et d'autres (la majorité) la Windows. Pour ceux qui vont
utiliser la Windows, certains vont encoder les caractères et d'autres pas
et parmi ceux qui vont le faire, certains pourront le faire de façon
facultative selon le choix du mode d'affichage utilisé. Même pour ceux
qui ne touchent pas à l'encodage, certains pilotes pourront faire ou non
l'encodage, de façon obligatoire ou facultative seront un paramètre de
configuration. (Cet encodage par les pilotes est une des raisons majeures
pour utiliser le préfixe N' ). Lorsqu'il y a un paramètre de
configuration, ce dernier peut être situé quelquefois dans la chaîne de
connexion; quelquefois dans la base de registres et quelquefois dans les
deux. Il y a aussi les paramètres dans la base de registres pour d'autres
programmes qui peuvent influencer le tout (voilà quelques années, cela m'a
pris plusieurs jours afin de déterminer pourquoi l'importation à partir de
fichiers Excel ne fonctionnait pas correctement sur les machines sur
lesquelles Interbase (la bdd de Borland) avait aussi été installé avant de
trouver qu'Interbase modifiait un paramètre dans la base de registres pour
JET et que la méthode utilisée pour importer les données à partir d'Excel
utilisait JET ODBC.
Vous dites que vous avez toutes les couches intermédiaires pour réaliser
les transcodages nécessaires; j'en suis bien content pour vous! Le
problème est, j'ai déjà appelé en consultation pour régler des problèmes
d'encodages sur des systèmes pour lesquelles le ou les développeurs me
disaient qu'il était impossible qu'il y ait le moindre problème puisqu'ils
avaient supposément toutes les couches nécessaires. S'il est impossible
qu'il y ait un problème, alors pourquoi y en a-t-il un???
La principale raison évoquée pour se casser la tête (et quelquefois les
coui**es) avec l'ANSI sur SQL-Server en est un de performance: on dit
souvent que cela va aller plus vite. Dans la plupart des cas, la
différence est imperceptible ou inutile (la seule différence notable que
je connaisse est avec l'utilisation de l'opérateur LIKE '%xxxx%' et même
là, vous êtes généralement mieux avec l'utilisation d'une deuxième colonne
inversée que de vous fier sur ANSI) et généralement, si vous avez un
problème de performance quelconque, vous êtes mieux d'analyser et de
corriger votre design que de vous fiez sur ANSI à la place d'Unicode.
La seule chose que j'ai vu dans le passé pour ceux qui s'obstinaient à
vouloir conserver l'ANSI à la place d'Unicode a été une perte de temps (et
considérable le plus souvent qu'autrement).
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Pierre Goiffon" <pgoiffon@free.fr.invalid> wrote in message
news:46dd0f06$0$9225$426a74cc@news.free.fr...
Sylvain Lafontaine wrote:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !
Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son
choix de vie est de toujours avoir un code page français sur sa machine?
?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !
Un Windows asiatique dont le charset par défaut serait GB-2312 pourra
très bien accéder et afficher les données d'un varchar contenant des
données en français dans une table dont la collation est en windows-1252
!
Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée
sur cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.
Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.
Première des choses, vous ne pouvez pas avoir une table dont la collation
est en Windows-1252. Il y a bien des collations 1250 telles que
SQL_Latin1_General_CP1250_CI_AS mais quand MS a introduit la collaton 1252
afin de tenir compte du symbole Euro, cet ajout ne semble pas avoir été
introduit dans les vieilles collations de compatibilité de SQL-Server.
Cependant, je peux me tromper sur ce point particulier surtout que pour
moi, l'utilisation du symbole Euro n'a pas vraiment d'importance.
Pour ce qui est du charset par défaut de l'environmment, il n'y a en pas
un mais deux: il y a l'OEM (à ne pas confondre avec la vente de matériel
OEM et les versions OEM de Windows) et la Windows. Certains clients vont
utiliser l'OEM et d'autres (la majorité) la Windows. Pour ceux qui vont
utiliser la Windows, certains vont encoder les caractères et d'autres pas
et parmi ceux qui vont le faire, certains pourront le faire de façon
facultative selon le choix du mode d'affichage utilisé. Même pour ceux
qui ne touchent pas à l'encodage, certains pilotes pourront faire ou non
l'encodage, de façon obligatoire ou facultative seront un paramètre de
configuration. (Cet encodage par les pilotes est une des raisons majeures
pour utiliser le préfixe N' ). Lorsqu'il y a un paramètre de
configuration, ce dernier peut être situé quelquefois dans la chaîne de
connexion; quelquefois dans la base de registres et quelquefois dans les
deux. Il y a aussi les paramètres dans la base de registres pour d'autres
programmes qui peuvent influencer le tout (voilà quelques années, cela m'a
pris plusieurs jours afin de déterminer pourquoi l'importation à partir de
fichiers Excel ne fonctionnait pas correctement sur les machines sur
lesquelles Interbase (la bdd de Borland) avait aussi été installé avant de
trouver qu'Interbase modifiait un paramètre dans la base de registres pour
JET et que la méthode utilisée pour importer les données à partir d'Excel
utilisait JET ODBC.
Vous dites que vous avez toutes les couches intermédiaires pour réaliser
les transcodages nécessaires; j'en suis bien content pour vous! Le
problème est, j'ai déjà appelé en consultation pour régler des problèmes
d'encodages sur des systèmes pour lesquelles le ou les développeurs me
disaient qu'il était impossible qu'il y ait le moindre problème puisqu'ils
avaient supposément toutes les couches nécessaires. S'il est impossible
qu'il y ait un problème, alors pourquoi y en a-t-il un???
La principale raison évoquée pour se casser la tête (et quelquefois les
coui**es) avec l'ANSI sur SQL-Server en est un de performance: on dit
souvent que cela va aller plus vite. Dans la plupart des cas, la
différence est imperceptible ou inutile (la seule différence notable que
je connaisse est avec l'utilisation de l'opérateur LIKE '%xxxx%' et même
là, vous êtes généralement mieux avec l'utilisation d'une deuxième colonne
inversée que de vous fier sur ANSI) et généralement, si vous avez un
problème de performance quelconque, vous êtes mieux d'analyser et de
corriger votre design que de vous fiez sur ANSI à la place d'Unicode.
La seule chose que j'ai vu dans le passé pour ceux qui s'obstinaient à
vouloir conserver l'ANSI à la place d'Unicode a été une perte de temps (et
considérable le plus souvent qu'autrement).
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Pierre Goiffon" wrote in message
news:46dd0f06$0$9225$Sylvain Lafontaine wrote:Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son
choix de vie est de toujours avoir un code page français sur sa machine?
?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !
Un Windows asiatique dont le charset par défaut serait GB-2312 pourra
très bien accéder et afficher les données d'un varchar contenant des
données en français dans une table dont la collation est en windows-1252
!
Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée
sur cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.
Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.