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...
J'ai probablement une piste :)
→
http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-into-cs v-or-mysql-in-linux/
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...
J'ai probablement une piste :)
â
http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-into-cs v-or-mysql-in-linux/
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...
J'ai probablement une piste :)
→
http://nialldonegan.me/2007/03/10/converting-microsoft-access-mdb-into-cs v-or-mysql-in-linux/
> 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!
> 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!
> 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!
Je continue également à chercher via Google
Je continue également à chercher via Google
Je continue également à chercher via Google
-----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
-----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
-----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
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 ?
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 ?
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 ?
Le Fri, 19 Jul 2013 13:25:06 +0200,
Sébastien NOBILI a écrit :
> 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.
Le Fri, 19 Jul 2013 13:25:06 +0200,
Sébastien NOBILI <sebnewsletter@free.fr> a écrit :
> 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.
Le Fri, 19 Jul 2013 13:25:06 +0200,
Sébastien NOBILI a écrit :
> 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.
On Fri, Jul 19, 2013 at 02:11:47PM CEST, Alain Vaugham
said:
> Le Fri, 19 Jul 2013 13:25:06 +0200,
> Sébastien NOBILI a écrit :
>
> > 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.
On Fri, Jul 19, 2013 at 02:11:47PM CEST, Alain Vaugham
<alain@vaugham.com> said:
> Le Fri, 19 Jul 2013 13:25:06 +0200,
> Sébastien NOBILI <sebnewsletter@free.fr> a écrit :
>
> > 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.
On Fri, Jul 19, 2013 at 02:11:47PM CEST, Alain Vaugham
said:
> Le Fri, 19 Jul 2013 13:25:06 +0200,
> Sébastien NOBILI a écrit :
>
> > 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.
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.
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.
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.
On Fri, 19 Jul 2013 14:11:47 +0200
Alain Vaugham wrote:
> 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.
Ça donne qq chose comme ça:
On Fri, 19 Jul 2013 14:11:47 +0200
Alain Vaugham <alain@vaugham.com> wrote:
> 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.
Ãa donne qq chose comme ça:
On Fri, 19 Jul 2013 14:11:47 +0200
Alain Vaugham wrote:
> 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.
Ça donne qq chose comme ça: