Discussion :

[navyg]

Bonjour,

Je suis maintenant sous embarcadero 10.4
Je dois migrer une application sur base paradox et je trouve dans l'aide embarcadero qu'il est possible d'attaquer une base paradox à partir des composants de l'onglet BDE, mais je ne trouve pas cet onglet ? Je dois être neuneu ...
Faut-il installer spécifiquement ces composants ?
Sinon y a t'il une solution pour attaquer une base paradox avec d'autres composants.
J'aimerai bien utiliser la base pâradox pour migrer les résultats directement dans une autre base mais je ne sais pas si c'est possible
Merci à ceux qui pourront me renseigner.

Bien cordialement

[SergioMaster]

Bonjour,

Question posée il y a peu par zarbouine ce qu'une petite recherche vous aurait permeis de trouver
Même réponse donc il faut télécharger dans son espace le bon zip. Un seul reproche à cette installation, elle n'installe non seulement les composants mais aussi BDE dans le répertoire de la version
Bien sûr je ne répeterai jamais assez que BDE est obsolète, qu'il n'est que 32 bits et qu'il y a des précautions d'installation et de paramétrage à prendre (indiqué toujours dans la même discussion)

[navyg]

Bonjour,
Merci beaucoup. Je n'avais pas accès à internet ces derniers jours, donc je ne découvre votre message qu'aujourd'hui.
Vous dites qu'en cherchant j'aurai trouvé le message de zarbouine. Effectivement, je pensais qu'en tapant ma recherche sur google j'aurai trouvé ce sujet, mais je n'ai pas eu le réflexe de faire la recherche directement sur le forum. Vous m'en voyez désolé.
Je vais donc m'orienter sur les solutions évoquées.
Si je rencontre des difficultés, je me permettrai de revenir sur le sujet.

[ShaiLeTroll]

Pour la migration, j'aurais aussi un conseil

Déterminer quelle est la version de Delphi utilisé pour générer la dernière version.
Compiler une nouvelle version sans rien modifier, s'assurer de la non-régression.
Au moins, tu n'auras pas à supporter la différence de Delphi pour cette étape qu'il ne faut pas négliger si l'on reprend un projet que l'on ne connait pas ... je pense à l'Unicode par exemple si l'on passe d'une version ultérieure à D2009 (comme D7)

Je n'installerais pas le BDE dans Delphi 10.4 mais uniquement, si nécessaire, dans l'ancienne version Delphi associé au projet.
Avant, revoir la structure de la base de données en fonction du nouveau SGBD.
Optimiser les jointures, normaliser sa DB et la dénormaliser ensuite pour les performances viendra ultérieurement.

Profiter que justement que 10.4 ne compile pas le projet sans le BDE pour revoir tout le code, oublier le TTable si il existe et n'utiliser que des Query et SQL.
En profiter pour ajouter peut-être même une abstraction entre le code IHM basé exclusivement sur du TDataSet sans qu'il soit nécessaire de prendre en compte si c'est ADO, FireDAC, UniDAC ...
Le code métier lui expose juste ce qu'il faut pour les vues, le code métier lui prend en compte le SQL spécifique au SGBD, voire à l'extrême de l'abstraction le code métier lui même peut reposer sur un socle technique encaspulant le provider.
c'est une stratégie de découplage à long terme.

Ne pas installer le BDE peut sembler délirant mais c'est pour s'imposer une dynamique de réécriture et pas un vilain portage.


Création d'un projet de migration qui convertir du Paradox en SQL puis ce SQL pouvant être importé dans le nouveau SGBD.

J'ai pu voir des projets de migration qui tentait de reproduire le "comme avant", un résultat souvent décevant, une longue période de version instable, peu performante ...
Repenser, redocumenter, réécrire complètement ... peut donner un gros plus pour le projet, sa pérennité, sa stabilité.
Sortir des versions par itérations avec une couverture partielle des fonctionnalités des plus essentielles jusqu'à celles de confort, impliquer des personnes pour tester tester tester au fur et à mesure des pré-versions, préparer la documentation de recette pouvant à terme servir pour la documentation utilisateur.

[navyg]

Merci pour ces conseils.
Je voulais installer les composants bde dans ma version actuelle pour pouvoir récupérer les tables depuis mon ordi actuel et pas rallumer un très vieil ordi sous w98 avec delphi3, c'est tout
De toute façon malgré une licence valable pour 10.4 sydney, je n'ai aucun download proposé. Peut-être parce que j'ai une community edition ? c'est un peu "rapia" de la part de l'éditeur ... je ne vois pas ce que ça lui couterait de donner les composants bde pour les version CE ...

