Récupération de Float sous D-XE2 + FB 2.5 Impossible

**lefju cabro** · 16/04/2012, 15h47

Bonjour,

J'utilise Delphi XE2 sous un poste Win7/64bits et j'ai commencé à créer une bdd Firebird 2.5 qui contient des champs de type Float.

Le problème que je rencontre est que je n'arrive pas à récupérer les champs Float d'une table. Lorsque je fais:

Code :

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

select * from maTable ;

tous mes champs exceptés ceux de type Float sont récupérés.

Je suppose que mon problème vient soit des dll firebird soit de mes paramètres de connection: sous D-XE2, j'utilise le composant TSQLConnection. Le code de connexion à ma base est le suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  with SQLConnection do
  begin
    DriverName:= 'Firebird' ;
 
    Params.Clear ;
 
    Params.Add('LibraryName=dbxfb.dll');
    Params.Add('VendorLib=fbclient.dll');
    Params.Add('VendorLibWin64=fbclient.dll');
    Params.Add('Database='+_FileName);
    Params.Add('RoleName=RoleName');
    Params.Add('User_Name='+'sysdba');
    Params.Add('Password='+'dude32');     
    Params.Add('ServerCharSet=ISO8859_3');
    Params.Add('SQLDialect=3');
    Params.Add('ErrorResourceFile=');
    Params.Add('LocaleCode=0000');
    Params.Add('BlobSize=-1');
    Params.Add('CommitRetain=False');
    Params.Add('WaitOnLocks=True');
    Params.Add('Interbase TransIsolation=ReadCommited');
    Params.Add('Trim Char=False');
  end;

J'avais déjà rencontré ce problème sous D-XE et je l'avais résolu en passant par les composants/dll DevArt (TCRSqlConnection) que nous ne souhaitons plus utiliser.

Par ailleurs, petite info intéressante, la même requête passée sous EMS SQL Manager me retourne tous mes champs, float inclus.

Par avance, je vous remercie pour vos retours.

**ShaiLeTroll** · 16/04/2012, 17h37

Cela me rappelle ce sujet Paramètre numériques mal reconnus avec DBExpress et Oracle où les nombres floattants ce n'est pas top avec DBExpress mais fonctionnel avec Devart\CoreLab, c'était de l'Oracle
Et ce sujet Requete + champ de type FLOAT dans la section FireBird du forum, mais c'est de toi, donc tu n'as pas corriger ton problème depuis

En théorie, float est supporté
As-tu une option comme EnableBCD dans Firebird\DBExpress
As-tu pensé à utiliser UIB ? MDO ? Zeos ?

la dLL fbclient est la même en 32 et 64 Bits ???
une dans System32 ou l'autre dans SysWOW64

**Nono40** · 16/04/2012, 23h33

Tu peux nous donner le DDL de la table ?

J'utilise DBX avec Firebird 2.1/2.5 sans aucun soucis de ce genre. Par contre je suis en D2010. Je suis sous Win 7 64 bits.

Quand tu dis que tu n'as pas les champs, tu n'as pas les valeurs ou tu n'as pas les colonnes ?

**lefju cabro** · 17/04/2012, 11h22

Merci pour vos réponses.

As-tu une option comme EnableBCD dans Firebird\DBExpress

Dans les paramètres de connexion de la base, j'ai ajouté le code suivant mais le résultat est identique. Est-ce ce qu'il faut faire ?

Code :

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

Params.Add('EnableBCD=True') ;

As-tu pensé à utiliser UIB ? MDO ? Zeos ?

J'y ai pensé mais on me l'a refusé

. On essaye de limiter les composants tiers, c'est la raison pour laquelle on ne souhaite plus utiliser DevArt.

la dLL fbclient est la même en 32 et 64 Bits ???
une dans System32 ou l'autre dans SysWOW64

Les DLL sont différentes entre 32 et 64 bits. Je n'en ai déployée qu'une qui se trouve dans le répertoire de mon appli. Si on utilise la mauvaise DLL FB, on a un message d'erreur lors de la connexion à la base.

