Forums Linux Autres OS Linux Debian

Script Bash pour convertir BD Access vers MySQL ?

Le
Serge SMEESTERS
Salut à tous,


Je viens de passer une petite demi-heure sur le Google mais déjà,
je trouve pas les bons mots clés à taper En gros, j'ai l'impression
que c'est pas évident à trouver comme ça :( Donc excusez-moi si je
viens poser ici une question peut-être toute bête.

J'aimerais me débarrasser de l'usage d'Access de Microsoft et le
remplacer par l'usage d'une application web php/mysql.

Le fichier Access se trouve sur un serveur Debian Squeeze sur lequel
est également installé MySQL, PHP et Apache ce fichier Access est
partagé via Samba et utilisé à partir d'un poste Windows 7/MS Office
2010.

Pour le développement de l'application web (PHP) et la transition,
j'aimerais avoir un script bash à exécuter pour (re-)faire une BD
MySQL à partir du fichier Access.

Existe-t-il un tel outil ?

J'imagine qu'il est possible d'exporter la bd à partir d'Access, en un
code SQL (moche ?) ; code qu'il serait possible de bidouiller pour
l'exécuter ensuite par MySQL Mais ce serait de nombreuses
manipulations "manuelles" ; et je préférerais un petit script facile =
à
exécuter et qui ferait tout ce qui faut automatiquement

Merci d'avance pour votre aide

Je continue également à chercher via Google


À+,
Serge S.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAFeEpGCbZxtBErmSGCT3sK2Hz=+b+prg7V1DVVAvitBMVYJ7Xg@mail.gmail.com
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Serge SMEESTERS
Le #25552362
J'ai probablement une piste :)

→ http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb -into-csv-or-mysql-in-linux/

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CAFeEpGDM-hnEyoYXozÙ
Répondre en citant
Alain Vaugham
Le #25552432
Le Fri, 19 Jul 2013 12:18:57 +0200,
Serge SMEESTERS
J'imagine qu'il est possible d'exporter la bd à partir d'Access, en un
code SQL (moche ?) ; code qu'il serait possible de bidouiller pour
l'exécuter ensuite par MySQL... Mais ce serait de nombreuses
manipulations "manuelles" ; et je préférerais un petit script f acile à
exécuter et qui ferait tout ce qui faut automatiquement...



Je suis dans la même démarche mais vers Postgres.


J'ai probablement une piste :)

→
http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-into-cs v-or-mysql-in-linux/





Mon expérience : les formats des champs Access ne sont pas forcém ent
identiques à ceux de Postgres. Donc il me faut tous les reformater à   la
main pour les mettre au format Postgres.

S'il existe un script qui sait deviner comment transformer les formats
de la source vers le format de la cible alors je suis preneur aussi!


--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
S
Le #25552482
Le vendredi 19 juillet 2013 à 12:41, Alain Vaugham a écrit :
> J'ai probablement une piste :)
>
> →
> http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-into-csv-or-mysql-in-linux/

Mon expérience : les formats des champs Access ne sont pas forcément
identiques à ceux de Postgres. Donc il me faut tous les reformater à la
main pour les mettre au format Postgres.

S'il existe un script qui sait deviner comment transformer les formats
de la source vers le format de la cible alors je suis preneur aussi!



Qu'entends-tu par « les formats des champs Access ne sont pas forcément
identiques à ceux de Postgres » ? Tu pourrais donner un exemple ?

S'il s'agit simplement de traduire des termes dans un fichier texte (export
SQL), sed et awk le feront très bien.

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Fabian Rodriguez
Le #25552522
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-07-19 06:18, Serge SMEESTERS wrote:
Je continue également à chercher via Google



"migrating access database to mysql"

J'utilise https://www.ixquick.com/ pour mes recherches:
https://fr.wikipedia.org/wiki/Ixquick

A+

F.



