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

[ShaiLeTroll]

Sans même modifier l'original, dans un autre répertoire, faire une copie modifiée de Data.SQLExpr, en l'incluant au projet, elle remplace celle de Delphi
Je l'ai pratiqué en D7 pour les couches SOAP

[mauriciopt]

Sans même modifier l'original, dans un autre répertoire, faire une copie modifiée de Data.SQLExpr, en l'incluant au projet, elle remplace celle de Delphi
Je l'ai pratiqué en D7 pour les couches SOAP

En fait non, car en design time les champs sont déjà déclaré.
J' avais l'habitude de modifier le source original si besoin mais comme je le disais, j' ai acheté le driver de devArt.Com ...
De plus, je n' ai pas trouvé quoi modifier sachant que c' est une particularité MySQL.

Mauricio

[ShaiLeTroll]

En fait non, car en design time les champs sont déjà déclaré.

Ah mince, c'est vrai que je n'utilise quasiment jamais le champs persistent d'un Query.

[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

[BeanzMaster]

Bonjour Mauricio

ce matin en faisant quelques recherche sur Firebird je suis tombé par hasard sur cette astuce dans le wiki de Lazarus

Boolean data types
Firebird versions below 3.0 do not support boolean data types.

Use a DOMAIN that uses a SMALLINT type (other integer types may work as well - please test and adjust text):
CREATE DOMAIN "BOOLEAN"
AS SMALLINT
CHECK (VALUE IS NULL OR VALUE IN (-1,0,1))
/* -1 used for compatibility with FPC SQLDB; 1 is used by many other data access layers */
;

Let your field/column use this domain type e.g.
CREATE TABLE MYTABLE
(
...
MYBOOLEANCOLUMN "BOOLEAN",
);
Now you can use .AsBoolean for assigning field values etc

Bonne journée

[mauriciopt]

Bonjour Mauricio

ce matin en faisant quelques recherche sur Firebird je suis tombé par hasard sur cette astuce dans le wiki de Lazarus



Bonne journée

Bonjour,

je ne sais pas si cela pourrait marcher avec MySQL mais de toute façon, je dois rester compatible avec des dixaines de clients avec les versions compilées sous Delphi 2009.
La meilleure solution a été d' acheter le driver DBExpress de DevArt, franchement ça vaut le coup.
Je n' ai eu que 2 soucis :
SELECT MIN(ChampNormalementBooleen) renvoi un champ de type entier

De même, l' utilisation de UNION fait annuler le type booléen sur un champ:
SELECT ChampNormalementBooleen FROM TABLE1
Renvoie bien un champ TBooleanField, par contre:
SELECT ChampNormalementBooleen FROM TABLE1
UNION
SELECT ChampNormalementBooleen FROM TABLE2
renvoi un champ de type entier.


Mauricio