Paramètre numériques mal reconnus avec DBExpress et Oracle

**Nono40** · 21/10/2011, 16h37

Bonjour,

Nous avons des soucis avec les paramètres de requète de valeur flotante.

Le contexte :
Oracle 9i, client 9i, Appli sous delphi 2010 (edit : même problème avec XE2) avec DBExpress

La table est simplement :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE ESSAISAND
(
  CHAMP1  VARCHAR2(5 BYTE),
  CHAMP2  FLOAT(126),
  CHAMP3  NUMBER(19,10),
  CHAMP4  NUMBER
)

La requète :

Code SQL :

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

1
2
3
4
insert into ESSAISAND
 (CHAMP1,CHAMP2,CHAMP3,CHAMP4) 
VALUES 
(:CHAMP1,:CHAMP2,:CHAMP3,:CHAMP4)

A l'exécution, en utilisant ParamByName :

Code :

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

  sqlqUERY1.ParamByName('CHAMP4'   ).AsFloat := 3.33;

On obtient l'erreur :

---------------------------
Testconnexiondbexpress
---------------------------
ORA-00932: types de données incohérents : %s attendu ; %s obtenu.
---------------------------
OK
---------------------------

L'erreur est la même avec CHAMP2 et CHAMP3.

En fouillant sur le net on trouve des solutions qui fonctionent partiellement :

AsBCD

Code :

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

  sqlqUERY1.ParamByName('CHAMP3'   ).AsBcd := 2.22;

Fonctionne si la valeur est faible.
Ceci ne fonctionne pas :

Code :

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

1
2
  D :=  1230000000000000000000000000.456;
  sqlqUERY1.ParamByName('CHAMP3'   ).AsBcd := d;

retourne :

---------------------------
Testconnexiondbexpress
---------------------------
Opération en virgule flottante incorrecte.
---------------------------
OK
---------------------------

AsFmtBCD
Fonction sur les petits nombre mais toujours pas sur les grands :

Code :

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

1
2
  D :=  1230000000000000000000000000.456;
  sqlqUERY1.ParamByName('CHAMP3'   ).AsFMTBCD := Doubletobcd(d);

---------------------------
Testconnexiondbexpress
---------------------------
1,23E27 n'est pas une valeur BCD correcte.
---------------------------
OK
---------------------------

AsFloat fonctione nickel avec FireBird/DBExpress mais aussi avec Oracle/BDE !

Une solution est de se passer des paramètres :

Code SQL :

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

1
2
3
4
insert into ESSAISAND
 (CHAMP1,CHAMP2,CHAMP3,CHAMP4) 
VALUES 
(:CHAMP1,:CHAMP2,:CHAMP3,'1.23E27')

Là, la valeur est stockée correctement (Vérifié dans Toad)... Mais ensuite elle ne s'affiche plus si on affiche la table dans un DbGrid via un ClientDataset.

Quelqu'un a eut une solution ?
Je ne peux pas utiliser de composants spécifiques à Oracle car nos applis sont multibases (suivant les clients) FireBird/Oracle/SQLServer.

On vient de se passer du BDE et suivi la recommandation de passer à DBexpress... Tout est basé sur DbExpress maintenant. Et nos tests ont été fait avec FireBird où il n'y a aucun souci.

**ShaiLeTroll** · 21/10/2011, 16h59

TParam.AsBCD c'est 20 chiffres significatifs, tu en mets 32 (en fait c'est un Currency, un entier géré avec une virgule fixe à 4)

TParam.AsFloat, ça tourne autour de 15-16

TParam.AsFMTBCD couple le avec DoubleToBCD n'aura pas plus d'intéret que AsFloat car tu reste limité à 15-16 chiffres significatifs

Essaye un TBcd

Code :

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

  sqlqUERY1.ParamByName('CHAMP3'   ).AsFMTBCD := StrToBcd('1230000000000000000000000000.456');

Il est rare de travail avec de tel nombre !
Avec '1.23E27' tu perds dont la précision et 456 !
Tu évoques FireBird, BDE, ... cela fonctionne avec une précision de 32 chiffres significatifs ou seulement 15 à 20 ?

**Nono40** · 21/10/2011, 17h19

Bonjour,

Même erreur.

J'ai aussi la même erreur avec :

Code :

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

sqlqUERY1.ParamByName('CHAMP3'   ).AsFMTBCD := StrToBcd('1.23E27');

Alors que 1.23E27 n'a que peu de chiffres significatifs

1.23E27 tient très bien dans un Single (Float sous FireBird)

En passant sans paramètre, 1.23E27 est bien stocké dans la base. Mais ça oblige à tranformer en chaine les paramètre directement dans la requète.

Edit : j'avais laissé le .456 par erreur, 123000000000000000000000000.0 ne fonctionne pas non plus. Single va de 1.0E-38 à 100E38 environ.
Le pb est justement de passer par des paramètres BCD qui eux limites les valeur.

**ShaiLeTroll** · 21/10/2011, 17h35

As-tu besoin d'une grand précision, les 456 ?