Si quelqu'un avait le zip pour sidney10.4 ce serait sympa.

Bien cordialement

[ShaiLeTroll]

...pas rallumer un très vieil ordi sous w98 avec delphi3, c'est tout

Il ne serait pas inutile de passer par Delphi 7 Pro si vous en avez un, déjà rien que le passage de tout les DFM binaire en DFM Texte et commencez un dépôt tel que SVN\GIT
Delphi 7 existe en version Personnel et ne contenait pas le BDE
Delphi 3 n'était elle pas une version Professionnel ?

Préparer tout de suite votre code avec Char, AnsiChar et WideChar et leurs pointeurs, pour anticiper le passage ANSI vers UNICODE.

Si vous pouvez relancer cette machine, construire le projet pour vérifier que c'est encore fonctionnel.
Cloner le projet et commencer un travail de refactoring seulement
Découpler le plus possible le code, faire en sorte que les TForm soit le moins dépendantes des unes des autres, idem pour les TDataModule, toujours produire une version et vérifier la non-regression

Cloner de nouveau le projet (Branche par exemple sur GIT)
J'espère que vous avez prévu de migrer Paradox vers SQLite par exemple

Si oui
Travail de suppression du BDE en créant des objets factices émulant TTable\TQuery, juste le prototypage pas l'implémentation.
Grace au travail de découplage de TForm, vous pourrez ainsi créer un nouveau projet D10 en y intégrant fenêtre/module par fenêtre/module avec le nouveau provider.

Si non
Euh ...

Peut-être parce que j'ai une community edition ? c'est un peu "rapia" de la part de l'éditeur

Je pense que proposer le BDE aujourd'hui ce n'est que pour les professionnels souhaitant migrer leurs applications, cela fait depuis 15 ans que Thierry Laborde répétait chaque année lors des conférences qu'il fallait oublier le BDE.

Proposer le BDE dans la Community Edition qui a pour but de montrer l'IDE aux développeurs amateurs tel que les étudiants est clairement un non-sens, on ne va pas commencer un projet aujourd'hui avec une technologie dépassée.
C'est même un pré-requis pour la version 64Bits de l'IDE car le BDE qui n'est que 32Bits, l'explorateur de données ne pourra plus l'utiliser sans compter tout le Design Time de TTable qui ne pourra plus exister.


Ce projet est-il commercialisé car en théorie passer d'une version professionnel à community edition n'est pas autorisée.

[navyg]

@ShaiLeTroll

Je précise que je n'ai jamais vendu un seul logiciel et que je programme pour mon plaisir.
Je m'étais payé à l'époque un delphi 3 pro pour mon usage perso.
Le projet sur lequel je travaille est la conversion d'un programme de gestion d'une association que j'avais fait il y a 20 ans maintenant et qui tourne donc sous une base paradox.
Toutes tables confondues, il doit y avoir pas loin de 100 000 enregistrements donc j'aimerai bien automatiser la reprise sous un système firedac/mysql qui me semble assez pérenne.
En plus j'ai fait d'autres applis pour moi sous mysql et je maîtrise un peu.

Le programme fonctionne toujours très bien, mais je me dis que un de ces jours on ne pourra plus du tout migrer pour une raison ou une autre donc je m'y attelle ...
Le pc win98/delphi 3 fonctionne encore mais en 1024x768 au mieux donc je peine un peu avec mes vieux yeux ... j'ai même recompilé le programme et ça le fait !

J'ai bien conscience que ce sera un gros boulot, ne serait-ce que pour faire une moulinette pour extraire les données paradox sous forme de requête sql à réinjecter dans la future base mysql, mais il faut se lancer pour y arriver un jour.

Bien cordialement.

[free07]

Bonjour,

J'ai bien conscience que ce sera un gros boulot, ne serait-ce que pour faire une moulinette pour extraire les données paradox sous forme de requête sql à réinjecter dans la future base mysql, mais il faut se lancer pour y arriver un jour.
Bien cordialement.

Pour l'extraction des données il existe des outils gratuits, une recherche avec le mot clé datapump permettra certainement de trouver l'outil permettant de recopier les données de Paradox vers la nouvelle base.

Par exemple pour interbase : https://blogs.embarcadero.com/fr/mig...-to-interbase/

