Discussion :

[Kephuro]

Bonjour à tous !

Je suis en train de développer une petite application permettant de transférer certaines données (choisies) d'une table source vers une table destination.

Le truc c'est que la nature de la source de données (Excel, Access, Oracle, Mysql...) et la destination ne doivent pas avoir d'importance (c'est le but de l'appli en fait).

Pour la petite histoire : Je suis encore étudiant en informatique (BTS IG) et lors de mon stage de 2ème année qui s'est terminé il y a peu, on m'a demandé dans le cadre d'un développement de travailler avec des fichiers Excel. Les gars voulaient utiliser access pour stocker des infos et j'ai dû coder un petit truc permettant de transférer certaines données (toutes n'étaient pas importantes/pertinentes) du fichier excel vers Access.
Je connaissais pas trop tout ce p'tite monde là, OLE, ADO, ODBC...mais je me suis quand même rendu compte qu'à mon avis on pouvait "simplement" faire bien plus que du Excel vers Access, mais potentiellement du n'importe quoi vers n'importe quoi pour peu qu'on dispose du driver ODBC.
Je me trompe sûrement dans l'utilisation de certains termes, le sujet est particulièrement complexe pour un non-initié (et même pour les initiés, j'en suis sûr ), aussi ne m'en tenez pas trop rigueur



Pour l'instant ça fonctionne bien avec Excel et Access mais j'ai des difficultés pour utiliser d'autres SGBD (même si je ne pense pas qu'Excel et Access soient des SGBD ?).

Je ne maitrise pas vraiment les composants ADO et j'étais donc plutôt sur des générations de requêtes style INSERT INTO pour transférer les données.
Le souci c'est que les requêtes qui fonctionnent sur l'un ne fonctionneront pas spécialement sur l'autre (essayez les crochets [ ] sur une requête vers MySQL il enverra bouler, alors que pour Excel et Access c'est nécessaire).

Mon but c'est de coder le moins de "rustines" possible et de faire quelque chose d'assez générique, fonctionnant sur un maximum de SGBD différents, et pas faire un truc genre "Si Excel alors machin, si Mysql alors bidule..."...etc...chose que je commençais à faire avec les requêtes SQL.

Et au final je me demande si j'ai bien retenu la bonne solution. Est-il possible d'utiliser les composants ADO et notamment les DataSet (pas encore trop familiarisé avec les termes et les fonctionnalités de chacun, mais ça viendra) pour simplifier le travail ?

Ou alors est-ce que le plus simple pour faire du "générique" c'est d'utiliser les requêtes SQL ?



Merci d'avance pour vos avis et conseils

[Aka Guymelef]

Euh sans vouloir être cassant je pense que c'est une problématique qui existe depuis longtemps et que si quelqu'un avait déjà une solution miracle générique et bien tout le monde l'utiliserais.

En ce sens pour moi c'est déjà quasiment le cas puisqu'avec ADO on peut se connecter quasiment à toutes les base de données avec un moyen uniforme (chaîne de connexion). Par contre l'utilisation en elle-même reste spécifique à la base de donnée. Normalement le média unique devrait être le langage SQL ce qui est plus ou moins le cas en général (bien qu'il y ait des fois des divergences d'implémentation comme les fameux [] d'Access/SQL Server). En fait ce sont justement ces divergences qui donnent une certaine identité à chaque SGBD(R?) sinon finalement on aurait qu'un seul moteur unique qui s'appellerait SGBD et puis c'est tout non ?
Et je ne parles pas des fonctions systèmes, des routines qu'on a dans l'un et pas dans l'autre, etc...

Bref pour que ADO fonctionne il faut à priori que le SGBD implémente un pilote. Je ne sais pas si cela implique des fonctions d'ajout/modification/suppression (autrement que de passer par du SQL) et si c'est ce genre de chose qui est utilisé par les composants genre ADOTable où c'est le composant qui gère les modification sur la table...
Pour moi s'il devait y avoir une façon portable de faire les interactions cela devrait être du SQL. Mais là encore même si une majorité est respectée, des divergences apparaîssent. Donc faire un code full générique sans if Access if Oracle if MySql if SQLServer, ben honnêtement je vois pas.

[Kephuro]

