Discussion :

[Papy214]

Bonjour tou(te)s

J'essaie d'utiliser une base DBase 4 avec Firedac et, n'étant pas vraiment habitué à ce genre de données un peu "old school", j'ai un petit souci de compréhension.
J'ai posé un composant TFDConnection et avec le minimum de paramètres, j'arrive à activer la connection dans l'inspecteur d'objet (en tous cas, le composant ne se plaint pas et la propriété Connected reste bien cochée.
Maintenant, je relie un composant TFDTable à la connexion et je voudrais choisir un nom de table. Sauf que là, la liste ne me propose rien.

J'ai voulu tester avec

Code :

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

FDConnection1.GetTableNames('', '', '', ListBoxTables.Items);

mais rien de mieux.

Je me dis alors que les premiers paramètres catalog et schema devraient être renseignés mais que faut-il y mettre, sachant qu'il s'agit d'un simple répertoire contenant les fichiers de données ?

Pour info, j'ai testé avec un TADOConnection et ça fonctionne bien mais la récupération de la liste des tables est extrêmement longue, et du coup, je crains de gros problèmes de perf pour le programme à migrer.

[ShaiLeTroll]

En même temps avec DBase4, c'est juste un FindFirst/FindNext sur les fichiers .dbf d'un répertoire
Comment spécifies-tu le dossier en FireDAC ou même en ADO ?
Au final, je suppose que tu passes par un driver ODBC : Microsoft dBase Driver (*.dbf) !?
Je n'avais jamais eu l'idée de les exploiter avec ces provider avec DBAse, j'utilisais Apollo DB Engine ou le BDE

De plus, je lis ceci dans la documentation : Migration d'applications BDE (FireDAC)

FireDAC ne supporte pas les bases de données de bureau, comme Paradox ou Dbase

[Papy214]

Oui, les tables ne sont que des fichiers facilement "listables" dans un dossier.

Le but est de faire pour le moment une migration du BDE vers Firedac en conservant DBase et ensuite de passer à Interbase.
Le client est un peu frileux et préfère une transition en douceur même si ça fait un peu plus de boulot.

Ce que je cherchais à faire c'est surtout définir le meilleur moyen d'accéder à ce dossier de données avec le composant TFDconnexion, et je me disais que le meilleur moyen de tester était de lancer une récupération des tables puis des champs de chaque table.

J'ai effectivement utilisé le driver microsoft fourni dans Windows en lien avec Firedac ODBC.

Et je viens à l'instant de trouver la solution. Pour le catalogue, il suffit de répéter le chemin du dossier de données. Je trouve çà un peu redondant , surtout au niveau de l'inspecteur d'objet, vu que le chemin est déjà disponible dans les données ODBC mais bon, ça fonctionne.

Je vais tout de même jeter un coup d'oeil à ce driver apollo. Questions sur ce produit: cet un accès direct aux données ou faut-il aussi utiliser ODBC ? Et sait-il aller cher les données dans un chemin réseau ?

[ShaiLeTroll]

C'est un composant payant qui remplace totalement le BDE et est intégré au programme, pas de déploiement supplémentaire !

Pour ma part, j'ai pu assisté à la migration Apollo+DBase vers MyDAC+MySQL,
je peux te dire que cela change énormément la logique du code,
rien que sur la gestion de la volumérie,
fini les TTables ouverts sur tous les enregistrements,
il faut faire de SQL économe, géré le partial fetch ...

Vouloir faire fonctionner ton programme en FireDac + DBase ne fera que perdre de l'argent à ton client !
Migré en Apollo, ce n'est intéressant si tu prévois que cela un choix qui dure entre 5 et 10 ans,
c'est si c'est juste pour la transition, idem perte de temps et d'argent

Sur un projet de gestion financier d'ONG en Paradox + BDE écrit massivement en SQL (oui, oui, inhabituel)
Un mois a été nécessaire pour migrer en Oracle + ADO (1 personne)
et un mois supplémentaire pour tester et corriger chaque petit détail (1 autre personne, moi)
et deux semaines pour ajouter de nouvelles fonctionnalités (moi aussi)

Sur un projet de gestion commercial d'une revue en DBase + Apollo, il a fallu 3 mois (1 personne, moi) + 1 mois de stabilisation (2 personnes, moi et un collègue)
Sur un projet de socio-médical sur le suivi de patient, il a fallu 3 mois pour migrer mais un an pour le stabiliser (2 personnes à plein temps sur ce projet)

Si vous êtes plusieurs, celui qui teste n'est pas celui qui développe et réciproquement !

[Papy214]

Tes paroles commencent à m'inquiéter ...............

Je vais peut-être revoir ma proposition parce que j'envisageai beaucoup moins que ça au point de vue temps de réalisation (en me basant sur une migration bde vers ado que j'avais réalisée il y a quelques années sur une autre application du même volume).

