Discussion :

[Papy214]

Bonjour

Il y a quelque chose qui gène dans mon projet actuel.

Éléments :

• Une base Interbase 2017
• Une table dans la base et dans cette table un champ de type FLOAT
• Un TSQLConnection
• Un TSQLQuery pour y faire des requêtes.

Les champs existent dans le composant TSQLQuery et l'un d'eux est de type TFloatField, ce qui correspondre en tous points au champ FLOAT de la table cible.
Pourtant, à l'ouverture de la requête, Delphi jure comme un malpropre en disant que le champ est de type float et qu'il attend un single.
Pour régler la chose, j'ai modifié le type du champ dans le DFM pour le en TSingleField et maintenant tout se passe bien.

La question est : Pourquoi un TFloatField n'arrive pas à gérer un champ FLOAT Interbase ?

Avec Firedac, je pourrais jouer avec les "mapping", mais avec le TQSQLConnection, pas possible.
Ou alors, j'ai raté une configuration cachée.

[hocine]

bonjour,
d'après ma petite expérience, ce problème se met en évidence, soit:
1- à votre première utilisation du ado votre champs était de type entier et par la suite vous l'avez changé en réel.
pour ce cas là: il faut supprimer le champs du TADO compiler l'application et par la suite l'ajouter de nouveau et recompiler
2- vous avez effectuer une opération dans la requête pour obtenir le champs.
là il faut revérifier votre requête.
Bonne chance.

[SergioMaster]

Bonjour,
@Hocine il ne s'agit pas de ADO mais de DBExpress

@Papy214 "mais qu'allait-il donc faire dans cette galère ?" dixit Molière
Plus sérieusement pourquoi utiliser DBExpress, du datasnap qui se cache derrière tout ça ?
Hocine à raison sur un point tu as déclaré les champs quelque part ou fait un prepare avant d'ouvrir la requête ? À moins que ce soit une requête au runtime ?
Quid de forcer le type dans ta Requête via un CAST :

Code :

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

SELECT CAST(mavaleur as NUMERIC(10,2)) mavaleur from table

reste qu'il faut trouver les bons "poids" (longeur et précision) pour DBExpress et voir si le type DECIMAL/NUMERIC n'a pas son mot à dire

[Papy214]

Tout d'abord, merci à vous deux de vos remontées sur le sujet !

Qu'est-ce que je vais faire dans cette galère ?
Shaï m'a déjà fait la remarque ! C'est un projet existant qu'un client nous a confié pour une migration depuis un ancien Delphi.
Je me serais volontiers passé de DBExpress et de DCOM qui m'ont posé pas mal de problème.

Le type du champ dans Delphi existant avant la migration et celui dans la base aussi.
La seule différence se situe dans la version Delphi qui a évolué de D6 à 10.2 et la version de la base de données qui est passée de IB6 à IB2017.
La version précédente toujours en cours d'utilisation en attendant la fin de la migration fonctionne bien.
J'imagine donc qu'il y a eu une évolution quelque part.