Discussion :

[SergioMaster]

Bonjour,

j'ai encore de vieilles applications utilisant le BDE comme moyen de connexion à une Base de Données. Comme c'est une vieille application de l'autre siècle, la base était à l'époque en CHARSET NONE . On m'a demandé de l'installer pour pouvoir l'utiliser en attendant une version plu récente, je me suis dit pourquoi pas mais tant qu'à faire, puisqu'il s'agit d'une nouvelle base, je vais la créer en WIN1252.

Hélas dès que je lance l'application j'ai des types de champs incorrects ! (champs déclarés dans le programme), cela n'est pas la faute de Firebird mais bien de la liaison avec le BDE.


Maintenant, je pense qu'il y a peut être un moyen quand même (sans retravailler l'application) au niveau de ce moteur pour indiquer de faire le travail d'interface WIN1232 -> NONE ? Ma question (qui n'est pas tout à fait Firebird) : Si quelqu'un a encore / utilise toujours BDE peut être pourrait-il m'indiquer la solution ?

N.B. bien évidemment comme c'était urgent, j'ai reconstruit une base vide charset NONE, et ce W.E. je me pencherai vraiment sur la question (j'ai vu quelque part une histoire de langue driver pour le BDE mais je doute)

[ALWEBER]

Bonjour,

Ayant longuement travaillé sur le BDE et bien sûr sur PARADOX. je vais essayer de regarder ce WE dans mes archives.
Envoies-moi un bout d'exemple.

Cordialement
Alain

[SergioMaster]

Merci de répondre,
moi aussi je vais essayer de me pencher dessus ce WE. En gros, c'est relativement simple une SGBD Firebird en CharSet NONE avec une table contenant différents types : SMALLINT, INTEGER, CHAR,VARCHAR,DATE,TIMESTAMP et un numerique DECIMAL(18,4), DECIMAL(18,0) et la même en Charset WIN1252
un programme (D3 dans mon cas) qui ouvre cette table (TDatabase, TTable) et dont tous les champs sont déclarés (à partir de de base en charset NONE)
il suffit ensuite de changer l'alias pour qu'il pointe sur la base en Charset WIN1252 pour se prendre un (enfin c'est le test que je vais faire, car il y a aussi une histoire de 32/64 bits qui pourrait jouer les troubles fêtes )

[Papy214]

ton composant TTable, il a des champs ajoutés en dur dans le dfm ?
Si oui, est-ce que tu as tenté de les supprimer et les récréer ?

[SergioMaster]

ton composant TTable, il a des champs ajoutés en dur dans le dfm ?

Oui et c'est là que ce situe le problème

Si oui, est-ce que tu as tenté de les supprimer et les récréer ?

je voulais éviter de faire une retouche des programmes (sans ça c'est ce que j'aurais fait) c'est pour cela que je suis retourner sur une base NONE

j'en profite pour dire que j'ai commencé l'essai et que l'ajout de Champs tels que BIGINT, DECIMAL n'est pas du goût de D3

[SergioMaster]

Bonjour,

en creusant et avec pas mal de tests. La vieille application utilisait au départ un base Interbase 5.4 puis a migré vers Firebird 1.5 puis 2.1, les tests ont été effectués sur une version 2.5 . Le constate que les NUMERIC et DECIMAL que je tente de déclarer sont de type TBytesField pour le BDE au lieu de TFloatField
Le problème est donc plus complexe et donc la ré-écriture hors de question (il faudrait que je remette un gds32.dll plus ancien pour vérifier à moins que cela soit du à la version du BDE) du coup le charset ne serait en cause ?
Etrangement un test sur la "vieille base", et des tables existantes le type est correct du coup je ne sais plus trop quoi en penser !

je résume : (vieille ) Base migrée charset NONE, DIALECT 1 un NUMERIC devient bien un TFloatField
Base charset NONE neuve , DIALECT 3 Firebird 2.5 (avec création de la table) un NUMERIC devient un TBytesField << c'est là le hic
idem pour Charset WIN1252
Base charset None DIALECT 1 NUMERIC -> TFloatField

et l'utilisation de l'explorateur de D7 me le confirme! (une idée qui m'est passé par la tête) j'ai voulu tester la base par DBexplor.exe fourni avec D7 qui me l'a explicitement indiqué :

Client SQL dialect 1 does not support reference to

J'ai enfin mon coupable ! et pas de solutions autre que rester en Dialect 1 pour cette application vu "l'usine à gaz" cela restera ainsi

il s'agirait donc d'un problème de dialect, cependant mettre DIALECT=1 dans les paramètres de TDatabase ne fonctionne pas

[ALWEBER]

J'ai recherché dans mes archives -
Voilà sans aucune garantie qu'être une source d'inspiration le petit programme ci-joint

[SergioMaster]

Bonjour,

@Alweber merci de t'être donné cette peine mais ....
il ne s'agit pas d'une migration Paradox vers Interbase (ou Firebird) et bien d'un problème de Dialect d'une base Firebird (passage de Dialect1 à Dialect 3).
En fait BDE ne sait pas (puisqu'il est obsolète) géré certains types du Dialect 3 par défaut ils sont alors définis comme TBytes (du moins est-ce plus ou moins ce que je saisi) ce qui provoquais donc l'erreur de mes champs "persistants".

Point positif cela m'a permis de découvrir (en limite du sujet) une des fonctionnalités de Firedac : les règles de mappage (puissant !)

Néanmoins comme cette application est en fin de vie (contrairement à la base de données), je ne vais pas "m'amuser" à ré-écrire. Ma solution reste donc de garder pour l'instant la base en dialect 1 quitte à la migrer ensuite en dialect 3 ,ce qui me permettra de mettre au point un outil de migration (bien que IBexpert version pro en a un) adapté (je pense entre autres aux copies de blobs impossible à faire en SQL << ça c'est une grosse lacune).
Dommage que je n'ai plus de stagiaire sous la main

Avec ce sujet, je voulais surtout montrer certaines limites du BDE en association avec Interbase/Firebird.
Vous vous demanderez certainement: "pourquoi la base est en Dialect 1 ?" tout simplement parce qu'elle a été crée avec la version d'interbase fournie avec D3 (voire même peut être Delphi 2 je ne m'en souvient plus) donc Interbase 5.2 je crois (je regarderai sur mon CD si je remet la main dessus) et que le Dialect 3 n'existait pas (du moins j'ai relu en diagonale les manuels de Interbase 5 sans y trouver cette notion)

La base étant en exploitation une migration en dialect 3 (malgré ses apports) n'avait pas été envisagée même après les passage successifs de 5.2 à 5.4 puis 5.5 puis 6.5 puis Firebird et ce jusqu'à 2.5. D'où la "surprise"

[ALWEBER]

Je ne savais pas que tu passais par FireDac à titre d'exemple voici la surcharge de TfdConnection que j'utilise :

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
29
30
 
  inherited Create(AOwner);
  Params.Values['DriverID'] := 'MSSQL';
  Params.Values['ApplicationName'] := 'Client/Server';
  Params.Pooled := true;
  fOptions := TMSConnectionOptions.Create;
  fOptions.fProvider := prSQL;
  fOptions.fPseudoDefaultLockTimeOut := 2000;
  FormatOptions.StrsEmpty2Null := true;
  FormatOptions.OwnMapRules := true;
  FormatOptions.AssignedValues := [fvMapRules];
  ResourceOptions.AutoConnect := true;
  ResourceOptions.AutoReconnect := true;
  // test lock sql
  // FetchOptions.Mode := fmAll;
  // FetchOptions.LiveWindowFastFirst := True ;
  // - FetchOptions.CursorKind
  // - FetchOptions.LiveWindowFastFirst
  // - FetchOptions.RowsetSize
  // - FDConnection.TxOptions.Isolation
  // Fin test
  aRule := FormatOptions.MapRules.Add;
  aRule.SourceDataType := dtBCD;
  aRule.TargetDataType := dtDouble;
  aRule := FormatOptions.MapRules.Add;
  aRule.SourceDataType := dtDateTimeStamp;
  aRule.TargetDataType := dtDateTime;
  aRule := FormatOptions.MapRules.Add;
  aRule.SourceDataType := dtFmtBCD;
  aRule.TargetDataType := dtDouble;