Discussion :

[SergioMaster]

Bonjour,

j'ai d'anciennes applications D3 que je dois encore maintenir. Celles-ci à l'époque, utilisaient une base de Données Interbase 4.5 qui a migré ensuite en 5.4 puis 6 afin d'aboutir en Firebird 2.1 ceci pour expliquer :
- le contexte
- le dialect de la base resté à 1

j'ai été obligé de créer une nouvelle table dans cette base
pour tester : mon poste utilise firebird 2.5

Avec une nouvelle application ou directement avec un GUI Firebird (flamerobin) je n'ai aucun soucis de connexion à cette table mais avec l'ancienne application que je dois modifier je reçois un message abscons m'indiquant que le client en dialect 1 ne supporte pas BIGINT ! alors qu'il n'y a aucun BIGINT dans la table

du coup je n'arrive pas à trouver l'origine du problème BDE, informations dans TDatabase, autres ?
Quelqu'un aurait-il déjà eu ce problème (c'est la deuxième fois que cela m'arrive sur cette semaine! j'ai contourné la première mais sur cette deuxième je séche )

[edam]

salut
je crois que c'est normale integer fb2.5(64bit) pour D3 (16bits) le vois comme bigint

[SergioMaster]

Merci de la réponse mais avec une autre application test cela fonctionne donc ce n'est pas une question de bits de l'OS (d'ailleurs D3 fait des 32bits pas des 16)
de plus j'ai omis de le préciser le poste sur lequel je fais ce travail est un 32 bits (donc firebird 2.5 32bits)

En cernant mieux, il s'avère que l'ouverture en table (TTable) se passe correctement, c'est une requête (TQuery) qui me pose ce souci
en réduisant les colonnes à récupérer (donc pas de SELECT * mais un SELECT précis) j'ai réduit le problème à la colonne qui était en DECIMAL(18,0)

je vais la passer en INTEGER simple ou en NUMERIC(?,0) pour voir ce qui va se passer. La suite au prochain épisode avec je l'espère un Résolu

[ShaiLeTroll]

NUMERIC(9, 0) ou alors DECIMAL(14,1) pour le forcer en Double, tu auras ainsi des nombres plus grand si le besoin se fait sentir !

C'est pareil sur ORACLE, cela retourne parfois un BIGINT sans trop raison apparente
Une Colonne NUMBER(9) alimenté en PL/SQL par une SEQUENCE non plafonné, et cela produit du ftLargeInt car il utilise le type la séquence et non le type du champ recevant la valeur

[SergioMaster]

NUMERIC(9, 0)

qui n'est en fait qu'un integer passe

Code :

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

DECIMAL(14,1) pour le forcer en Double,

ne passe pas étrangement, alors que j'ai du NUMERIC(15,2) ou NUMERIC(15,4) dans la base d'origine

je pense que c'est du au changement de DIALECT et de l'interprétation qui en est faite alors par Firebird, j’essaierai de voir ça ce week-end en fouillant du coté des tables systèmes. Comme Integer couvrira largement mes besoins je vais en rester là. Etrange quand même que le TTable accepte et pas le TQuery, que même si le DIALECT est forcé dans les paramètres de TDatabase (SQLDIALECT=3) ce ne soit pas pris en compte, mais bon il s'agit de D3

mon problème est mais je vais laisser ouverte cette discussion le temps de faire un test avec D7, puis d2010 disponibles sur ce poste et pour cette fouille table système si j'ai le courage