[popoy]

Pour info convertisseur open source paradox vers MySQL
https://sourceforge.net/projects/paradoxtomysql/

[navyg]

Ok pour ces infos, merci beaucoup.
J'avais essayé avec un composant ado et ça n'a pas marché
J'ai aussi essayé avec l'explorateur firedac mais j'ai une erreur à l'importation de l'alias avec un message "impossible de convertir le variant de type(Null) en type (boolean). Malgré toutes les corrections que j'ai pu faire, impossible d'utiliser cette voie.
Mais je suis presque arrivé à mes fins ... mais je vais voir cet outil.

[ShaiLeTroll]

J'ai bien conscience que ce sera un gros boulot, ne serait-ce que pour faire une moulinette pour extraire les données paradox sous forme de requête sql à réinjecter dans la future base mysql, mais il faut se lancer pour y arriver un jour.

LA moulinette c'est facile, je n'ai plus le code de ma TParadoxToSQLForm qui produisait des INSERT, rien d'insurmontable, faut juste bien gérer les formats de date ... à l'époque le fichier étant lu par MySQL Administrator mais fonctionnait aussi avec un TMyDump de Devart, avec un autre template SQL, cela supportait la transition vers Oracle
Tu peux le développer en D3 cet outil, je l'avais fait en D7 et il n'y a rien de bien différent, j'ai juste TTable + la fonction Format sur des templates SQL

Toutes tables confondues, il doit y avoir pas loin de 100 000 enregistrements donc j'aimerai bien automatiser la reprise sous un système firedac/mysql qui me semble assez pérenne.

j'ignore en combien de table c'est réparti mais si en gros tu as 5000 par table, tu n'auras pas de mauvaises surprises de performance même avec un TTable, c'est le problème de passer d'une base de données fichier accédé en direct à un SGBD plus complexe.
On verra plus tard pour évoquer le Packet Row
En D7, 2006, une seule table faisant 300 000 enregistrements, c'est passé crème en modifiant la façon de lire la table

[SergioMaster]

je trouve dans l'aide embarcadero qu'il est possible d'attaquer une base paradox à partir des composants de l'onglet BDE,