A savoir que tous les traitements sont extrêmement basiques dans la programme : Pas de SQL et que des TTable ouverts et fermés.
Quand je vois le nombre de composants utilisés sur chaque TForm, je pique une crise à chaque fois.

A te lire, je commence tout de même à me demander si j'ai bien fait de proposer ça.

Donc, revoir ma copie sur le nombre de jours de travail

En tous cas, merci pour les infos et ton retour d'expérience.

[SergioMaster]

Tes paroles commencent à m'inquiéter ...............
Je vais peut-être revoir ma proposition parce que j'envisageai beaucoup moins que ça au point de vue temps de réalisation

Bonjour,
passant par là je n'avais fait que les propos de ShaileTroll. Je confirme qu'il faut prévoir des temps de réalisation conséquent sauf à avoir des performances minables. Mon expérience se base sur une/des migrations BDE+Interbase (et quelques fichiers Paradox) vers ZEOSDBO puis maintenant FireDac + Firebird, mais aussi DBExpress -> ZEOSDBO.
Avec BDE les/s programmeur/s (dont moi) à l'époque usaient/abusaient de TTable.

Je suis encore en train d'en faire une actuellement. Grosso modo, en environnement de travail (donc avec interruption) je compte une forme ( plus exactement écran quand il y a des PageControl) à 1/2 jour

il faut faire du SQL économe, gérer le partial fetch ...

j'abonde dans ce sens

maintenant, si l'application utilisait paradox, le nombre d'accès concurent (muti-utilisateur) doit être faible.

L'outil de migration proposé est :bof:....
La méthode que j'applique actuellement
2 Postes
un avec la version D3
un avec D XE10
un tightVNC entre les deux et beaucoup de copier-coller, comme il y a des différences de composants en plus (non installé sur XE10) ça complique le pb

[ShaiLeTroll]

Je suis encore en train d'en faire une actuellement. Grosso modo, en environnement de travail (donc avec interruption) je compte une forme ( plus exactement écran quand il y a des PageControl) à 1/2 jour

1-2 jour par écran simple, oui, c'est une bonne estimation de départ,
on oublie souvent le temps de test qui est parfois plus long que le temps de codage
parce qu'il faut créer des cas de tests et parfois suivre une série d'écran avant d'arriver à celui que l'on veut tester

@Papy214
J'évoquais 3 mois, c'est parce qu'il y avait presque 100 TForm dans ces projets, certaines anodines et d'autres plus complexe
dans le projet socio-médicale, un écran contenant de 5 à 15 onglets selon la complexité du dossier patient, chaque onglet était une TForm ancrée
La structure même du projet était complexe

En fait, je n'ai jamais fait de migration sur un de mes propres projets,
faut aussi penser qu'il y a eu un temps d'adaptation et de prise en main du "métier" du logiciel à migrer

[SergioMaster]

Re,

ma veille techno sur Linkedin vient de me rappeler ce produit : DelphiParser

[Papy214]

J'ai aussi eu cette info sur delphiparser et ça aurait pu être une bonne solution (si ça fonctionnne aussi bien que ça).
Mais le site indique:

BDE Code to FIREDAC For Delphi Seattle 10

Le projet est en XE7

[Papy214]

L'outil de migration proposé est :bof:....
La méthode que j'applique actuellement
2 Postes
un avec la version D3
un avec D XE10

La première fois que j'avais fait ça de BDE à ADO, j'avais fait une moulinette à base d'expression régulière.
Je traitais chaque fichier dfm individuellement dans un éditeur créé avec delphi puis je faisais les ajustements nécessaires si besoin.
Ensuite, j'ouvrais les .pas dans delphi, je rajoutais un espace n'importe où et j'enregistrais.
Là, delphi m'annonçait les différences de type entre le dfm et le .pas et me proposait de faire la correspondance pour moi.
Ensuite, je faisais chaque adaptation de code au besoin et je passais au suivant.

Je pensais utiliser le même système. Bien sur, je ne ferai aucune amélioration de code mais le plus important dans le cas présent est surtout de virer le bde pour éviter les problèmes de configuration sur chaque poste, les versions de bde qui ne sont pas à jour, etc.

Je vais faire un essai sur quelques fichiers et estimer le temps total (sans doute un peu mieux qu'au départ )