Discussion :

[Kephuro]

Bonjour à tous !

Je suis sur une appli qui permet le transfère des données de certains champs d'une table d'une base de données Source, vers les champs d'une table d'une base de données Destination.

Les bases de données Source et Destination sont inconnues avant le lancement de l'application.

Grosso modo j'ai un bouton "Connecter Source" qui me permet de créer une chaine de connexion puis d'établir la connexion à la base Source.
Ensuite je récupère le nom des tables avec TADOConnection.GetTableNames puis je les insère dans une combobox.
En dessous de cette ComboBox j'ai une ListBox qui contient la liste des champs de la table sélectionnée.

J'ai la même chose côté Destination : Un bouton "Connecter Destination" ensuite remplissage d'une combobox avec le nom des tables, puis une ListBox avec le nom des champs de la table sélectionnée.

Le but étant en fait de sélectionner un champ dans la ListBox Source puis un champs dans la ListBox Destination afin de les "lier".
Après avoir établi les liens on peut lancer le transfert.

Le contenu des champs Source est copié vers les champs Destination.

J'ai joint à ce sujet un screen de ce que j'ai actuellement.


En fait j'avais développé ce truc lors d'un stage. L'entreprise avait besoin de transférer un fichier Excel vers une base de données Access et ils n'y connaissaient rien.
Lorsqu'on cliquait sur "Importer" ça générait une requête du genre :

Code :

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

Insert Into maTable IN 'c:\MaBase.mdb' Select Champ1, champ2, champ3 from maTable2

et ça fonctionnait très bien.

Mais j'aurais voulu étendre ce principe et transférer des données simples (texte, valeurs numériques et dates) entre d'autre SGBDR et je me suis aperçu que les syntaxes SQL pouvaient être différentes d'un SGBDR à un autre (notamment lors du transfert de données vers Excel où il faut ajouter des paramètres supplémentaires dans la requête).

Du coup je pense que gérer les connexions et les données serait plus simple avec les composants ADO 'purs', sans l'utilisation de SQL, vu que les composants ADO permettent de faire abstraction du SGBDR.

Le problème c'est que je suis un peu perdu devant le nombre de composants Ado (surtout que j'ai l'impression que certains peuvent faire la même chose que d'autres) et que je ne sais pas trop lesquels choisir.

L'autre souci concerne le type de données que je ne connais pas à l'avance. En effet, je ne sais pas si champ1 va être de type texte ou de type flottant.
Comment pourrais-je gérer ceci ?

La plupart des documentations que j'ai pu trouver sur ADO concernaient leur utilisation avec des composants de type DBGrid, et où les données et leurs types étaient connus à l'avance (dans le cas d'insertions de données).

Je ne sais pas si ma demande a été claire, je cherche quelques pistes (composants, méthodes à appeler...etc...).

Merci d'avance pour vos éclaircissements

[ShaiLeTroll]

Le problème c'est que je suis un peu perdu devant le nombre de composants Ado

Hein ? Les composants ADO, il n'y en a pas beacoup puisque c'est justement une couche d'abstraction vers ODBC pour ADO (je ne parle pas de ADO.NET)

Pour le type de données, voir DataType et DataSize, sinon tenter la conversion des Variants via Value ou AsVariant ...

Enfin, il y a DataPump (celui de Borland problématique avec les Dates ou les Blobs, ou DataPump de SQL Manager) c'est fait pour, et justement il gère la lecture en ADO via API mais l'écriture en spécifique en SQL pour chaque moteur connu ... pour ma part c'est ce que j'ai fait pour mon convertisseur Paradox vers Oracle, toutes les différences SQL sont stockés dans une sorte de base de connaissance, et selon la DB il va chercher la bonne chaine de formattage (en fait, à part les dates ...)

[Franck SORIANO]

...
Du coup je pense que gérer les connexions et les données serait plus simple avec les composants ADO 'purs', sans l'utilisation de SQL, vu que les composants ADO permettent de faire abstraction du SGBDR.

Le problème c'est que je suis un peu perdu devant le nombre de composants Ado (surtout que j'ai l'impression que certains peuvent faire la même chose que d'autres) et que je ne sais pas trop lesquels choisir.

Et oui, en réalité dans ADO il y a trois composants principaux : Un objet Connection pour la connexion à la source de données, un objet Command pour exécuter des requêtes et un objet recordset pour manipuler des jeux de données.

Les composants ADO de Delphi encapsulent ces composants de base pour coller au mieux à l'architecture DB qui était proposées avec le BDE.
Donc tu te retrouve avec une série de composants qui se ressemblent parfois beaucoup parce qu'ils se ramènent tous aux trois mêmes composants de base.

Avec les composants dbGO de Delphi, tu as :
- TADOConnection : Pour gérer la connexion à la base.
- TADOCommand : encapsule l'objet Command d'ADO pour exécuter des requêtes. C'est le composant de base pour utiliser du SQL.
- TADOQuery : C'est un TADOCommand adapté pour le faire ressembler au composant TQuery du BDE. Si tu n'as pas de problématique de portage depuis le BDE, tu peux l'oublier.
- TADOStoredProc : Idem, C'est un TADOCommand adapté pour appeler une procédure stockée.
- TADODataSet : C'est le composant de base pour manipuler un jeu de données (résultat d'une requête, table...).
- TADOTable : C'est un composant TADODataSet adapté pour le faire ressembler au composant TTable du BDE.

Pour faire ce que tu veux, c'est à dire travailler directement sur les tables, sans avoir a écrire une ligne de requête SQL, je te conseille d'utiliser le composant TADOTable.
Tu auras juste besoin de relier le composant à la connexion et de définir le nom de la table à manipuler.

Cependant pour ce genre de problème (copie massif de données d'une source, vers une autre) je préfère faire une lecture générique (genre ADO (voir BDE pour Paradox)) et faire les insertions de façon spécifique en utilisant les API de Bulkload de chaque SGBD. Ca va beaucoup, beaucoup plus vite à l'exécution...

[Kephuro]

Merci beaucoup pour vos réponses. Je sais maintenant vers quoi m'orienter