Discussion :

[stdek]

Bonjour.
Je suis débutant et je dois alimenter les tables d'un forum phpbb à partir de celles d'un forum invision.
J'ai installé xampp en local sur mon pc.
J'ai les deux bdd (toutes deux mariadb). L'une est vide (celle phpbb) et l'autre avec les données du forum invision.
J'ai choisi de commencer par la table des users. Pour commencer doucement j'ai créé une petite base de données (migration) avec 2 tables pour faire un test.
Table des users en entrée :
Nom : ibf_core_members
2 colonnes : member_id mediumint(9) et name varchar(255)
Table des users en sortie :
Nom : cor_users
3 colonnes : member_id mediumint(9), user_id int(10) et name varchar(255)
Ensuite j'ai écrit un petit script SQL (fichier recup_users.sql) dont voici le contenu :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
FOR EACH ROW member_id IN migration.ibf_core_members
BEGIN
     INSERT INTO migration.cor_users
                         migration.cor_users.member_id = migration.ibf_core_members.member_id
                         migration.cor_users.user_id = migration.ibf_core_members.member_id + 49
                         migration.cor_users.name = migration.ibf_core_members.name;
END;

Ensuite je lance le shell dans xampp control panel, je me connecte à sql en tapant "mysql -u root -p" , je fais entrée sur la demande de password et j'ai le prompt "MariaDB [(none)] >". Je tape "source (chemin accès):recup_user.sql
Et j'ai ce message:

ERROR 1064 (42000) at line 1 in file: 'c:\xampp\recup_users.sql': You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'EACH ROW member_id IN migration.ibf_core_members
begin
insert into migra...' at line 1
ERROR 1064 (42000) at line 7 in file: 'c:\xampp\recup_users.sql': You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'END' at line 1

Pouvez-vous m'éclairer ? D'avance merci et bonne journée.

[escartefigue]

Bonjour,

Quelques remarques

Sur la forme : il faut à encadrer votre code en utilisant les balises CODE (bouton # de la barre d'icones) ça active la coloration syntaxique et facilite la lecture.
Là j'ai édité votre message pour les ajouter, mais pensez-y la prochaine fois

Sur le fond :

• la syntaxe de l'ordre INSERT n'est pas bonne, parmi les syntaxe possibles :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  insert into ma_table
        (col1, col2, …, coln)
  values (val1, val2,..., valn)
   
  insert into ma_table
        (col1, col2, …, coln)
  select cola, colb, …, colz
  from autre_table
  where [...]

  voyez les tuto SQL dans le forum langage SQL par exemple ICI
• je suppose que vous incrémentez la valeur de l'identifiant de 49 parcequ'il y a 49 personnes dans la table, mais il est préférable de définir l'identifiant avec la propriété "auto_increment" et de laisser le SGBD attribuer la valeur
• le nombre entre parenthèses après le type integer ou mediumint n'a plus d'intérêt, il servait à dimensionner l'affichage dans les anciennes versions de MySQL
• également, avant d'insérer les personnes dans la base cible, il serait sage de s'assurer qu'il n'existe pas de doublons fonctionnels dans la source. Pour ce besoin, un nom seul ne suffit pas (les "Jacques Martin" par exemple sont nombreux en France ), vous aurez besoin de valeurs plus discriminantes telles que le NIR par exemple, le plus souvent en combinaison avec d'autres colonnes (nom + prénom + NIR, + date de naissance...)
  Car si le NIR est en thérorie unique (une personne <-> un NIR) ce n'est dans les faits pas toujours le cas, non seulement à cause des personnes immatriculées à l'étranger (numéro CAFAT, Monaco, Lunaire...) mais aussi, dans certains S.I., les enfants rattachés au NIR du père ou de la mère.

[stdek]

Merci pour toutes vos précisions.
En regardant la documentation SQL MariaDB je me suis aperçu que le FOR EACH ROW n'était pas supporté. Je me dirige donc vers l'utilisation de CURSOR et FETCH. En cas de problème je solliciterais certainement votre aide.
Encore merci.
Je vais essayer de fermer ce post.

[escartefigue]

Utiliser un curseur pour traiter ligne à ligne toutes les lignes est une très mauvaise solution.
Il n'y a aucune raison de passer par un curseur dans votre cas, utilisez plutôt la deuxième syntaxe que j'ai proposée : INSERT qui s'appuie sur un SELECT, ce sera beaucoup plus rapide.

[stdek]

Bonjour et merci Escartefigue.

J'ai fait comme tu m'as conseillé et ça marche très bien.
Maintenant je dois régler un autre problème. Dans la table ou je fais les INSERT, la première colonne est déclarée en AUTO_INCREMENT (dans mon test je ne l'ai pas fait mais maintenant je dois le faire).
Actuellement la requête SQL est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

INSERT INTO `users` (`member_id`, `user_id`, `name`) SELECT `member`, `user`, `nom` FROM `members`;

Donc je vais passer la colonne 'member_id' en AUTO_INCREMENT. Est-ce que je dois modifier le code et ne plus insérer la colonne 'member_id' car je crois comprendre qu'elle va se générer toute seule ? Et donc dois-je supprimer la colonne 'member' dans la table du SELECT ?

Je suis retraité et j'avoue que j'étais plus habité a travailler avec des fichiers en séquentiel indexé (d'où mon approche CURSOR et FETCH). Tout cela est très nouveau pour moi et même si les cours et tutos sont très bien fait, les subtilités ne sont pas toujours bien expliquées (exemple du AUTO_INCREMENT).

En attendant, c'est très gentil à vous de prendre le temps de me lire et de me répondre.

[escartefigue]

En effet, quand une colonne est calculée par le SGBD, il est préférable de ne pas la mentionner dans l'ordre INSERT de sorte à ce que le SGBD en attribue la valeur, c'est plus simple, et comme c'est un identifiant technique, on se fiche d'en maîtriser le contenu, ce qui compte c'est de garantir l'unicité.

Il faut juste avoir à l'esprit que ce type de colonnes prend des valeurs qui ne sont pas obligatoirement contigües et qui ne sont pas non plus toujours chronologiques.
On peut très bien avoir les valeurs suivantes insérées dans cet ordre : 1, 2, 3, 6, 8, 9, 10, 7, 11, etc.
Les "trous" de numérotation sont fréquents, il ne faut pas s'en formaliser, on s'en cogne

La séquence n'est pas toujours dans l'ordre chronologique, c'est dû à plusieurs phénomènes : d'une part la distribution des identifiants par paquets, d'autre part le multi-threading, et plus marginalement, du forçage d'une valeur précise lors de l'insertion, ce qui reste toujours possible sous réserve que la valeur communiquée respecte la contrainte d'unicité bien entendu .
Là non plus il ne faut pas s'en formaliser, si l'on a besoin de connaitre la chronologie de création alors il faut ajouter une colonne d'horodatage fin dans la table, par exemple un timestamp, mais surtout pas utiliser ces identifiants.
Note : en environnement peu concurrentiel, style plate-forme de test unitaire, les identifiants sont souvent insérés dans l'ordre chronologique, mais comme indiqué plus haut, ce n'est jamais garanti.