Tu peux nous donner le DDL de la table ?

Le voici:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
CREATE TABLE ETAT_MACHINE (
  ID INTEGER NOT NULL,
  MOTEUR_ID INTEGER NOT NULL,
  CAMPAGNE_ID INTEGER NOT NULL,
  ETAT INTEGER DEFAULT 1,
  OFFSETDATA INTEGER DEFAULT -1,
  FIRSTTIME SMALLINT DEFAULT 0,
  ANALYSE VARCHAR(240) DEFAULT '',
  ACTIONMAINTENANCE VARCHAR(150) DEFAULT '',
  PRECONISATION VARCHAR(150) DEFAULT '',
  DETAILCALCUL VARCHAR(200) DEFAULT '',
  DATECALCUL DATE,
  KZOOMPORTEUSE INTEGER DEFAULT -1,
  KSPANPORTEUSE INTEGER DEFAULT -1,
  FPORTEUSE FLOAT DEFAULT -1,
  APORTEUSE FLOAT DEFAULT -1,
  CHARGE FLOAT DEFAULT -1,
  TMACRETE FLOAT DEFAULT -1,
  TMAEFF FLOAT DEFAULT -1,
  TMAFDS FLOAT DEFAULT -1,
  TMFCRETE FLOAT DEFAULT -1,
  TMFEFF FLOAT DEFAULT -1,
  TMFFDS FLOAT DEFAULT -1,
  FMAX FLOAT DEFAULT -1,
  AMAX FLOAT DEFAULT -1,
  THDG FLOAT DEFAULT -1,
  THDPAIR FLOAT DEFAULT -1,
  THDIMPAIR FLOAT DEFAULT -1);

Quand tu dis que tu n'as pas les champs, tu n'as pas les valeurs ou tu n'as pas les colonnes ?

Ma colonne qui doit contenir les champs de type Float n'existe pas.

J'ai remarqué une chose étonnante: on utilise le TkbmMemTable (version gratuite donc pas de doc...) car le TClientDataSet n'est pas top. Après lancement de ma requête et remplissage du CDS, toutes mes colonnes sont présentes. Mais lors du "transfert" du CDS vers le TkbmMemTable, les colonnes de type Float disparaissent.
Par contre pourquoi ce remplissage fonctionne avec les composants DevArt, je n'en sais rien.

**Rayek** · 17/04/2012, 12h10

Envoyé par lefju cabro

J'ai remarqué une chose étonnante: on utilise le TkbmMemTable (version gratuite donc pas de doc...) car le TClientDataSet n'est pas top. Après lancement de ma requête et remplissage du CDS, toutes mes colonnes sont présentes. Mais lors du "transfert" du CDS vers le TkbmMemTable, les colonnes de type Float disparaissent.
Par contre pourquoi ce remplissage fonctionne avec les composants DevArt, je n'en sais rien.

Si les colonnes sont bien présentes dans le ClientDataset et pas dans le TKbmMemTable, c'est que ce composant doit avoir un problème et pas Delphi.