Euh sans vouloir être cassant je pense que c'est une problématique qui existe depuis longtemps et que si quelqu'un avait déjà une solution miracle générique et bien tout le monde l'utiliserais.

Je sais bien ! Je n'ai pas non plus l'intention de coder la solution miracle, juste un truc qui soit compatible avec un maximum de choses. Si c'est compatible qu'avec 3 SGBD, m'en fiche.

Mais tu as bien répondu à ma question, je pense qu'utiliser le SQL est le meilleur moyen, celui sur lequel théoriquement il y a le moins possible de "rustines" à faire. Je n'utilise pas les fonctionnalités avancées de chaque SGBD, juste celles de base pour de la lecture et de l'insertion de données.

D'après ce que j'ai pu lire, les composants ADO génèrent de toutes façons du SQL et ça me semble logique qu'ils adaptent leur syntaxe pour un SGBD, c'est pour celà que je me demandais s'il n'était pas plus simple d'utiliser ce système là. Mais du coup, il semblerait que ce soit le curseur (ou moteur de curseur, j'ai pas bien rentenu) qui soit plus ou moins spécifique à chaque SGBD, ce qui déplace juste le problème au lieu de le régler.

[Aka Guymelef]

D'après ce que j'ai pu lire, les composants ADO génèrent de toutes façons du SQL et ça me semble logique qu'ils adaptent leur syntaxe pour un SGBD, c'est pour celà que je me demandais s'il n'était pas plus simple d'utiliser ce système là. Mais du coup, il semblerait que ce soit le curseur (ou moteur de curseur, j'ai pas bien rentenu) qui soit plus ou moins spécifique à chaque SGBD, ce qui déplace juste le problème au lieu de le régler.

C'est pour cela que je disais que chaque SGBD implémente un pilote pour que ADO fonctionne. Comme pour les cartes graphique, le pilote d'un SGBD se charge de faire la correspondance entre ce que l'on veut faire et comment on fait avec la mécanique du SGBD.
La première des fonctionnalité à implémenter est bien sûr établir une connexion (et la fermer aussi) mais aussi envoyer une requête SQL, demander à démarrer une transaction et aussi à renvoyer des curseurs donc. Un curseur (je ne sais pas si tu es familier du terme en PL/SQL) c'est tout simplement un objet qui contient les lignes retournées par ta requête et que l'on peut parcourir (en avant, en arrière, premier, dernier, localiser). Tient ça te rappelle rien ? Ha ben c'est ce bon vieux DataSet. Le DataSet en lui-même est une surcouche du curseur quelque part. Quand tu demandes un first il transmet l'instruction first au curseur via le pilote donc.

Dès lors on peut très bien imaginé qu'il est aussi prévu que les pilotes sachent faire les insertion/modification/suppression pour une table sans que les paramètre transmis soit du code SQL. Et c'est ce genre de fonctionnalité des pilotes qui est utilisée par les composant ADOTable par exemple pour transmettre à la base de donnée quand un enregistrement est ajouté, modifié ou supprimé.

Néanmoins pour moi le moyen le plus universellement connu ça reste quand même le SQL en lui-même, même si quelques différences peuvent apparaître, hélas.

[ShaiLeTroll]

Personnellement, j'ai utilisé Borland DataPump pour faire une migration Paradox vers Oracle, alors déjà on commence par des soucis ce type avec les blobs, puis finalement, on se rend compte, que certaines données sont corrompues ...

au final, j'ai fait un programme qui lit les tables paradox et génère du SQL pour remplir ces tables ... avec du SQL bien spécifique à paradox car je dois gérer des Dates ...

Tiens, pour te donner une idée du defi, regarde les produits (leur propre Data Pump) de SQL Manager, tu verras, à quoi tu t'attaques, c'est très interressant, ...

Sinon, des notions de polymorphismes (constructeurs et méthodes virtuelles, référence de classe, ...), cela vous parle, c'est l'une des clés pour écrire un moteur générique pouvant selon la source et la cible utiliser un objet différent ...

tient ce sujet "Retrouver une instance de classe par son nom", je donne quelques idées pour utiliser le polymorphisme ...

[Aka Guymelef]

En effet le polymorphisme est une bonne solution pour s'éviter des if à rallonge. Dès lors le seul et unique if qui existe c'est au début pour créer la classe qui va bien selon la base de donnée source/cible.