Version imprimable
Bonjour
En migrant un projet C++Builder 6 vers C++ Builder 2009 je rencontre le problème suivant :
TIBDataSet dont la propriété SelectSQL contient une requête en apparence inoffensive (et fonctionnant en C++ B6)
je reçois l'erreur EDivByZero sur la méthode Open en C++B2009Citation:
select * from T1
left join T2 on T1.X = T2.X
left join T3 on T3.Y = T2.Y
where T1.Z=constante
Je ne comprends pas comment une requête peut produire cette exception ?
Poursuivant mes recherches :
le problème ne vient pas de la requête mais de la table. Certaines tables (même vide) provoque l'erreur dès l'ouverture du dataset (quel qu’il soit IBTable ou IBDataset)
Je cherche donc le type de champ qui disconvient à Rad Studio 9 car le comportement décrit est observable aussi bien sous Delphi que sous C++
Je précise aussi que j'accède à une base Firebird 2.1 avec les composants IB. Est ce compatible sous Rad Studio 2009 ?
L'origine de l'exception EDivByZero semble être dans la clause COLLATE FR_FR qui altère les champs de certaines tables. ce sont celles qui déclenchent l'exception.
Pour poursuivre les tests je teste désormais avec un TIBDataSet et place la phrase SQL dans SelectSQL. Je produis à volonté l'exception EDivByZero en ajoutant la clause COLLATE FR_FR dans la requête comme suit
El lisant la doc langage reference de Firebird 2.1 je vois qu'une nouvelle collation existe FR_FR_CI_AI compatible avec mon jeu de caractères ISO_8859_1. Cette collation déclenche le messageCode:select MOT_ID,MOT_MOT collate FR_FR from MOT
J'ai testé le même code sous Delphi 7. Il fonctionne parfaitement dans le cas Collate FR_FR et produit le même message avec FR_FR_CI_AI.Citation:
COLLATION FR_FR_CI_AI for ISO_8859_1 is not defined
Les tests se déroulent sur le même PC (avec la même version de Firebird et la même DLL GDS32).
A tout hasard, un test a été fait avec la dernière version de Firebird (2.5.1) (GDS32 6.3.1.26351) sans rien changer
Ensuite j'ai essayé sous Delphi 9 COLLATE ES_ES_CI_AI qui fait bien partie de RDB$COLLATIONS et cela déclenche l'exception EDivByZero
Le problème se précise mais la solution ...
A noter que le problème se déplaçant au fil des recherches il aurait plutôt sa place dans Firebird->SQL désormais !