Si les champs n'apparaissent pas c'est que ce composant ne gère pas le type FLOAT (il faudrait voir le type que retourne le Cliendataset sur ces champs et voir s'il existe dans le TkmbMemTable)

**lefju cabro** · 17/04/2012, 14h31

Je n'arrive pas à savoir si c'est le composant TkbmMemtable ou la connexion qui est incorrecte.

J'ai effectué les tests suivants pour lire le champs FPorteuse de la table moteur (ddl défini ci-dessus):

SQLConnection (DriverName= DevartInterbase) --- colonne FPorteuse récupérée de type ftFloat --- transfert dans TkbmMemtable OK

SQLConnection (DriverName= Firebird) --- colonne FPorteuse récupérée de type ftSingle --- transfert dans TkbmMemtable KO

Le transfert de CDS vers TkbmMemtable se fait grâce à la méthode:

Code :

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

LoadFromDataSet(DMConnection.SQLQuery, [mtcpoStructure, mtcpoProperties]);

La modification des arguments ne résoud pas mon problème.

**Nono40** · 17/04/2012, 14h38

Avec un simple TSQLConnection et un TSQLQuery est-ce que tu as toutes les colonnes ?

Tu ne peux pas mettre de grille mais par code tu peux lire les colonnes.

Si c'est le cas le problème ne vient pas de Delphi.

Concernant EnableBcd, moi je le mettrais plutôt à False pour rester en mode flottant pur. Le mode BCD c'est pour la compatiblité avec Oracle dont le BCD est le format natif. Firebird gère des flottant au format standard lui.

**ShaiLeTroll** · 17/04/2012, 14h40

Envoyé par lefju cabro

Ma colonne qui doit contenir les champs de type Float n'existe pas.

Tu veux dire "tes 20 colonnnes FLOAT" sont ignorés dans FieldDefs ou juste UNE des colonnes ?
EDIT : OK, la colonne FPorteuse

Il semble que ce FLOAT c'est l'équivalent d'un Single, force un type plus large comme "Double Precision"

Envoyé par lefju cabro

Par contre pourquoi ce remplissage fonctionne avec les composants DevArt, je n'en sais rien.

tu as la réponse DevArt force le type ftFloat, le type ftSingle n'est peut-être tout simplement pas implémenté dans le TkbmMemtable !
Encore une fois DevArt fait preuvre d'intelligence, je pense que 90% des développeur utilise AsFloat et non AsSingle, à cause des erreurs d'arrondis trop fréquente chez ce dernier, du coup, pour éviter des conversions inutiles ainsi que du code différent pour chaque type de flottant, tout en Double !
Surtout qu'avec les processeurs (au moins à partir du P4 et peut-être même P3), un calcul sur un Single ou sur un Double est tout aussi rapide (même léger avantage au Double), pourquoi alors utiliser un peu précis sur il n'est pas nettement plus rapide !

Il est drôle de s'interdire DevArt et d'utiliser un objet non documenté, je suppose que c'est juste pour des tests de migration, tu ne comptes pas l'utiliser réellement dans le projet (ou alors vous avez une stratégie des plus étranges !)

la copie d'un SQLQuery vers un TClientDataSet, les deux types (ftFloat et ftSingle) fonctionnent ?

Sinon, le TMemoryDataSet - Développer un DataSet en mémoire pourrait être une alternative au TkbmMemtable !

DevArt fourni le VirtualTable

**Rayek** · 17/04/2012, 15h47

Envoyé par lefju cabro

Je n'arrive pas à savoir si c'est le composant TkbmMemtable ou la connexion qui est incorrecte.

J'ai effectué les tests suivants pour lire le champs FPorteuse de la table moteur (ddl défini ci-dessus):

SQLConnection (DriverName= DevartInterbase) --- colonne FPorteuse récupérée de type ftFloat --- transfert dans TkbmMemtable OK

SQLConnection (DriverName= Firebird) --- colonne FPorteuse récupérée de type ftSingle --- transfert dans TkbmMemtable KO

Le transfert de CDS vers TkbmMemtable se fait grâce à la méthode:

Code :

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

LoadFromDataSet(DMConnection.SQLQuery, [mtcpoStructure, mtcpoProperties]);

La modification des arguments ne résoud pas mon problème.

Ce qu je vois c'est que le TkbmMemtable ne supporte pas les ftSingle alors que le Cliendataset (qui n'est pas top

) lui le supporte.

D'ailleurs en quoi le ClientDataset n'est pas top pour toi (ou tes supérieurs ?)

**lefju cabro** · 17/04/2012, 17h00

Envoyé par Nono40

Avec un simple TSQLConnection et un TSQLQuery est-ce que tu as toutes les colonnes ?
Si c'est le cas le problème ne vient pas de Delphi.
Concernant EnableBcd, moi je le mettrais plutôt à False pour rester en mode flottant pur. Le mode BCD c'est pour la compatiblité avec Oracle dont le BCD est le format natif. Firebird gère des flottant au format standard lui.

TSQLConnection et un TSQLQuery me retourne toutes mes colonnes avec driver FB.

