niconicochan

Bonjour,

J'essaye ainsi de créer une table en SQL à partir de phpmyadmin:

CREATE TABLE 'inscription' (
nomutilisateur char(10) NOT NULL utf8_general_ci AUTO_INCREMENT PRIMARY KEY,
motdepasse char(8) NOT NULL utf8_general_ci,
firmeouinon text(3) NOT NULL binary utf8_general_ci,
nomfamille text(25) NOT NULL utf8_general_ci,
prenom text(25) NOT NULL utf8_general_ci,
sexe text(5) utf8_general_ci,
age char(3) utf8_general_ci,
adresseemail varchar(35) NOT NULL utf8_general_ci,
numerotelephone varchar(15) utf8_general_ci UNSIGNED,
numeromobile varchar(15) utf8_general_ci UNSIGNED,
numerorue char(3) NOT NULL utf8_general_ci,
nomrue text(100) NOT NULL utf8_general_ci UNSIGNED,
codepostal bigint(15) NOT NULL utf8_general_ci,
ville text(25) NOT NULL utf8_general_ci UNSIGNED,
pays text(25) NOT NULL default'France' utf8_general_ci,
);

On me répond:

#1064 - 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 ''inscription' ( login char(10) NOT NULL utf8_general_ci AUTO_INCREMENT PRIMARY' at line 1

De fait je n'arrive pas à créer ma table.

Quelqu'un peut m'aider?

LupusMic

Attention à la différence sémentique entre les quotes ' et les backquotes (ou backticks) `.

niconicochan

Je viens de trouver la sotuion à tous mes problèmes et c'est alors que je vois ton message...

Je n'ai pas beaucoup de connaissances, encore moins d'expérience mais avec une très bonne idée j'ai pu avancer beaucoup tout d'un coup, et la résolution du premier gros problème a fait boule de neige (cercle vertueux) j'ai ainsi pu régler les autres qui étaient devenus alors mineurs.

J'ai commencé par lire le cours sur CREATE TABLE avec SQL sur le site Lephpfacile et j'ai carrément copié tout le code de la création de table écrite pour l'exemple, je l'ai copié sur phpmyadmin hébergé chez OVH et ça a marché: j'ai créé la table.
Ayant beaucoup moins travaillé sur phpmyadmin en local, je suis allé sur phpmyadmin en local et j'ai fait pareil. J'ai réussi à créé la même table (j'ai ensuite bien sûr supprimé les deux tables).

Ayant la preuve irréfutable que phpmyadmin hébergé comme phpmyadmin en local marchent très bien l'un comme l'autre, il était alors clair que j'avais un problème de code.

J'ai alors fait différentes comparaisons et différents essais sur phpmydmin local entre la table d'exemple
du cours de Lephpfacile et la table que je veux créer.
J'ai ainsi pu analyser tous les problèmes principaux et créer la table que j'avais envie de créer.
donc PROBLEME RESOLU.

Le cours sur Lephpfacile m'aura donc été très efficace.

Je souhaiterais juste te demander, car il y a un point que je n'ai compris sur
aucun des supports d'apprentissage que j'ai vu dans des livres ou sur le net:
l'histoire des octects avec CHAR.
CHAR représente une chaîne de valeur de longueur fixe, mais représente
avant tout le nombre d'octets utilisés pour la valeur saisie par l'utilisateur
dans le formulaire, mais de mon côté, en tant que développeur, comment
associer un nombre d'octets aux caractères tapés par l'utilisateur?
Déjà, est-ce que tous les caractères prennent le même nombre d'octets?
(la lettre M en prend sûrement plus que la lettre N puisque la graphie est plus longue,
je suppose??)
Il faut compter qu'un caractère prend combien d'octets?

niconicochan

Aussi, deuxième question intéressante:

la partie de code TYPE=MyISAM est très bien passée dans phpmyadmin hébergé et elle a empêché la création de la table dans phpmyadmin en local (j'ai donc dû effacer cette partie de code pour créer la table).
Pourquoi?

LupusMic

Ce sont souvent les erreurs les plus bêtes qui nous ralentissent le plus !

En ce qui concerne les caractères, il faut être très prudent quand au vocabulaire qu'on emploi. Les caractères sont codés sur 8 bits dans la table ASCII, qui permet donc de coder 2[sup]8[/sup] - 1 caractères au maximum. Parmi tous ces caractères, le format ASCII réserve quelques plages pour des caractères non-imprimables ou spéciaux (retour à la ligne, tabulations, etc).De plus, à la base, ASCII réserver le premier bit pour permettre de contrôler que le byte a été bien passé. Depuis, ce bit est utilisé et permettre d'utiliser un encodage étendu (ISO8859-1 ou latin1). Mais ce n'est toujours pas suffisant, et certaines langues requièrent un encodage plutôt qu'un autre, pensons aux langues cyrilliques, à l'arabe, au chinois, etc.

Depuis on a inventé unicode et UTF-8 (qui en est un sous-ensemble), dont ASCII a lui-même été fait un sous-ensemble. Unicode permet d'encoder tous les caractères en utilisant un encodage à taille variable. Celui que nous utilisons le plus souvent est un encodage sur un ou deux octets, UTF-8.

Ceci est pour le codage dans un fichier.

Il faut que tu différencie ce codage de la représentation graphique (le glyphe) d'un caractère. Le glyphe est fournit par une font, qui est globalement un catalogue de glyphes pour chaque caractère. Donc non, 'm' ou 'n' n'ont pas une taille différente dans la table de caractère. Par contre, leur glyphe peut éventuellement l'être. Mais ça ne nous intéresse pas quand nous écrivons un caractère dans un fichier, une base de données, etc.

Maintenant, en ce qui concerne char ou varchar, la taille que tu fournis indique combien de caractères tu veux pouvoir insérer dans un champ en base. La taille du caractère en lui-même devrait être géré par la base de données (en fonction de l'encodage et de la collation choisie).

Ces quelques éléments devraient te permettre d'y voir plus clair.

niconicochan

Je te remercie.
C'est exactement les informations qu'il me manquait.

Est-ce que je peux aussi te demander ce qu'on appelle une collation?
J'ai déjà fait une recherche de mon côté mais mis à part le jus d'orange
et les croissants je n'ai rien trouvé.

LupusMic

Ouais, c'est un barbarisme, un anglicisme du plus mauvais goût, mais je n'ai pas de bonne traduction à proposer.

Fais une recherche dans la documentation de MySQL, c'est expliqué en long, en large et en travers. En gros, c'est la spécification de la manière dont les caractères seront triés. L'ordre n'est pas le même selon les langages, et les signes diacritiques viennent avec leur propres règles. En gros, 'e' et 'é' ne peuvent pas être vu comme l'un une variation de l'autre, ils ont un identifiant différent; Et historique, ces nombres ne sont pas contiguës. Donc il faut que MySQL puisse savoir comment trier 'e', 'é', 'è', 'ë' entre 'd' et 'f' par exemple.

niconicochan

Merci pour toutes ces explications.
Elles vont me servir