Discussion :

[looping]

Bonjour,

je viens de migrer une application écrite sous D2007 vers Delphi XE2.
Et bien sur se pose le problème de l'unicode !!

La partie serveur est une base de donnée est Firebird 2.1 en code ISO 8859-1
La partie client utilise les IBX avec ce paramètre :IbDatabase1.Params.Add ('lc_ctype=ISO8859_1')
Cette appli ne sera jamais traduite en langue étrangère.

La compilation se passe bien , et je n'ai pas trop de surprise , seulement des avertissements:

[DCC Avertissement] Unit74.pas(72): W1058 Transtypage de chaîne implicite avec perte de données potentielle de 'string' en 'AnsiString'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
form3.IBQuery1COAUTRE.Value:=IBquery1.FieldByName('CTAUTRE').AsString;

je précise que les champs COAUTRE ou CTAUTRE sont des Blob text

j'ai l'impression que le mappage des champ persistents et différent du mappage des champ dynamique ?


cordialement

[ShaiLeTroll]

Value est c'est un Variant, normalement cela gère l'UnicodeString, curieux d'avoir ce message sur cette ligne !
utilise explicitement AsString de chaque côté

Form3, IBQuery1, ... tu t'y retrouves avec des nommages pareils ?

[looping]

Bonjour,

pour information:

quand je passe la souris sur <form3.IBQuery1COAUTRE.Value> j'ai ceci en popup: DB.TMemoField
lorsque que c'est sur: <IBquery1.FieldByName('CTAUTRE').AsString> le popup indique system.string

Je n'ai pas l'erreur si les 2 champs sont de type string de chaque coté du signe :=


A+

[SergioMaster]

Bonjour,
Utilises AsWideString

[looping]

En passant la souris sur le mot Value de <form3.IBQuery1COAUTRE.Value> il m'indique system.ansistring ? D'ou l'erreur de conversion .

résume
sur un champ persistent:
si IBQuery1CHAMP.Value represente une chaine est elle en system.string
si IBQuery1CHAMP.Value represente un Tmemofield est elle en system.Ansistring

A+

[looping]

J'ai écrit comme on me l'a suggéré:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
form3.IBQuery1COAUTRE.AsString:=IBquery1.FieldByName('CTAUTRE').AsString;

et là plus d'erreur

autre petite question: est ce que je dois changer ISO-8859-1 vers UTF8 coté base de donnée et coté client ou bien si l'appli reste "française" ce n'est pas nécessaire ?


+a

[SergioMaster]

autre petite question: est ce que je dois changer ISO-8859-1 vers UTF8 coté base de donnée et coté client ou bien si l'appli reste "française" ce n'est pas nécessaire ?

non si l'application reste "Europe occidentale" pas besoin de passer en UTF8
les limitations de cette norme pour le français sont les lettres  Œ, œ, Ÿ  pas trop gênant et le € (celui là par contre ...)
tu peux dans ce cas passer à l'ISO 8859-15 (je n'ai pas référence de ce dernier avec Firebird) ou WIN1252

plus d'infos et liens

[looping]

bonjour,

chose bizarre, le symbole EURO fonctionnait jusqu'a maintenant ?
Alors que je suis en Iso 8859-1 coté client et serveur.

Comme je travaille sous Windows, est ce qu'il y a un transtypage implicite du WIN1252 ?

merci

[ShaiLeTroll]

Dans le vrai Latin1 ( Iso 8859-1), le symbole Euro € n'existe pas
Cela fait parti des extensions du Windows 1252 comme aussi le �Œ� œ bien utile dans cœur, œdème,
... en fait surtout utile lorsque l'on a bossé pendant 10 ans sur des applications médicales

Pour le symbole €, je le stocke assez rarement dans la DB, si ce n'est jamais,
soit c'est tout en euro, on affiche € dans les TLabel ou dans les DisplayFormat
soit il y a une gestion de devise via un code comme EUR, USD, ... c'est les abréviations des devises ISO_4217

Pense qu'un exe généré par 2007 est une application ANSI
alors qu'un exe généré par XE2 est une application Unicode

Cela a des impacts car les applications ANSI utilise un CharSet spécifique (le Windows-1252)
La couche DB si elle transmet du Latin1, il est converti en UTF16 par le type string (UnicodeString) et plus en Windows-1252 et donc tu peux avoir des pertes remplacés par des "?"


En C++Builder2007, lorsque l'on est passé en XE2, on a vu ce genre de problème !
En fait nos bases SQL Anywhere, il y avait de grosses confusion entre Latin1 et cp863
J'utilisais les ouils de Central SQL Anywhere et j'avais les accents en cp863
Mon responsable et mon collègue utilisait plutôt SQL Explorer du BDE et voyait du Latin1
Du grand n'importe quoi que DBExpress 2007 supportait par magie

DBExpress XE2 lui voyait la réalité et ne supportait plus les bidouilles !
On a carrément fait une routine de recodage des chaines pour corriger les accents lors du passage la version 2007 à la version XE2 du progiciel

[looping]

Bonjour,


Ok, merci pour vos explications, je commence à comprendre maintenant.
j'ai essayé de passer ma base en WIN1252 et j'ai retrouvé mon Euro.
Ca devrait suffire pour mon appli qui est interne à ma société.

Mais j'ai quand même essayé de la migrer en UTF8 mais problème ca ne marche pas:
des chaines comme "BJÖRKHEMSGATAN " ne sont pas acceptée ? erreur: malformated string
C'est bizarre, l'unicode est censé tout accepter.

Mais comme c'est un problème qui concerne Firebird je vais continuer sur le forum Firebird si je ne ne trouve pas de solution.

Cordialement