Discussion :

[mauriciopt]

Bonjour,

je viens d'acquérir delphi 10.2.3 et je suis en train de convertir mes applications de Delphi 2009 vers cette nouvelle version.
J' utilise les composants DB Express pour accéder aux base de données MySQL.

Je rencontre un problème important, les champs mySQL de type tinyint(1) mappé en TBoolenfield sous Delphi 2009 sont maintenant mappé comme TShortIntField, ce qui pose beaucoup de problèmes.

J' ai trouvé une solution avec les pilotes DevArt pour DBExpress / MySQL mais cela ne me satisfait pas dans le sens où ces derniers sont payants et peuvent apporter des problèmes que je n' avais pas.

J' aimerai donc savoir commet puis je mapper les champs de type TinyInt en TBooleanField.

Merci pour votre aide.

Mauricio

[pprem]

Bonjour Mauricio

As-tu tenté de forcer le type des champs en les décrivant dans tes TSQLTable ou TSQLQuery ?
Sinon, au pire, tu peux toujours tenter un champ calculé, mais c'est pas génial.

En passant à FireDAC au lieu de rester sur dbExpress tu peux aussi forcer le nappage de champs directement au niveau des options de ta connexion.

[mauriciopt]

Bonjour Mauricio

As-tu tenté de forcer le type des champs en les décrivant dans tes TSQLTable ou TSQLQuery ?
Sinon, au pire, tu peux toujours tenter un champ calculé, mais c'est pas génial.

En passant à FireDAC au lieu de rester sur dbExpress tu peux aussi forcer le nappage de champs directement au niveau des options de ta connexion.

Salut,

merci pour ta réponse.
Malheureusement, je ne peux pas forcer car le mapping est fait en interne lors de l'ouverture et si le type de champ n' est pas le même, ça buggue ...
Pour les champs calculés, c' est pas top.

Je suis parti pour l' instant sur le driver DB Express MySQL de DevArt.com qui a l' avantage d'avoir l' option de mapping des champs de type TinyInt(1) mais aussi d' être compatible mySQL 8.

Je suis quand même preneur s' il existe une solution simple.

a+

[ShaiLeTroll]

Dommage que l'écart de version soit si important, cela mériterait de faire un Cas sur QualityCentral si cela avait sur deux versions proches, maintenant c'est trop tard
C'est pénible de changer de version de Delphi et de voir qu'un comportement a changé
Par contre, tu dois pas être le seul à avoir eu ce problème

J'ai travaillé avec MySQL et MyDAC, idem, le TinyInt(1) en Booleen c'est fort pratique, cela me manque en ORACLE ou le code est plus lourd.
D'ailleurs MyDAC est nettement plus confortable que DB Express que j'ai aussi expérimenté mais sur Sybase

[mauriciopt]

Dommage que l'écart de version soit si important, cela mériterait de faire un Cas sur QualityCentral si cela avait sur deux versions proches, maintenant c'est trop tard
C'est pénible de changer de version de Delphi et de voir qu'un comportement a changé
Par contre, tu dois pas être le seul à avoir eu ce problème

J'ai travaillé avec MySQL et MyDAC, idem, le TinyInt(1) en Booleen c'est fort pratique, cela me manque en ORACLE ou le code est plus lourd.
D'ailleurs MyDAC est nettement plus confortable que DB Express que j'ai aussi expérimenté mais sur Sybase

Salut,

je vais basculer progressivement vers FireDAC.
J' ai téléchargé le driver DBExpress pour mySQL de DevArt.Com et il suffit d'ajouter dans la propriété params la valeur suivante:
EnableBoolean=True

Se serait bien qu' il y ait une option dans ce sens mais je n' ai pas trouvé.

Merci en tout cas pour ton commentaire.

Mauricio


J' en profite pour vous donner le lien vers mes compos gratuits:
https://sourceforge.net/projects/tcycomponents/

[SergioMaster]

Bonjour,

pourquoi ne pas modifier les composants DBExpress de votre version ?
Lors de la sortie de Firedac c'est souvent ce que Dimitry Arefiev proposait lorsqu'on lui signalait un problème Firedac, il indiquait l'endroit et le code à remplacer.
Les précautions sont bien sûr de sauvegarder le source initial avant. Puis, ensuite, une réinstallation du composant s'impose. Il fallait bien sûr prendre garde aux mises à jour mais 10.2.3 ne va plus évoluer donc pas de soucis d'écrasement.

AMHA c'est l'unité Data.SQLExpr qui est à modifier, à partir des lignes 74-105 se trouve tout ce qui semble concerner le mapping, comparer cette version avec celle d'une version D2009 devrait donner les clé nécessaires

[pprem]

Dommage que l'écart de version soit si important, cela mériterait de faire un Cas sur QualityCentral si cela avait sur deux versions proches, maintenant c'est trop tard
C'est pénible de changer de version de Delphi et de voir qu'un comportement a changé
Par contre, tu dois pas être le seul à avoir eu ce problème

En fait il n'est jamais trop tard pour signaler les régressions qui posent problème. Embarcadero est quand même dans une optique de pérennité des programmes développés et pourra ainsi proposer une alternative ou corriger la partie qui devrait l'être.

S'ils n'ont pas conscience d'un problème, ils ne risquent pas de corriger le tir.

[ShaiLeTroll]

En fait il n'est jamais trop tard pour signaler les régressions qui posent problème... S'ils n'ont pas conscience d'un problème, ils ne risquent pas de corriger le tir.

Eh bien c'est effectivement une bonne chose qu'Embarcadero assure encore la non-regression des versions de l'époque de CodeGear pour ajouter des corrections dans les nouvelle versions