Oui mais il est possible de se connecter à des tables paradox (je n'ose appeller cela une base de données) avec Firedac.

"Si ce n'était que pour migration était-il possible de ne pas avoir besoin des composants BDE ?"
C'est la question que je me pose car j'ai vu que via Firedac/ODBC il est possible de se connecter aux tables Paradox (entre autres). Cela dit il faut quand même les drivers ce qu'une installation de BDE (pas des composants entendons nous bien) soit quand même nécessaire.

J'ai donc un peu fouiller sur mon PC maintenance, dégotté une ou deux tables paradox que j'ai transféré et tenté le coup

C'est normalement possible mais j'avoue que je butte sur
.

Or donc, je me suis mis à triturer un peu plus le truc et après quelques modifications du FDConnection (je mettrai au besoin lesquelles) le FDTable me posait toujours souci (mais un autre message)
alors qu'un FDQuery fonctionne nickel

La moulinette c'est facile

Faire ensuite un FDBatchmove ne pose donc aucun problème par la suite. J'ai du écrire quelque part sur le forum qu'il n'était même pas besoin de faire un exécutable, le designtime suffit pour faire les transferts
une fois la structure de la BDD MySQL ou autre faite cela devrait le faire (je ne me souviens plus si Batchmove ne peut pas créer la structure d'une table si inexistante d'ailleurs, faudra que je vérifie)

En conclusion : il y a "migrer une application" en utilisant l'outil reFind (normalement dans Embarcadero\Studio\21.0\bin à vérifier) et "migrer les tables" en utilisant Firedac. Tout cela nécessite (peut-être) BDE mais pas les composants BDE (AMHA)

Mais garder une structure de table Paradox quand on a un SGBD relationnel c'est un peu mettre un moteur de 2CV dans une Ferrari (enfin ça dépend du SGBD).
garder le code de l'ancienne application (après reFind) me semble tout aussi peu efficace

Les conseils de ShaiLeTroll

Avant, revoir la structure de la base de données en fonction du nouveau SGBD.
Optimiser les jointures, normaliser sa DB et la dénormaliser ensuite pour les performances viendra ultérieurement.
... oublier le TTable si il existe et n'utiliser que des Query et SQL.

sont plus que bons

[navyg]

Mais garder une structure de table Paradox quand on a un SGBD relationnel c'est un peu mettre un moteur de 2CV dans une Ferrari (enfin ça dépend du SGBD).

Si je me lance dans ce gros projet de migration, c'est bien pour ne plus travailler sur les tables paradox, mais pour choisir une structure plus actuelle

[ShaiLeTroll]

N'hésite pas à le faire en deux temps
Une base de migration identique à la structure Paradox pour le DataPump avec une vérification de la cohérence des données, qu'il n'y ait pas de perte comme les dates ...
Une base revue pour le projet qui pourra être rempli depuis la base de migration via SQL ou via un outil comme TALEND

Sinon, l'AutoInc de paradox et des jointures via ID numérique, ça reste toujours valable, juste bien déclarer PRIMARY et FOREIGN KEY

[SergioMaster]

je "retombe" sur cette erreur de "Table externe n'est pas dans le format attendu"
Je n'ai changé ni les options de connexion ni le SQL de quoi devenir chèvre. Je n'aime pas l'ODBC et ça me conforte dans mon opinion mais j'aimerais quand même comprendre.

Est-ce que quelqu'un s'est réellement frotté à Firedac/ODBC/Paradox ?

[navyg]

Bon je vais marquer ce sujet comme résolu car j'arrive à faire dans une petite appli la lecture des paradox et la lecture ou l'écriture en mysql avec les composants firedac
Par contre je vais ouvrir un nouveau sujet sur RecNo !

Merci à tous pour vos conseils.

[SergioMaster]

Je ne voulais pas rester sur un échec niveau connexion ODBC après avoir lu dansr un forum anglophone cette discussion (je m'en souvenais mais avais jamais vraiment tester ODBC n'étant pas mon truc) j'ai donc poussé le bouchon (avec des tables Pardox fiables)

Voilà ce que je ferais avec l'IDE (la grille étant optionnelle, juste pour montrer qu'il est possible d'accéder à des tables paradox sans BDE)


Si la table est créée dans la BDD mySQL avec la même structure (une structure différente demandant tout au plus un peu de boulot) un simple clic droit sur le FDBatchmove pour ontenir le menu contextuel puis Exécuter devrait* remplir la table.

*devrait car je tombe encore sur une erreur (j'ai toujours été fâché avec ODBC et ADO, cela persiste )


A propos de Biolife.db (le fameux biolife) j'ai été surpris de constater que dans cette version on n'avait pas la colonne graphic, c'est moi où ????

[navyg]

La moulinette est déjà écrite et fonctionnelle, car j'ai déjà tout récupéré dans une base MariaDB sur mon NAS.

je me doutais que c'était un peu tard. De ce que je comprends du problème (et pour avoir fait d'autres migrations entre facilement en utilisant la technique batchmove uniquement via l'EDI) c'est une histoire de blocage paradox

Je voulais la mettre sur un hébergement, mais je me suis rendu compte que autant il est facile de trouver un hébergeur pour des bases mysql accessibles par le web, autant il est difficile d'en trouver un (pas cher) qui permette d'accéder à la base à distance avec un logiciel dédié

la solution le multi-tiers et non le client serveur

heidisql - logiciel remarquable

écrit avec Delphi, c'est à souligner. C'est le GUI que j'utilise pour MySQL après essais de beaucoup d'autres, j'ai compris la structure de la base de données de Prestashop grâce à cet outil et prépare presque toujours les requêtes sur cette BDD avec avant de passer à la rédaction sur le portail de la boutique (SELECT uniquement, dommage)

[navyg]

c'est quoi le multi-tiers ?

[SergioMaster]

Bonne question.

Il y a un schéma qui résume bien la différence entre client/serveur et multi-tiers il faudrait que je remette la main dessus.
l'application
En gros
- client/serveur l'application client se connecte directement à la base de données
- multi tiers l'application client fait appel à une application hébergée qui elle interroge la base de données. La communication entre le programme client et l'hebergée se fait par l'intermédiaire généralement d'un format standard (XML ou JSON). Le truc très à la mode : REST/API c'est ça du multi tiers.

En pratique (là pprem l'expliquerait mieux comment installer tout ça) Il y a un site web, la bdd et des "fonctions" php le programme client fait appel à ces fonctions.
Plusieurs bouquins sur le sujet, dont le livre de Thierry Gracia "Delphi 10.3 : programmation objet en environnement windows"
et beaucoup de webinaires.