SQL et ACCESS 2010

Bonjour,
j'ai crée cette requête sur MySQL, PHPMYDAMIN.

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE `Test1` ( `BOOK` TEXT NOT NULL , `TRADEID` INTEGER(4) NOT NULL , `CCY` TEXT NOT NULL , `COMPANY` TEXT NOT NULL , `EXPIRY` BIGINT NOT NULL , `VALUE` BIGINT NOT NULL , PRIMARY KEY ( `BOOK` ) ) ENGINE = MYISAM

---

Cela fonctionne très bien. Ensuite, j'ai tenté de faire cette requête sous Acess2010. Mais il semble qu'Access 2010 n'accepte pas du tout les trucs du type "INTEGER(4)", mais seulement INTEGER. Il n'accepte pas non plus les BIGINT...
Y a t'il beaucoup d'incompatibilités entre SQL sous Access et SQL sous MYSQL?

Car j'ai peur d'avoir d'autres surprises.
Merci

Il arrive en effet que certains types ne soient pas reconnus par certains SGBD... ou que des types existants dans certains SGBD et non conformes à la norme ne soient pas reconnus par d'autres SGBD.

Revenons à votre création de table...
Il est inutile de préciser la longueur du type INTEGER comme l'affiche phpMyAdmin. Un entier est codé sur 4 octets.

Avez-vous vraiment besoin du type TEXT pour les colonnes BOOK et COMPANY ? Un VARCHAR ne serait-il pas suffisant ?

Quoi qu'il en soit, choisir comme clé primaire une colonne de type TEXT est un très mauvais choix ! VARCHAR est un peu mieux mais une bonne clé est de préférence de type entier non null non signé et auto-incrémentée.
Mais là encore il y aura une différence entre MySQL et Access puisqu'on ajoutera l'instruction AUTO_INCREMENT à une colonne de type entier chez MySQL alors qu'on utilisera le type NumAuto chez Access (du moins si ça n'a pas changé, depuis le temps que je n'utilise plus Access).

Posez vous aussi la qeustion de la pertinence du type TEXT pour la colonne CCY, dont le nom ne me dit pas ce qu'elle est censée contenir, et du type BIGINT pour les colonnes EXPIRY et VALUE (un BIGINT, c'est vraiment très grand !)

Plus d'infos sur les types normalisés SQL chez SQLPro.

En fait, j'apprends le SQL avec SQL pour les nuls.
Il semble que SQL donné dans ce livre ne soit pas entièrement compatible avec le SQL implémenté dans Access 2010.