Car dans ce cas, utilise que le FLOAT ou NUMBER(19,10) dans Oracle, semble que ce soit le NUMBER implicite, quelles sont ces limites dans ce cas ?

Je travail assez peu sur de grand chiffre, en compta, le Currency suffit, au pire, il y a un compte dédié aux erreurs d'arrondis.
En finance, c'est là qu'il faut pousser, surtout pour les taux de change, qu'il faut calculer sur 6 digits et non 4 comme le Currency, pour le moment, j'ai jamais dépassé NUMBER(7,6) ce qui tient correctement dans unDouble, c'était sur Oracle, je t'avoue que je n'ai jamais vérifié si la conversion Euro-FrancBelge était bonne, j'avais juste finalisé l'outil, procédure et déploiement pour la migration Paradox/BDE -> Oracle/ADO fait par un collègue démissionnaire d'une application de gestion financière d'une ONG.
C'était les plus gros chiffres que j'ai vu !

Moi, je travail plus avec les bits et des entiers qu'avec du flottant !

**Nono40** · 21/10/2011, 17h49

Les 456 non.
La précision d'un Single me suffit dans la plupart des cas.
Dans certains cas je passe en Double (DOUBLE PRECISION sous firebird) car les 8/9 chiffres ne sont pas suffisant.

Mais dans tous les cas AsFloat devrait fonctionner.

J'ai tellement eut de doute que je viens même de refaire un essai sous FireBird

Sous FB :

Code :

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

    ParamByName('TRUC').AsFloat := 1.23E27;

Fonctionne sans problème.
1229999970340245300000000000.000000 en float
1230000000000000000000000000.000000 en double précision.

**ShaiLeTroll** · 21/10/2011, 17h55

Ce qui pose problème, c'est le type Oracle, CHAMP1 2 et 3 fonctionne ?
Modifie CHAMP4 pour qu'il ressemble à un de ces trois champs !
Je ne vois que cela !

**Nono40** · 21/10/2011, 18h03

Non, j'ai mis trois types dans Oracle pour faire des essais avec différents type.

Aucun ne fonctionne. SInon ce serait une solution simple pour moi.

Pour info, même souci avec Oracle 10g

**ShaiLeTroll** · 21/10/2011, 18h29

As-tu lu ce sujet DBExpress et Oracle
AsString, AsFloat, AsCurrency semblait ne pas fonctionner correctement !
Peut-être que le Driver DBExpress pour Oracle converti les chaines en string pour le passage de paramètre et que cela foire selon Français\Anglais ?
J'ai un gros doute, cela serait gravissime !

As-tu essayé un autre Driver DBExpress comme ceux de Devart Core Lab

As-tu essayé AsCurrency d'ailleurs ?

Dans le sujet Embarcadero Discussion Forums » C++Builder » Database » DBExpress - Thread: c++ builder, oracle, dbexpress, tsqlstoredproc, bcd overflow, seul AsString semblait fonctionner correctement pour un Paramètre de Procédure Stockée utilisant un NUMBER ! Ouch !

**Nono40** · 21/10/2011, 19h04

Oui j'avais lu ce sujet.
C'est indispensable de la faire pour supporter . et , comme séparateur, sinon même le TField ne fonctionne pas correctement. C'est déjà appliqué dans mon exemple.

J'avais lu aussi l'autre sujet, d'ailleurs il y a des tonnes de pages sur le passage des paramètres des procédures stockées. Mais pas de solution viable pour toutes les valeur. C'est toujours AsBcd ou AsFMTBcd qui est utilisé.

Note que c'est bien le TParam qui merde, car sans paramètre la requète fonctionne bien.

En lisant ceci : http://download.oracle.com/docs/cd/B...ype.htm#i16209
Je commence à comprendre un peu. Oracle, nativement, utilise du BCD contrairement à toutes les autres bases qui utilisent les formats IEEE Single et Double.
Du coup son format numérique par défaut c'est le BCD. Le driver DbExpress semble se mélangeur les pinceaux pour convertir une valeur Float en valeur BCD.

Je n'ai pas testé d'autre driver DBExpress car je n'en connaissais pas l'existence.
Je vais tester car la lib DbExpress est certainement au coeur du problème, c'est qui qui transmet le TParam.Value (Variant) en un type connu par la base.

Edit : en tout cas merci de t'être penché sur mon problème

**Nono40** · 21/10/2011, 19h57

Bon, suite à ton conseil j'ai essayé le driver DevART.
http://www.devart.com/dbx/oracle/download.html

Cela résout le problème des pramètres de requète :

Code :

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

1
2
  sqlqUERY1.ParamByName('CHAMP3'   ).AsFloat := 2.7e5;
  sqlqUERY1.ParamByName('CHAMP4'   ).AsFloat := 3.33e28;

Ceci fonctione, dans Toad je vois le lignes avec les bonnes valeurs.

Maintenant la suite : il est imposible de lire une valeur 3.33E28 dans la base. Les deux drivers DbExpress retournent 0 :

Code :

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

1
2
  ShowMessage(SQLQuery3.FieldByName('CHAMP4').AsString);
  ShowMessage(FloatToStr(SQLQuery3.FieldByName('CHAMP4').AsFloat));