- --
Fabián Rodríguez
http://debian.magicfab.ca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: PGP/Mime available upon request
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHpKUMACgkQfUcTXFrypNV0YQCgzxQlptUjQFvg0MTAhDV13+GS
+3AAnihJhM5EHyvjoV2z/2Ym6Fpmbx5s
=r/3u
-----END PGP SIGNATURE-----

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Jean-Jacques Doti
Le #25552582
Bonjour,

Le 19/07/2013 13:55, Fabian Rodriguez a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-07-19 06:18, Serge SMEESTERS wrote:
Je continue également à chercher via Google


"migrating access database to mysql"

J'utilise https://www.ixquick.com/ pour mes recherches:
https://fr.wikipedia.org/wiki/Ixquick



Est-ce que l'utilisation des mdbtools (présents dans Debian) ne ferait
pas l'affaire ?
Il y a un utilitaire, mdb-schema, qui permet l'export de DDL dans le
dialecte SQL désiré (access, mysql, postgresql, oracle, …) et mdb-export
devrait savoir faire de même pour les données.

A+
Jean-Jacques

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Alain Vaugham
Le #25552632
Le Fri, 19 Jul 2013 13:25:06 +0200,
Sébastien NOBILI
Le vendredi 19 juillet 2013 à 12:41, Alain Vaugham a écrit :
> > J'ai probablement une piste :)
> >
> > →
> > http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-int o-csv-or-mysql-in-linux/
>
> Mon expérience : les formats des champs Access ne sont pas forcà ©ment
> identiques à ceux de Postgres. Donc il me faut tous les reformater
> à la main pour les mettre au format Postgres.
>
> S'il existe un script qui sait deviner comment transformer les
> formats de la source vers le format de la cible alors je suis
> preneur aussi!

Qu'entends-tu par « les formats des champs Access ne sont pas
forcément identiques à ceux de Postgres » ? Tu pourra is donner un
exemple ?



Super : c'est vendredi!
Cependant, je ne voudrai pas voler le post initial...

Voici l'exemple pour lequel je n'ai pas encore trouvé de solution
rapide et simple :
Access dispose d'un champ de type NuméroAuto qui accepte par défa ut un
entier long, soit incrémental, soit aléatoire.
L'intérêt de ce type de champ c'est que si une ligne de la table est
détruite, le contenu de ce champ est "brûlé". Il n'est donc plus
possible de le réutiliser dans une nouvelle ligne.
C'est l'usage type d'une traçabilité de numéros de séri e. Un numéro de
série est sensé être unique. Si un produit est détruit, son numéro de
série ne doit plus être réutilisatable.
Bon, d'accord on pourrait trouver une autre solution que l'usage du
NuméroAuto en ajoutant une colonne pour indiquer l'état du numà ©ro de
série... mais dans mon cas, je me contente de détruire la ligne du
numéro de série dont le produit a été mis au rebus.

Extraire toutes les lignes de ce champ pour les mettre dans un fichier
csv et les importer dans Postgres ne pose aucun problème. Là n'es t pas
la question.
Par contre je n'ai pas trouvé dans Postgres l'équivalent d'un for mat de
champ qui corresponde au format NuméroAuto d'Access. Dans Postgres, le
format serial UNIQUE NOT NULL ne tient pas compte des numéro brûl és.

Donc pour migrer une telle colonne je n'ai pas de solution qui soit
automatique.



--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Erwan David
Le #25552622
On Fri, Jul 19, 2013 at 02:11:47PM CEST, Alain Vaugham
Le Fri, 19 Jul 2013 13:25:06 +0200,
Sébastien NOBILI
> Le vendredi 19 juillet 2013 à 12:41, Alain Vaugham a écrit :
> > > J'ai probablement une piste :)
> > >
> > > →
> > > http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-into-csv-or-mysql-in-linux/
> >
> > Mon expérience : les formats des champs Access ne sont pas forcément
> > identiques à ceux de Postgres. Donc il me faut tous les reformater
> > à la main pour les mettre au format Postgres.
> >
> > S'il existe un script qui sait deviner comment transformer les
> > formats de la source vers le format de la cible alors je suis
> > preneur aussi!
>
> Qu'entends-tu par « les formats des champs Access ne sont pas
> forcément identiques à ceux de Postgres » ? Tu pourrais donner un
> exemple ?