J'ai testé EnableBcd=False mais cela ne résoud pas mon problème

**lefju cabro** · 17/04/2012, 17h08

Envoyé par ShaiLeTroll

Encore une fois DevArt fait preuvre d'intelligence, je pense que 90% des développeur utilise AsFloat et non AsSingle, à cause des erreurs d'arrondis trop fréquente chez ce dernier, du coup, pour éviter des conversions inutiles ainsi que du code différent pour chaque type de flottant, tout en Double !
Surtout qu'avec les processeurs (au moins à partir du P4 et peut-être même P3), un calcul sur un Single ou sur un Double est tout aussi rapide (même léger avantage au Double), pourquoi alors utiliser un peu précis sur il n'est pas nettement plus rapide !

Je comprends pourquoi ça ne marche pas mais je ne suis pas sûr de comprendre ta solution.

Tu me proposes de passer en Double mes champs de type Float même si j'ai un problème de précision ?

Envoyé par ShaiLeTroll

Il est drôle de s'interdire DevArt et d'utiliser un objet non documenté, je suppose que c'est juste pour des tests de migration, tu ne comptes pas l'utiliser réellement dans le projet (ou alors vous avez une stratégie des plus étranges !)

On souhaite par dessus tout limiter les composants tiers surtout s'ils sont payants.

Envoyé par ShaiLeTroll

la copie d'un SQLQuery vers un TClientDataSet, les deux types (ftFloat et ftSingle) fonctionnent ?

Les deux types fonctionnent sans problème.

**lefju cabro** · 17/04/2012, 17h13

Envoyé par Rayek

D'ailleurs en quoi le ClientDataset n'est pas top pour toi (ou tes supérieurs ?)

Lors de différents essais que j'avais pu faire sur les accès/update/insert de données, les temps d'accès étaient meilleurs qu'avec ClientDataset.

Comme nous mettons à plat actuellement les outils de dev de nos logiciels, je ne suis contre l'idée de tester un autre type de table mémoire.
Je vais regarder ce que m'a proposé ShaiLeTroll

**Nono40** · 17/04/2012, 19h33

Envoyé par ShaiLeTroll

Surtout qu'avec les processeurs (au moins à partir du P4 et peut-être même P3), un calcul sur un Single ou sur un Double est tout aussi rapide (même léger avantage au Double), pourquoi alors utiliser un peu précis sur il n'est pas nettement plus rapide !

Single prend aussi deux fois moins de place

Code :

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

TSQLConnection et un TSQLQuery me retourne toutes mes colonnes avec driver FB.

Donc déjà tu peux éliminer cette partie, le driver FB te renvoie bien toutes les colonnes.

**lefju cabro** · 18/04/2012, 12h23

Si je bascule mes champs Float en Double dans ma base, le TkbmMemtable récupère la colonne.

Quelles sont les changements que je peux voir dans mon appli ? Mes données sont de type scientifique et la précision est très importante pour moi. Il faut parfois conserver jusqu'à la 10ème décimale.

**Nono40** · 18/04/2012, 14h00

Alors justement utilise des doubles !
Comme le dit Shai le format double est bien plus précis que le format float.
Float est le format Single dans Delphi. Single est un flottant sur 32bits, il n'a pas plus de 7 ou 8 décimales.. Double est un flottant sur 64bits et contient 15 à 16 décimales.

**lefju cabro** · 19/04/2012, 08h37

Envoyé par Nono40

Alors justement utilise des doubles !
Comme le dit Shai le format double est bien plus précis que le format float.
Float est le format Single dans Delphi. Single est un flottant sur 32bits, il n'a pas plus de 7 ou 8 décimales.. Double est un flottant sur 64bits et contient 15 à 16 décimales.

OK, je vais passer en double mes données.

Merci à tous pour vos réponses.

**Nono40** · 19/04/2012, 17h40

Double est de plus le format par défaut dans Delphi. Si tout est en Double il n'y aura jamais de conversion et de perte de décimales.

Récupération de Float sous D-XE2 + FB 2.5 Impossible

Bases de données Delphi

Discussions similaires

Partager

Partager