Bonjour,
 
tout est presque dans le texte. Plus d'info :
Access 2003 sp3
MySQL Server 5.5
 MySQL ODBC 5.1
 j'utilise "MS Access to MySQL" 2.0.0.64
 
et voila le message que j'obtiens (idem pour toutes les tables et quelque soit le type choisi : InnoD ou MyIsam)
TABLES
------------
- Creating 'Log' failed
- SQL: CREATE TABLE `Log` (  `Numero` INTEGER AUTO_INCREMENT,   `Date_Operation` VARCHAR(255),   `Objet` VARCHAR(255),   `Libelle` VARCHAR(255),   INDEX (`Numero`)) TYPE=InnoDB
- Error: -2147217900 (80040E14) [MySQL][ODBC 5.1 Driver][mysqld-5.5.12]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=InnoDB' at line 1
- 0 records moved
 
merci de vos réponses

 
Up Up ....
 
La solution que j'ai trouvée à ce pb est de supprimer TYPE=InnoDB
 
Par contre je rencontre bon nombre d'erreurs dues à des caractères spéciaux qu'Access traitait sans pb et qui font planter le processus de conversion.
par exemple :
INSERT INTO `Contacts` VALUES ('2007/01/01', 'C', 'Autre', 'IDD', 'IDD Biotech', 'VERMOT – DESROCHES', 4799) provoque l'erreur :
Error Code: 1366
Incorrect string value: '\xC2\x96 DES...' for column 'Nom' at row 1
 
ce qui correspond à la non reconnaissance du tiret (sans doute un caractère spécial) entre VERMONT et DEROCHES :
 
 VERMOT – DESROCHES (copie coller depuis Access)
 
 
 Je me vois contraint de plonger dans les Character_Set sans être certain que tout vienne de là :
character_set_client            | latin1                      |
| character_set_connection        | latin1                      |
| character_set_database          | latin1                      |
| character_set_filesystem        | binary                      |
| character_set_results           | latin1                      |
| character_set_server            | latin1                      |
| character_set_system            | utf8                        |
| character_sets_dir              | /usr/share/mysql/charsets/  |
| collation_connection            | latin1_swedish_ci           |
| collation_database              | latin1_swedish_ci           |
| collation_server                | latin1_swedish_ci            
 
....C'est scandaleusement incompréhensible, il suffit de voir les milliers de pages web sur le sujet et dans toutes les langues.
 
Si une âme charitable (ou pas!) pouvait m'indiquer la procédure à suivre pour migrer de Access vers MySQL sans toutes ces erreurs je lui en serais (presque) éternellement reconnaissant !
 
pour info la base sera ensuite utilisée en VBA / Excel
 

Il me semble que les conversion Access -> SQL Server sont plus facil que vers MySQL.
Si tu ne t'en sors vraiment pas avec MySQL tu pourrais toujours essayer SQL Server et voir si ca passe mieux (SQL Server Express est gratuit).
 
Il n'y a pas de facon magique de migrer depuis access, c'est soit un outils que tu ecris toi meme, soit les outils de conversion existant.
Dans les deux cas il faut s'y connaitre pas mal en Access et en MySQL.

 
Merci du conseil, je suis quand même effaré par les difficultés que rencontrent les développeurs web avec PHP/MySQL.  
 
J'en viens à me demander si les développeurs de logiciels "Open Source" ont toujours présent à l'esprit la facilité de migration et d'utilisation de leur produits qui sont par ailleurs remarquables.

J'ai eu un problème assez similaire récemment.  
 
Essaye de remplacer "TYPE=InnoDB" par "ENGINE=InnoDB"

Effectivement c'est le mot clé "Type" qui ne lui plait pas !

Si "MS Access to MySQL" 2.0.0.64" cree un fichier sql ,  essay de sauvegarder le fichier en UTF-8 avant de lancer
( voir aussi s'il y des options (i.e parameter/switch) avec "MS Access to MySQL" ...en tout cas je le connais pas!   )

 
 
Le pb est qu'il n'y a pas d'option de sauvegarde pour le format de caractères, peut-être faut-il rajouter en tête du fichier .sql une clause pour indiquer le charset à utiliser pour le rechargement.
Néanmoins j'ai peur qu'ensuite :
1- je rencontre encore des problèmes quand le programme VBA ira stocker et relire des infos avec des caractères spéciaux, d'autant plus que certaines zones de texte sont remplies par des copier/coller qui viennent de diverses sources
2 - qu'un paramétrage (par exemple des drivers ODBC) soit nécessaire sur les postes clients, ce qui compliquerait le déploiement et la maintenance (c'est une petite PME avec 3 ou 4 de postes concernés mais qui vont monter à une bonne dizaine voire plus).
 
Mais merci du conseil, je vais essayer d'aller jusqu'au bout pour mieux maitriser ces pb,  même si ensuite je ne passe pas à la mise en œuvre.