Pire : sous Delphi 2010, sur un DBGrid lié à un ClientDataSet lié à SQLQuery3, l'affchage des lignes s'arrète sur la première ligne contenant une valeur hors normes !

(gauche appli de test sous D2010, droite Toad)

Sous Delphi XE2, les autres lignes sont biens affichées mais toujours avec les valeur à 0.

(gauche appli de test sous DXE2, droite Toad)

Comme cela ne génère aucune exception je ne suis même pas sûr de la valeur lue dans la base

!

Je n'ai pas Oracle 10g sous la main pour tester avec des champd Oracle de type BINARY_FLOAT et BINARY_DOUBLE qui sont eux en format natif IEEE. Ces champs ne sont pas reconnus sous Oracle 9i

(Et toujours pareil, sous FireBird j'ai bien 1.23E27 dans mon DBGrid)

**Nono40** · 21/10/2011, 22h16

Je viens d'avancer d'un grand pas !
Merci à toi car en me donnant l'idée de changer de Driver c'est en fouillant dans leur forum que j'ai trouvé la solution avec DevArt.

Il faut ajouter :

Code :

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

  SQLConnection.Params.Add('EnableBCD=False');

Pour que les champs lus soient retournés en TFloatField au lieu de TBCDField.
Avec D2010 la grille s'affiche correctement maintenant.

Plus qu'a trouver cette option dans le driver d'Embarcadero, mais au pire il y a una solution (payante) qui fonctionne.

**ShaiLeTroll** · 24/10/2011, 10h57

ENABLED BCD, comme avec le BDE ou la propriété EnableBCD du ADO et TCustomADODataSet !

A y reflechir, le projet Oracle ne contenait que des objets champ persistant et tous définis à TFloatField hérité du BDE, c'est surement pour cela qu'il n'y a pas eu de soucis avec les Flottants lors de la migration du Projet.
Il n'y avait jamais de critère sur les nombres mais uniquement sur des identifiants métiers ou des dates !

Cherche bien, c'est une option classique, impossible qu'elle est était oubliée !

J'ai utilisé MyDAC pour MySQL de Core Lab (nouvellement Devart) pendant plus de 4 ans, et ça faisait au moins 1 ans que la société avait migré sur cette bibliothèque, et continue encore !

Leurs composants sont réputés, leur mise à jour régulières et assez confortable
Leur expérience avec ODAC, UniDAC font qu'ils fournissent les meilleurs drivers DBExpress disponible et nettement plus poussé et testé que ceux fournis par Embarcadero

**Nono40** · 24/10/2011, 21h48

Envoyé par ShaiLeTroll

Cherche bien, c'est une option classique, impossible qu'elle est était oubliée !

Et bien si !
http://qc.embarcadero.com/wc/qcmain.aspx?d=70661
<je garde mes commentaires pour moi

>
Je continue de chercher mais je doute qu'ils aient pensé à cette option.

Envoyé par ShaiLeTroll

Leurs composants sont réputés, leur mise à jour régulières et assez confortable
Leur expérience avec ODAC, UniDAC font qu'ils fournissent les meilleurs drivers DBExpress disponible et nettement plus poussé et testé que ceux fournis par Embarcadero

Merci pour le retour.
Plus qu'a faire passer l'idée à mon chef que Delphi 2010 ne fonctionne pas avec Oracle/DbExpress et d'ajouter une licence Devart.
Déjà on a du passer à une version Entreprise car Embarcadero ne sait pas se connecter à Oracle avec le BDE+SqlLinks avec la version Pro.

Je suis assez sidéré par les soucis de connectivité rencontrés.

**ShaiLeTroll** · 25/10/2011, 10h55

Je troll pour toi alors :
Impensable ! C'est limite scandaleux !

Je découvre DBExpress, et je ne suis vraiment pas fan de cette bibliothèque franchement pénible, en fait comme tous les composants DB, vivement l'avènement d'un full LiveBindings et d'un modèle OR Embarcadero (comme Bold) ainsi que LinQ Entity, quoi qu'en fait, j'aime bien écrire la couche moi-même, c'est fun !

**Nono40** · 25/10/2011, 16h24

Nouvel épisode :

Ma collègue a eut l'idée de tester avec... Delphi 6/DbExpress.
Et bien ça fonctionne

Les valeurs sont lues correctements.
On peut donc qualifier le problème de régression.

En passant j'ai essayé avec D2007, le problème est exactement le même que sous D2010 (0 affiché et table tronquée)

Nous avons aussi tester les champs de type BINARY_FLOAT sous Oracle 10.
Toad ne sait même plus lire les données.
Il est impossible d'ourvir une table dans Delphi/DbExpress avec une colonne de ce type. Que ce soit avec D6 ou D2010 :

Autrement dis, ce type de champ est inutilisable avec Delphi.

Mettre la main dans la camboui ? Non merci, on n'achète pas des outils RAD pour devoir révinventer les couches d'accès aux données.

Paramètre numériques mal reconnus avec DBExpress et Oracle

Bases de données Delphi

Discussions similaires

Partager

Partager