Super : c'est vendredi!
Cependant, je ne voudrai pas voler le post initial...

Voici l'exemple pour lequel je n'ai pas encore trouvé de solution
rapide et simple :
Access dispose d'un champ de type NuméroAuto qui accepte par défaut un
entier long, soit incrémental, soit aléatoire.
L'intérêt de ce type de champ c'est que si une ligne de la table est
détruite, le contenu de ce champ est "brûlé". Il n'est donc plus
possible de le réutiliser dans une nouvelle ligne.
C'est l'usage type d'une traçabilité de numéros de série. Un numéro de
série est sensé être unique. Si un produit est détruit, son numéro de
série ne doit plus être réutilisatable.
Bon, d'accord on pourrait trouver une autre solution que l'usage du
NuméroAuto en ajoutant une colonne pour indiquer l'état du numéro de
série... mais dans mon cas, je me contente de détruire la ligne du
numéro de série dont le produit a été mis au rebus.

Extraire toutes les lignes de ce champ pour les mettre dans un fichier
csv et les importer dans Postgres ne pose aucun problème. Là n'est pas
la question.
Par contre je n'ai pas trouvé dans Postgres l'équivalent d'un format de
champ qui corresponde au format NuméroAuto d'Access. Dans Postgres, le
format serial UNIQUE NOT NULL ne tient pas compte des numéro brûlés.

Donc pour migrer une telle colonne je n'ai pas de solution qui soit
automatique.



En SQL on fait ça avec une séquence.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Alain Vaugham
Le #25552612
Le Fri, 19 Jul 2013 14:19:13 +0200,
Erwan David
On Fri, Jul 19, 2013 at 02:11:47PM CEST, Alain Vaugham
> Le Fri, 19 Jul 2013 13:25:06 +0200,
> Sébastien NOBILI >
> > Le vendredi 19 juillet 2013 à 12:41, Alain Vaugham a écrit :
> > > > J'ai probablement une piste :)
> > > >
> > > > →
> > > > http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb -into-csv-or-mysql-in-linux/
> > >
> > > Mon expérience : les formats des champs Access ne sont pas
> > > forcément identiques à ceux de Postgres. Donc il me faut tous
> > > les reformater à la main pour les mettre au format Postgres.
> > >
> > > S'il existe un script qui sait deviner comment transformer les
> > > formats de la source vers le format de la cible alors je suis
> > > preneur aussi!
> >
> > Qu'entends-tu par « les formats des champs Access ne sont p as
> > forcément identiques à ceux de Postgres » ? Tu po urrais donner un
> > exemple ?
>
> Super : c'est vendredi!
> Cependant, je ne voudrai pas voler le post initial...
>
> Voici l'exemple pour lequel je n'ai pas encore trouvé de solution
> rapide et simple :
> Access dispose d'un champ de type NuméroAuto qui accepte par dà ©faut
> un entier long, soit incrémental, soit aléatoire.
> L'intérêt de ce type de champ c'est que si une ligne de la ta ble est
> détruite, le contenu de ce champ est "brûlé". Il n'est d onc plus
> possible de le réutiliser dans une nouvelle ligne.
> C'est l'usage type d'une traçabilité de numéros de sà ©rie. Un numéro
> de série est sensé être unique. Si un produit est dà ©truit, son
> numéro de série ne doit plus être réutilisatable.
> Bon, d'accord on pourrait trouver une autre solution que l'usage du
> NuméroAuto en ajoutant une colonne pour indiquer l'état du nu méro de
> série... mais dans mon cas, je me contente de détruire la lig ne du
> numéro de série dont le produit a été mis au rebus.
>
> Extraire toutes les lignes de ce champ pour les mettre dans un
> fichier csv et les importer dans Postgres ne pose aucun problème.
> Là n'est pas la question.
> Par contre je n'ai pas trouvé dans Postgres l'équivalent d'un
> format de champ qui corresponde au format NuméroAuto d'Access. Dans
> Postgres, le format serial UNIQUE NOT NULL ne tient pas compte des
> numéro brûlés.
>
> Donc pour migrer une telle colonne je n'ai pas de solution qui soit
> automatique.

