Discussion :

[du.64]

Bonsoir à tout le monde,

Je débute avec Ado. Désirant migrer du BDE vers ADO, je rencontre quelques soucis avec les caractères accentués. J'utilise une trentaine de tables Paradox 7 avec le Table Language "Paradox Ansi Intl", avec de nombreux index secondaires, des liaisons Maitre/Détail et plusieurs centaines de milliers d'enregistrements. J'utilise Delphi Seattle sous Windows 8.1. Sous Delphi, pour la migration, je tente d''apprivoiser dBGo...

Lorsque j'utilise le BDE (TTable et dBGrid), les caractères accentués sont affichés correctement. La même base de données avec AdoTable et un dBGrid me donne d'autres caractères : carrés, u majuscule avec des trémas... malgré plusieurs tentatives avec des tables différentes, sur le PC de mon cabinet de soin et celui du domicile, j'obtiens toujours les mêmes facéties.

J'ai potassé le document de JColibri pour la migration et lu bien des posts à ce sujet. Si j'ai bien compris les divers posts que j'ai pu lire, c'est bien ce langage de table qui convient.. Il y a-t-il un paramétrage particulier à effectuer dans Paradox ? Pour AdoConnection ou pour AdoTable ? Voire ailleurs ? Me serai-je fourvoyé avec un mauvais langage de table car il est aussi évoqué UTF-8, 8859-1, voire Borland Latin-1...

Merci pour vos conseils.

[SergioMaster]

Bonjour,

ADO je n'ai jamais vraiment aimé puisqu'il y a plusieurs couches à rajouter (OLE, ODBC) donc on n'est pas à l'abri d'un problème de ces couches.

A mon avis il s'agit d'un problème de Charset (les fameux UTF-8, 8859-1, Borland Latin-1 etc ...), toujours à mon avis je dirais qu'il faut utiliser Borland Latin 1 pour vous connecter aux tables Paradox

[du.64]

Bonjour SergioMaster,
Merci pour la réponse.
J'ai testé avec Borland FRA Latin-1, même problème... Par dépit, j'ai testé le dBase FRA cp437, le dBase FRA cp850... Ils affichent correctement les caractères. J'ai testé également Paradox "INTL" 850. Il correspond à mes besoins.
En espérant que cela puisse servir...

[SergioMaster]

Bonjour,
Reste que à mon avis vous devriez vous tourner vers un SGBD plus "costaud" que Paradox :
- SQLite
- PostGres
- Interbase (DBGO ?) ou Firebird Embedded
etc...

avec de nombreux index secondaires, des liaisons Maitre/Détail et plusieurs centaines de milliers d'enregistrements.

Avec un SGBD comme cité plus haut vous seriez plus que surpris du résultat !
Allié à Firedac comme composants de base de données (ou à défaut ZEOSDBO) vous auriez un programme BDELike mais nettement plus performant ! et je ne parle même pas des possibilités des SGBD que Paradox ne peut pas fournir

[du.64]

Bpnjour SergioMaster,

Merci pour les conseils. J'ai tenté de migrer de Paradox à Interbase, pour me passer du BDE, mais j'éprouve quelques difficultés avec les types InterBase quand à FireBird, je n'ai jamais réussi à le faire fonctionner.

[SergioMaster]

Bonjour,

J'ai tenté de migrer de Paradox à Interbase, pour me passer du BDE, mais j'éprouve quelques difficultés avec les types InterBase

je ne sais plus où (si j'ai le temps je ferai des recherches), mais il y a des tutoriels pour aider et un outil pour migrer les données de Paradox vers Interbase.

quand à FireBird, je n'ai jamais réussi à le faire fonctionner.

je suis surpris car Firebird n'est ni plus ni moins qu'un clone d'Interbase (version 5.6 qui était open source). C'est vrai que depuis les deux se sont écartés mais la plupart de ce qui est valable pour l'un l'est pour l'autre. La seule chose qui pourrait planter est la coexistence de Firebird et Interbase si ces deux SGBD utilise le même port ou si les composants accèdent tous à gdslib.dll (seule bibliothèque de nom commun pour des raisons de compatibilité la version de l'un écrasant celle de l'autre.

Toutefois, il est vrai que que ce soit Interbase ou Firebird ou tout autre SGBD ces dernières apportent beaucoup plus qu'une "simple" gestion de table tel que Paradox et subséquemment la structure des tables, l'apport de procédures, de triggers etc.. sera à envisager.