limite d'affichage à 255 caractères.

Bonjour,

Je suis chargé de reprendre un programme réalisé sous Delphi 6 + BD paradox.
Je dois migrer tout sous PGsql.
Tout se passe bien, en passant sous ADO.
Tout sauf l'affichage !
Quand je visualise mes tables sous un DBGrid, je ne vois s'afficher QUE 255 caractères ( retours chariots compris )
J'ai pas mal fouillé sur le forum et google mais je ne trouve pas la réponse à mon problème.
En fait, c'est uniquement un pb d'affichage.

Du temps ou le prog utilisait Paradox, passé 254 caractères, "Mémo" s'affichait dans la cellule du DBgrid.
Maintenant, la chaine de caractère est tronqué à 254.

J’espère avoir été assez clair.

Merci à tous

Bonjour,

quelle est la taille du champ dans la base ?

quelle est la taille du champ déclaré dans le TStringField dans Delphi ?

Merci Paul,

Le type du champs de ma base PGSQL est Character Varying.
Initialement, dans Paradox, c'était du Mémo.

J'ai essayé d'imposer une taille avec TStringField mais elle n'est pas prise en compte :(

Bonjour,
AMHA c'est ADO qui ne charge pas le bon type. On parle toujours d'une version D6 ?

Oui, c'est sous Delphi 6 !
Comment peut on résoudre ce pépin :)
Merci beaucoup de ton aide SergioMaster !

Sujet similaire : https://www.developpez.net/forums/d8...55-caracteres/

Re,

Désolé mais non je ne vois pas vraiment !
Déjà je n'ai pas D6, même si je l'ai installé je ne l'ai jamais vraiment utilisé j'en reste à D3, D7, D2010, XE4 et les dernières versions Tokyo et Rio (10.2, 10.3)
C'est surtout ADO qui me fait tiquer, je n'ai jamais adhéré à ce pack de composants qui nécessite des drivers spécifiques. Une suggestion cependant tenter d'obtenir une version à jour https://www.devart.com/dbx/postgresql/

Bien sûr je voterai plutôt pour changer de set de composants ;) genre une vieille version de ZEOSLIB (6.5 ?) ou, mieux, utiliser une version plus récente de Delphi

RE:

Malheureusement, je n'ai guere le choix !
Je dois utiliser uniquement Delphi 6 et passer par une couche ADO.
Tout fonctionne à peu près bien mais il me reste quelques réglages à faire...notamment cette fameuse limite de caractères...

Tu as raison, il doit y avoir un petit paramètre à étendre dans l'ADOQUERY...je fouille

EDIT : Je viens de tenter

Code:

---

ADOQuery.Fieldlist.Field[X].DisplayWidth

---

mais cela ne change rien.

Citation:

---

Envoyé par mikelemerle

Je dois utiliser uniquement Delphi 6 et passer par une couche ADO.

---

Le choix d'un grand stratège !
Quand l'on refait une application Paradox vers un SGBDR, les pratiques changent, fini les listings infinis, tout en SQL au lieu de Filter et autre ...

Le support des hautes résolutions, le support de Windows Récent ?
Non, ton responsable ne voit pas le problème d'utiliser une version vieille de 20ans conçue pour Win2K avec une couche ADO même plus en phase avec OLE DB / ODBC qui est installé sur les postes en Win10 ?



1- Champ persistant ou Non ?
2- Tu as bien vérifié que ce n'est pas le DataPump Paradox->PostgreSQL qui a oublié la fin des blobs ?
3- As-tu essayé un autre provider pour montrer que ADO de D6 est peut-être pas adapté à PostgreSQL et montrer au grand stratège qu'il a tord ?

Bonjour,

Tu es totalement dans le vrai !

Mais plusieurs problèmes viennent se greffer à ce projet : Ancienneté du programme ( gros programme réalisé en pratiquement 2 ans et amélioré sans cesse en 20 ans), budget qui est uniquement alloué au changement de BD et non à une refonte complète du programme...
Par contre, en ce qui concerne le provider, c'est moi même qui ai choisi ADO parce que c'est juste le premier essayé.
Il faut savoir que paradox était utilisé plus comme table de stockage que base de données à part entière. Pratiquement aucune requêtes ne sont exécutées.

Donc, la couche ADO me semble suffisante, même largement suffisante pour ce que mon client veut en faire :)

Je continue à regarder...et vous tiens au courant.

Merci pour votre aide.

Citation:

---

Envoyé par mikelemerle

Par contre, en ce qui concerne le provider, c'est moi même qui ai choisi ADO parce que c'est juste le premier essayé.

---

Si c'est la cas pourquoi ne pas essayer ZEOSDBO (qui rentrera dans le budget puisque open source)

Citation:

---

Il faut savoir que paradox était utilisé plus comme table de stockage que base de données à part entière

---

SQLite n'aurait pas été plus simple

Citation:

---

Pratiquement aucune requêtes ne sont exécutées.

---

Ah le bon vieux temps des tables Paradox

Citation:

---

Donc, la couche ADO me semble suffisante, même largement suffisante pour ce que mon client veut en faire :)

---

les couches j'évite, mais bon c'est toujours mon a priori

Citation:

---

Ancienneté du programme ( gros programme réalisé en pratiquement 2 ans et amélioré sans cesse en 20 ans), budget qui est uniquement alloué au changement de BD et non à une refonte complète du programme...

---

c'est le cas de mon appli (D3) mais j'ai pris le taureau par les cornes et le transfert vers la dernière version et en FMX (pour intégrer les Mac et tablettes) est en cours. Gros avantage la base de données (du moins le SGBD) reste le même (Firebird) même si la structure des tables change un peu. J'ai 4 ans pour finaliser tout en continuant la maintenance (cela va de soit)

Citation:

---

montrer au grand stratège qu'il a tord ?

---

@ShaiLeTroll ton tord est tordu alors qu'avoir tort tue :ptdr:

Re:

Je viens de regarder le size ( en champs persistant), d'un de mes champs que je connais long.
Par défault, la valeur de l'ADODataSet.ChampsX.size = 255.
J'ai cru à une piste mais non...en changeant, rien n'y fait.

Essaye un ADOQuery tout neuf sans champ persistant avec un brutal SELECT * pour voir ce que cela donne



HS
Merci pour le moyen mémo-technique du Tort tue !

La même chose.
J'ai fait le tour de l'ADOQuery...

J'ai essayé aussi avec d'autres programmes.
Il y a toujours une troncature à 255 caractères concernant les champs de type CharacterVarying.

Bonjour,

As-tu tenté de changer le driver ? La version de PostGres est-elle compatible avec ton driver ?

J'ai honte...je viens de trouver !
Je me suis focalisé sur la couche ADO sans aller voir les options ODBC de Win 10.
Dans les options avancées, la valeur de Max Varchar était à 255 !

Tout s'arrange avec une valeur plus grande :)

Un grand merci à vous tous !!

En y regardant de plus près, le problème c'est que un mémo Paradox aurait plutôt du être transféré vers un bytea ou Text et non un varchar.

Ce n'est pas un problème mais après avoir essayé la conversion Mémo ==> Bytea affiche Binarydata sans pouvoir visualiser les datas.
Par contre, Text fonctionne très bien...

Merci du conseil !