En SQL on fait ça avec une séquence.




Ce n'est pas suffisant.
Malheureusement, une séquence seule autorise l'usage des "numéros
brûlés".




--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Bzzz
Le #25552702
On Fri, 19 Jul 2013 14:11:47 +0200
Alain Vaugham
Par contre je n'ai pas trouvé dans Postgres l'équivalent d'un
format de champ qui corresponde au format NuméroAuto d'Access.
Dans Postgres, le format serial UNIQUE NOT NULL ne tient pas
compte des numéro brûlés.



Pourquoi utiliser un 'serial' (ne serais-ce déjà, parce que certa ins
S/N comportent des lettres)?

Par ailleurs, tu confonds 'brûlé' (mauvaise habitude donnée par
qq chose qui n'est même pas l'ombre d'un RDBMS) et non-réutilisab le;
si ton article est vendu, il suffit d'un flag pour l'indiquer (c'est
en Gal la présence d'un lien vers la facture) et donner à son S/N
la caractéristique 'UNIQUE NOT NULL' suffit à créer un index
interdisant la réutilisation dudit S/N par unicité.

Et peu importe que le lien article-S/N soit existant ou non, le
simple
fait de renseigner un S/N le rend indisponible à toute réutilisat ion.

Ça donne qq chose comme ça:

table sn (
id serial not null primary key,
sn varchar(128) not null UNIQUE)

table article (
id bigserial not null primary key,
bla, bla…)

table article_sn (
ida int4 not null references article(id),
ids int8 not null references sn(id))

et pour retrouver ses petits (et savoir si l'article est en stock ou
vendu):

table facture_sn (
idf int4 not null references facture(id),
ids int8 not null references sn(id))

--
1PFmiss : c’était quoi le problème d'internet de ta mà ¨re ?
Jiraya09 : ma mère...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Alain Vaugham
Le #25552762
Le Fri, 19 Jul 2013 14:37:40 +0200,
Bzzz
On Fri, 19 Jul 2013 14:11:47 +0200
Alain Vaugham
> Par contre je n'ai pas trouvé dans Postgres l'équivalent d'un
> format de champ qui corresponde au format NuméroAuto d'Access.
> Dans Postgres, le format serial UNIQUE NOT NULL ne tient pas
> compte des numéro brûlés.

Pourquoi utiliser un 'serial' (ne serais-ce déjà, parce que cer tains
S/N comportent des lettres)?

Par ailleurs, tu confonds 'brûlé' (mauvaise habitude donné e par
qq chose qui n'est même pas l'ombre d'un RDBMS) et non-réutilis able;
si ton article est vendu, il suffit d'un flag pour l'indiquer (c'est
en Gal la présence d'un lien vers la facture) et donner à son S /N
la caractéristique 'UNIQUE NOT NULL' suffit à créer un ind ex
interdisant la réutilisation dudit S/N par unicité.

Et peu importe que le lien article-S/N soit existant ou non, le
simple
fait de renseigner un S/N le rend indisponible à toute réutilis ation.




Bien vu : La structure et l'usage initial de la bdd n'était pas au top.
Résultat : Pour migrer cette base Accces vers Postgres il faut la
reconcevoir.
C'est à mon avis ce qui risque souvent d'arriver lors d'une migration.

Donc pour en revenir au post initial de Serge, je doute qu'on puisse
trouver le script qui va bien même avec MySQL...




Ça donne qq chose comme ça:




[...]

Merci beaucoup pour ton exemple.


--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Poster une réponse
Anonyme