Discussion :

[DMboup]

Bonjour

Le présent sujet vise à produire un outil d'exportation d'une base de données Access vers les SGBD Mysql, PostgreSql, Oracle et Sql Serveur.

Le principe est très simple, il s'agit de la création d'un fichier SQL ayant les instruction CREATE TABLE et INSERT INTO.

L'outil est opérationnel pour Mysql avec toutefois quelque bug que je suis entrain de corriger.

Pour la prise en charge de toutes les SGBD, il me faut la correspondance entre les types Access et ceux des autres SGBD. Je peux trouver et tester pour Mysql et PostgreSql, mais il me faut des testeurs pour Oracle et Sql Serveur (Pour les autres SGBD on verra plus tard !).

Voila le topo.

[DMboup]

Voici la première version de l'outil d'exportation de base de données Access vers les autres base de données MySql, PostgreSql, etc...

L'outil est composé d'un formulaire, de deux modules et d'une table. La table permet d'établir la correspondance entre les types de la base Access et ceux des autres. Je n'ai renseigné que les types pour MySql et une partie pour PostgreSql. Donc les tests peuvent se faire que pour MySql.

Pour tester l'exportation vers PostgreSql, Oracle, et SqlServeur, il faudra remplir la table de correspondance.

L'exportation va créer un fichier .SQL qui sera enregistré dans le même dossier que la base à exporter et portera le même nom.

Pour l'instant la structure des tables ne prend pas en compte les clés primaire et autres identités.

Je signale encore une fois que c'est le premier jet de l'outil, donc en attendant l'intégration des identifiants et clé étrangères, veuillez signaler les erreurs et suggestions à la suite de ce post.

[Arkham46]

je n'ai pas ce qu'il faut pour tester, mais je t'envoie mes encouragements

juste un petit truc : mets plutôt un zip au lieu d'un rar, beaucoup ne peuvent ouvrir ce format

[DMboup]

Bonjour

Outil au format zip envoyé.

[zoom61]

Salut,

Bonne initiative, mais il faudrait la remettre au goût du jour et pouvoir s'en servir avec des fichiers *.accdb, cela fonctionne mais cela convertir du fichier SQL en *.acsql

@+.

[DMboup]

Salut

Oui se sera une bonne chose de le terminer mais on n'est pas tout le temps maître de son emploi du temps.

L'autre soucis c'est que les SGBD ne respect pas tous la norme SQL. Il faut donc presque une syntaxe différente pour chaque cible de BD.

Mon idée de départ était de travaillé avec d'autres sur le projet et d'en faire un outil utile.

[troumad]

Il faudrait peut-être faire de la pub pour un tel outil

[marot_r]

Note qu'il existe déjà des outils qui font cela dans le commerce.

Pour Oracle, sache que les booléans d'Access n'existent pas et qu'autant que je sache les mémos sont limités à 4000 carcatères.

Les relations sont des contraintes (des objets à part entière).

A+

[DMboup]

Il faudrait peut-être faire de la pub pour un tel outil

Si l'outil est vraiment abouti, oui mais il sera simplement publié dans le forum.

Note qu'il existe déjà des outils qui font cela dans le commerce.

C'est justement ce qui m'a motivé à chercher quelque chose propre à Access.

Pour Oracle, sache que les booléans d'Access n'existent pas et qu'autant que je sache les mémos sont limités à 4000 carcatères.

C'est bien mais ce qu'il me faut c'est un tableau de correspondance entre les types de oracle de ceux d'access.

D'autre part si vraiment il faut reprendre le projet, il faudra délimiter un périmètre pas trop large pour avoir des résultats stables et vites. Par exemple s'occuper d'abord d'exporter que les structures des tables avec les données.

[troumad]

Par exemple s'occuper d'abord d'exporter que les structures des tables avec les données.

Exact !
Ceci dit, je ne pense plus en avoir besoin maintenant...

[DMboup]

Exact !
Ceci dit, je ne pense plus en avoir besoin maintenant...

Heureusement que tu as dit maintenant et pas plus jamais. Il y a aussi d'autres utilisateurs qui pourraient en avoir besoin.

C'est d'abord une utilisation personnelle qui m'a obligé à faire cet outil. J'ai ensuite voulu le partager et comme il loin d'être au point la participation de tous ne ferait qu'accélérer les choses.

Par ailleurs le besoin d'exporter une base access vers d'autres SGBD et réel. Même si le projet n'est pas achevé, peut être que les développeurs microsoft de access pourront avoir des idées pour la mise en place d'un outil intégré aux futures versions de Access.

[troumad]

peut être que les développeurs microsoft de access pourront avoir des idées pour la mise en place d'un outil intégré aux futures versions de Access.

Pas un outil pour passer d'un produit MS à un produit libre... À mon avis, s'ils n'en ont pas mis, c'est pour éviter que des utilisateurs de leurs produits se tournent vers autres choses.

Enfin, je suis peut-être mauvaise langue...

[DMboup]

Pas un outil pour passer d'un produit MS à un produit libre... À mon avis, s'ils n'en ont pas mis, c'est pour éviter que des utilisateurs de leurs produits se tournent vers autres choses.

Tout à fait d'accord. J'avais complétement oublié ce coté propio de la chose.

