J'ai un petit soucis avec une base Oracle 10.2. La base en question
a été déclarée avec un charset WE8ISO8859P15 (donc en iso-latin-9 ou
iso-8859-15 ?).
Quand on insère un enregistrement dans une table, les caractères
euros sont transformés en point d'interrogation inversé, que cette
insertion se fasse via une appli java ou par toad.
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC (par exemple, à l'aide de SquirelSQL)? Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question. Désolé :(
Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Charly
Stephane Dupille a écrit :
TestMan écrit :
Bonjour,
Bonjour,
Quel est l'encodage interne de votre base ?
WE8ISO8859P15
Et le symbôle EURO, vous le tapez sous Windows ? Si tel est le cas, il faut faire attention que le code de caractère reçu par le client sera dans la norme WE8MSWIN1252, et on a vite les points d'interrogations inversés.
Pour éviter toute conversion, les NLS_LANG des postes de travail et serveurs utilisés doivent être conformes avec le "character set" de la base, soit dans ton cas WE8ISO8859P15, cela devrait marcher dans ce cas. (testé avec des caractères chinois stockés en WE8xxx au lieu de ZHxxx :-) )
[...]
Charly
Stephane Dupille a écrit :
TestMan <none@example.com> écrit :
Bonjour,
Bonjour,
Quel est l'encodage interne de votre base ?
WE8ISO8859P15
Et le symbôle EURO, vous le tapez sous Windows ? Si tel est le cas, il
faut faire attention que le code de caractère reçu par le client sera
dans la norme WE8MSWIN1252, et on a vite les points d'interrogations
inversés.
Pour éviter toute conversion, les NLS_LANG des postes de travail et
serveurs utilisés doivent être conformes avec le "character set" de la
base, soit dans ton cas WE8ISO8859P15, cela devrait marcher dans ce cas.
(testé avec des caractères chinois stockés en WE8xxx au lieu de ZHxxx :-) )
Et le symbôle EURO, vous le tapez sous Windows ? Si tel est le cas, il faut faire attention que le code de caractère reçu par le client sera dans la norme WE8MSWIN1252, et on a vite les points d'interrogations inversés.
Pour éviter toute conversion, les NLS_LANG des postes de travail et serveurs utilisés doivent être conformes avec le "character set" de la base, soit dans ton cas WE8ISO8859P15, cela devrait marcher dans ce cas. (testé avec des caractères chinois stockés en WE8xxx au lieu de ZHxxx :-) )
[...]
Charly
Stephane Dupille
Charly écrit :
Et le symbôle EURO, vous le tapez sous Windows ? Si tel est le cas, il faut faire attention que le code de caractère reçu par le client sera dans la norme WE8MSWIN1252, et on a vite les points d'interrogations inversés.
Oui.
Pour éviter toute conversion, les NLS_LANG des postes de travail et serveurs utilisés doivent être conformes avec le "character set" de la base, soit dans ton cas WE8ISO8859P15, cela devrait marcher dans ce cas. (testé avec des caractères chinois stockés en WE8xxx au lieu de ZHxxx :-) )
Marche avec un driver OCI, mais pas avec le driver THIN que j'utilise, qui ne comprends pas les variables d'environnement NLS.
Charly <No.Email@No.Spam> écrit :
Et le symbôle EURO, vous le tapez sous Windows ? Si tel est le cas, il
faut faire attention que le code de caractère reçu par le client sera
dans la norme WE8MSWIN1252, et on a vite les points d'interrogations
inversés.
Oui.
Pour éviter toute conversion, les NLS_LANG des postes de travail et
serveurs utilisés doivent être conformes avec le "character set" de la
base, soit dans ton cas WE8ISO8859P15, cela devrait marcher dans ce
cas.
(testé avec des caractères chinois stockés en WE8xxx au lieu de ZHxxx :-) )
Marche avec un driver OCI, mais pas avec le driver THIN que
j'utilise, qui ne comprends pas les variables d'environnement NLS.
Et le symbôle EURO, vous le tapez sous Windows ? Si tel est le cas, il faut faire attention que le code de caractère reçu par le client sera dans la norme WE8MSWIN1252, et on a vite les points d'interrogations inversés.
Oui.
Pour éviter toute conversion, les NLS_LANG des postes de travail et serveurs utilisés doivent être conformes avec le "character set" de la base, soit dans ton cas WE8ISO8859P15, cela devrait marcher dans ce cas. (testé avec des caractères chinois stockés en WE8xxx au lieu de ZHxxx :-) )
Marche avec un driver OCI, mais pas avec le driver THIN que j'utilise, qui ne comprends pas les variables d'environnement NLS.
TestMan
Stephane Dupille a écrit :
TestMan écrit :
<...>
Quel est l'encodage interne de votre base ?
WE8ISO8859P15
ISO8859-15, ISO8859-1, Win1512... c'est vite la prise de tête. Si c'est une nouvelle base, avez-vous essayé de partir directement sur de l'unicode UTF-16 (par défaut sous la v9 sur tous les type N*, par ex NCHAR, NCLOB,...) ? Voir AL16UTF16 dans http://www.oracle.com/technology/tech/globalization/pdf/Unicode.PDF
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC (par exemple, à l'aide de SquirelSQL)? Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question. Désolé :(
Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Collez la liste des propriéts contenues par les métadata (classe spécifique à votre pilote dérivé de http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html ) que l'on obtient sur toute Connection JDBC ...
Afin de vous éviter de taper du code pour l'afficher, je vous indiquais que certains editeurs SQL Java (type SQuirelSQL) affichent directement ces données et permette de les copier facilement (onglet metadata) ...
Aucune idée si Toad peut le faire aussi, à vous de voir ;-)
A+ TM
Stephane Dupille a écrit :
TestMan <none@example.com> écrit :
<...>
Quel est l'encodage interne de votre base ?
WE8ISO8859P15
ISO8859-15, ISO8859-1, Win1512... c'est vite la prise de tête. Si c'est
une nouvelle base, avez-vous essayé de partir directement sur de
l'unicode UTF-16 (par défaut sous la v9 sur tous les type N*, par ex
NCHAR, NCLOB,...) ? Voir AL16UTF16 dans
http://www.oracle.com/technology/tech/globalization/pdf/Unicode.PDF
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC
(par exemple, à l'aide de SquirelSQL)?
Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question.
Désolé :(
Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Collez la liste des propriéts contenues par les métadata (classe
spécifique à votre pilote dérivé de
http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html )
que l'on obtient sur toute Connection JDBC ...
Afin de vous éviter de taper du code pour l'afficher, je vous indiquais
que certains editeurs SQL Java (type SQuirelSQL) affichent directement
ces données et permette de les copier facilement (onglet metadata) ...
Aucune idée si Toad peut le faire aussi, à vous de voir ;-)
ISO8859-15, ISO8859-1, Win1512... c'est vite la prise de tête. Si c'est une nouvelle base, avez-vous essayé de partir directement sur de l'unicode UTF-16 (par défaut sous la v9 sur tous les type N*, par ex NCHAR, NCLOB,...) ? Voir AL16UTF16 dans http://www.oracle.com/technology/tech/globalization/pdf/Unicode.PDF
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC (par exemple, à l'aide de SquirelSQL)? Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question. Désolé :(
Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Collez la liste des propriéts contenues par les métadata (classe spécifique à votre pilote dérivé de http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html ) que l'on obtient sur toute Connection JDBC ...
Afin de vous éviter de taper du code pour l'afficher, je vous indiquais que certains editeurs SQL Java (type SQuirelSQL) affichent directement ces données et permette de les copier facilement (onglet metadata) ...
Aucune idée si Toad peut le faire aussi, à vous de voir ;-)
A+ TM
Stephane Dupille
TestMan écrit :
Quel est l'encodage interne de votre base ?
WE8ISO8859P15
ISO8859-15, ISO8859-1, Win1512... c'est vite la prise de tête. Si c'est une nouvelle base, avez-vous essayé de partir directement sur de l'unicode UTF-16 (par défaut sous la v9 sur tous les type N*, par ex NCHAR, NCLOB,...) ? Voir AL16UTF16 dans http://www.oracle.com/technology/tech/globalization/pdf/Unicode.PDF
C'est ça aussi le soucis : ce n'est pas une nouvelle base. Je peux tenter une conversion du charset, mais bon...
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC (par exemple, à l'aide de SquirelSQL)? Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question. Désolé :( Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Collez la liste des propriéts contenues par les métadata (classe spécifique à votre pilote dérivé de http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html ) que l'on obtient sur toute Connection JDBC ...
Désolé, je n'ai rien compris. :( Autant vous prévenir tout de suite, je suis une grosse truffe. ;-)
Afin de vous éviter de taper du code pour l'afficher, je vous indiquais que certains editeurs SQL Java (type SQuirelSQL) affichent directement ces données et permette de les copier facilement (onglet metadata) ...
On va faire autrement : où trouve-t-on cette info dans squirrel ? J'ai beau retourner l'interface dans tous les sens, je ne trouve pas d'onglet métadata.
J'ai bien un onglet « propriétés du driver », qui contient une seule ligne « RemarksReporting » avec une case à cocher décochée (donc à false). C'est ça ?
Aucune idée si Toad peut le faire aussi, à vous de voir ;-)
On va rester sur Squirrel, j'ai les deux.
TestMan <none@example.com> écrit :
Quel est l'encodage interne de votre base ?
WE8ISO8859P15
ISO8859-15, ISO8859-1, Win1512... c'est vite la prise de tête. Si
c'est une nouvelle base, avez-vous essayé de partir directement sur de
l'unicode UTF-16 (par défaut sous la v9 sur tous les type N*, par ex
NCHAR, NCLOB,...) ? Voir AL16UTF16 dans
http://www.oracle.com/technology/tech/globalization/pdf/Unicode.PDF
C'est ça aussi le soucis : ce n'est pas une nouvelle base. Je peux
tenter une conversion du charset, mais bon...
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC
(par exemple, à l'aide de SquirelSQL)?
Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question.
Désolé :(
Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Collez la liste des propriéts contenues par les métadata (classe
spécifique à votre pilote dérivé de
http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html )
que l'on obtient sur toute Connection JDBC ...
Désolé, je n'ai rien compris. :( Autant vous prévenir tout de suite,
je suis une grosse truffe. ;-)
Afin de vous éviter de taper du code pour l'afficher, je vous
indiquais que certains editeurs SQL Java (type SQuirelSQL) affichent
directement ces données et permette de les copier facilement (onglet
metadata) ...
On va faire autrement : où trouve-t-on cette info dans squirrel ?
J'ai beau retourner l'interface dans tous les sens, je ne trouve pas
d'onglet métadata.
J'ai bien un onglet « propriétés du driver », qui contient une seule
ligne « RemarksReporting » avec une case à cocher décochée (donc à
false). C'est ça ?
Aucune idée si Toad peut le faire aussi, à vous de voir ;-)
ISO8859-15, ISO8859-1, Win1512... c'est vite la prise de tête. Si c'est une nouvelle base, avez-vous essayé de partir directement sur de l'unicode UTF-16 (par défaut sous la v9 sur tous les type N*, par ex NCHAR, NCLOB,...) ? Voir AL16UTF16 dans http://www.oracle.com/technology/tech/globalization/pdf/Unicode.PDF
C'est ça aussi le soucis : ce n'est pas une nouvelle base. Je peux tenter une conversion du charset, mais bon...
Pouvez-vous nous coller les méta-propriétés de votre connexion JDBC (par exemple, à l'aide de SquirelSQL)? Histoire d'y voir plus clair ...
Là, par contre, je ne comprends pas la question. Désolé :( Où dois-je récupérer ça dans Toad ou dans SquirrelSQL ?
Collez la liste des propriéts contenues par les métadata (classe spécifique à votre pilote dérivé de http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html ) que l'on obtient sur toute Connection JDBC ...
Désolé, je n'ai rien compris. :( Autant vous prévenir tout de suite, je suis une grosse truffe. ;-)
Afin de vous éviter de taper du code pour l'afficher, je vous indiquais que certains editeurs SQL Java (type SQuirelSQL) affichent directement ces données et permette de les copier facilement (onglet metadata) ...
On va faire autrement : où trouve-t-on cette info dans squirrel ? J'ai beau retourner l'interface dans tous les sens, je ne trouve pas d'onglet métadata.
J'ai bien un onglet « propriétés du driver », qui contient une seule ligne « RemarksReporting » avec une case à cocher décochée (donc à false). C'est ça ?
Aucune idée si Toad peut le faire aussi, à vous de voir ;-)
On va rester sur Squirrel, j'ai les deux.
Stephane Dupille
TestMan écrit :
Bonjour,
Hello !
En gros, si tu as un problème pour A1 ET B1 tu as vraisemblablement un soucis de config avec ta base. Si A1 & B1 sont OK, alors le problème vient de l'affichage et les test 2,3 et 4 te permetront de trouver d'où celà vient précisement et le paramètrage à modifier (variable d'environement, config du charset du serveur d'appli, ...)
Merci beaucoup pour le coup de main. En fait, la base envoie du latin-9, tomcat déclare envoyer de l'UTF8, et dans les formulaires de saisie, et les JSP ont été codées en CP windows ! Bref, un joyeux bordel.
Alors on va remettre un peu tout ça à plat. On a convertit les sources en UTF8 et convertit la base en UTF8. J'ai une base de tests en UTF8, et tout de suite, ça marche bien mieux ! Tout est parfait.
Reste juste le problème de la conversion de la base. Visiblement, on est obligé de faire un export puis un import. Evidemment, comme ça prend plus de place en UTF8, le contenu de certains varchar a été dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a pas un moyen de faire compter le varchar en caractères et non en octets ?
Merci beaucoup !
(je remet un xpost vers sgbd)
TestMan <none@example.com> écrit :
Bonjour,
Hello !
En gros, si tu as un problème pour A1 ET B1 tu as vraisemblablement un
soucis de config avec ta base.
Si A1 & B1 sont OK, alors le problème vient de l'affichage et les test
2,3 et 4 te permetront de trouver d'où celà vient précisement et le
paramètrage à modifier (variable d'environement, config du charset du
serveur d'appli, ...)
Merci beaucoup pour le coup de main. En fait, la base envoie du
latin-9, tomcat déclare envoyer de l'UTF8, et dans les formulaires de
saisie, et les JSP ont été codées en CP windows ! Bref, un joyeux
bordel.
Alors on va remettre un peu tout ça à plat. On a convertit les
sources en UTF8 et convertit la base en UTF8. J'ai une base de tests
en UTF8, et tout de suite, ça marche bien mieux ! Tout est parfait.
Reste juste le problème de la conversion de la base. Visiblement, on
est obligé de faire un export puis un import. Evidemment, comme ça
prend plus de place en UTF8, le contenu de certains varchar a été
dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a
pas un moyen de faire compter le varchar en caractères et non en
octets ?
En gros, si tu as un problème pour A1 ET B1 tu as vraisemblablement un soucis de config avec ta base. Si A1 & B1 sont OK, alors le problème vient de l'affichage et les test 2,3 et 4 te permetront de trouver d'où celà vient précisement et le paramètrage à modifier (variable d'environement, config du charset du serveur d'appli, ...)
Merci beaucoup pour le coup de main. En fait, la base envoie du latin-9, tomcat déclare envoyer de l'UTF8, et dans les formulaires de saisie, et les JSP ont été codées en CP windows ! Bref, un joyeux bordel.
Alors on va remettre un peu tout ça à plat. On a convertit les sources en UTF8 et convertit la base en UTF8. J'ai une base de tests en UTF8, et tout de suite, ça marche bien mieux ! Tout est parfait.
Reste juste le problème de la conversion de la base. Visiblement, on est obligé de faire un export puis un import. Evidemment, comme ça prend plus de place en UTF8, le contenu de certains varchar a été dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a pas un moyen de faire compter le varchar en caractères et non en octets ?
Merci beaucoup !
(je remet un xpost vers sgbd)
Thierry Thomas
[En-tête "Followup-To:" positionné à fr.comp.applications.sgbd.] Mardi 03 avril 2007 à 16:01 GMT, Stephane Dupille a écrit :
Reste juste le problème de la conversion de la base. Visiblement, on est obligé de faire un export puis un import. Evidemment, comme ça prend plus de place en UTF8, le contenu de certains varchar a été dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a pas un moyen de faire compter le varchar en caractères et non en octets ?
Si, la syntaxe (depuis Oracle 8 ou 9 ?) est :
VARCHAR2(n [BYTE | CHAR] ) -- Th. Thomas.
[En-tête "Followup-To:" positionné à fr.comp.applications.sgbd.]
Mardi 03 avril 2007 à 16:01 GMT, Stephane Dupille a écrit :
Reste juste le problème de la conversion de la base. Visiblement, on
est obligé de faire un export puis un import. Evidemment, comme ça
prend plus de place en UTF8, le contenu de certains varchar a été
dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a
pas un moyen de faire compter le varchar en caractères et non en
octets ?
[En-tête "Followup-To:" positionné à fr.comp.applications.sgbd.] Mardi 03 avril 2007 à 16:01 GMT, Stephane Dupille a écrit :
Reste juste le problème de la conversion de la base. Visiblement, on est obligé de faire un export puis un import. Evidemment, comme ça prend plus de place en UTF8, le contenu de certains varchar a été dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a pas un moyen de faire compter le varchar en caractères et non en octets ?
Si, la syntaxe (depuis Oracle 8 ou 9 ?) est :
VARCHAR2(n [BYTE | CHAR] ) -- Th. Thomas.
astalavista
"Thierry Thomas" a écrit dans le message de news:
[En-tête "Followup-To:" positionné à fr.comp.applications.sgbd.] Mardi 03 avril 2007 à 16:01 GMT, Stephane Dupille a écrit :
Reste juste le problème de la conversion de la base. Visiblement, on est obligé de faire un export puis un import. Evidemment, comme ça prend plus de place en UTF8, le contenu de certains varchar a été dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a pas un moyen de faire compter le varchar en caractères et non en octets ?
Si, la syntaxe (depuis Oracle 8 ou 9 ?) est :
VARCHAR2(n [BYTE | CHAR] )
Depuis la 9i ...
"Thierry Thomas" <tthomas@mail.dotcom.fr> a écrit dans le message de news:
slrnf159jn.14v6.tthomas@graf.pompo.net...
[En-tête "Followup-To:" positionné à fr.comp.applications.sgbd.]
Mardi 03 avril 2007 à 16:01 GMT, Stephane Dupille a écrit :
Reste juste le problème de la conversion de la base. Visiblement, on
est obligé de faire un export puis un import. Evidemment, comme ça
prend plus de place en UTF8, le contenu de certains varchar a été
dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a
pas un moyen de faire compter le varchar en caractères et non en
octets ?
[En-tête "Followup-To:" positionné à fr.comp.applications.sgbd.] Mardi 03 avril 2007 à 16:01 GMT, Stephane Dupille a écrit :
Reste juste le problème de la conversion de la base. Visiblement, on est obligé de faire un export puis un import. Evidemment, comme ça prend plus de place en UTF8, le contenu de certains varchar a été dépassé. Du coup, on est obligés de revoir le schéma de la base. Y'a pas un moyen de faire compter le varchar en caractères et non en octets ?