C'est peut être ce qui explique que ce post n'est pas trop d’engouement.

[alassanediakite]

Salut
Belle initiative!!!
J'avais commencer à le faire pour PostgreSQL mais le découragement à gagné la bataille.
Je ne pense pas que ce genre d'outil puisse faire perdre à ACCESS des utilisateurs. Au contraire, on veut passer très souvent a d'autre SGBD tout en gardant ACCESS commen IHM. D'ailleurs ACCESS permet de le faire à travers l'exportation vers des bases ODBC, mais il faut mettre la main à la pâte pour parfaire la chose.
Bon courage!!!

[marot_r]

Je suis d'accord avec alassanediakite, Access a beau être le meilleur plus bon outil :-) de travail, il existe aussi des petites BDs comme Oracle, DB2, MS-SQL Server ou MySQL qui ont quelques vertues valant qu'on leur accorde un regard condécendant :-))).

Ceci dit ce genre d'outils de conversion nécessite une bonne connaissance de Access et un connaissance encore plus intime du SGBD de destination pour réussir à faire le pont entre les deux systèmes et à adapter l'un à l'autre.

C'est clairement un gros effort.

A+

[alassanediakite]

Je suis d'accord avec alassanediakite

en quels points?

Access a beau être le meilleur plus bon outil :-) de travail, il existe aussi des petites BDs comme Oracle, DB2, MS-SQL Server ou MySQL...

j'espère que tu as de bons boucliers antimissiles

Ceci dit ce genre d'outils de conversion nécessite une bonne connaissance de Access et un connaissance encore plus intime du SGBD de destination pour réussir à faire le pont entre les deux systèmes et à adapter l'un à l'autre.

ce n'est pas le cerveau qui manque sur dev.com!!!

C'est clairement un gros effort.

le temps peut manquer.
@+

[DMboup]

Ceci dit ce genre d'outils de conversion nécessite une bonne connaissance de Access

ce soucis est réglé d'autant qu'il ya quelque chose de fonctionnel même si il n'est pas tout à fait au point

et un connaissance encore plus intime du SGBD de destination

Pas nécessairement. Il suffit juste d'avoir la correspondance entre les types de Access et ceux du SGBD de destination. Les types des autres SGBD qui n'ont pas de correspondant ne sont pas concernés.

faire le pont entre les deux systèmes et à adapter l'un à l'autre.

Le sujet de départ est très claire. il n'est pas bi-directionnel. On veut exporter de Access vers -> les autres SBGD et pas l'inverse. De plus c'est juste la définition des tables et les données que l'on exporte.

Si on se limite au périmètre identifié, on peut très bien avoir un outil fiable sans trop problème.

[vodiem]

Salut à tous,

j'ai regardé rapidement.
j'attends impatiemment la version finale qui convertira aussi les formulaires et états dans les navigateurs.
... en plus d'intégrer les contraintes, index, valeurs par défaut, emploi des autoincréments, type d'exportation, jeu de caractère employé... cela va de soi...

j'espère que sharepoint n'éclipsera pas trop ton projet avec l'intégration déjà d'une partie des fonctionnalités d'access dans le navigateur.
tu me diras y a pas que lui sur terre... même si intégrer des tables reste un travail marginal dans le processus de conversion et qu'il existe des solutions pour attaquer le moteur jet dans un navigateur... (parce que si le but de l'exportation est de faire un .exe : autant rester sur access... à mon avis )

sinon p'tite remarque : vu que souvent le sql reste une étape transitoire, pourquoi pas faire simplement une liaison odbc pour réaliser l'exportation ?

comme disait :

le temps peut manquer.

mais tant que la motivation est là, ca ira : donc tous mes encouragements !
ainsi, sache : moi aussi je t'ai à l’œil... ^^

Bonne continuation !

[DMboup]

j'attends impatiemment la version finale qui convertira aussi les formulaires et états dans les navigateurs.
... en plus d'intégrer les contraintes, index, valeurs par défaut, emploi des autoincréments, type d'exportation, jeu de caractère employé... cela va de soi...

Il ne s'agit vraiment pas de ça. Je re-précise le périmètre de l'heure qui reste l'exportation tout simple de la structure des tables et des données dans un simple fichier SQL.

j'espère que sharepoint n'éclipsera pas trop ton projet avec l'intégration déjà d'une partie des fonctionnalités d'access dans le navigateur.
tu me diras y a pas que lui sur terre... même si intégrer des tables reste un travail marginal dans le processus de conversion et qu'il existe des solutions pour attaquer le moteur jet dans un navigateur... (parce que si le but de l'exportation est de faire un .exe : autant rester sur access... à mon avis )

sinon p'tite remarque : vu que souvent le sql reste une étape transitoire, pourquoi pas faire simplement une liaison odbc pour réaliser l'exportation ?

Il ya beaucoup d'outils externes à Access qui proposent des solutions d'exportation de base Access. Quand j'en est eu besoin, j'ai perdu trop de temps en recherche. J'ai donc juste voulu avoir un autre à partir de Access.

Je le met à disposition de tout le monde, mais pour continuer à y travailler (ce qui n'est pas le cas présentement), il faudra que d'autre s'y mettent pour qu'on est un tableau de correspondance complet (cf premier post).

[vodiem]

J'avais tout bien compris chef.