Mise à jour de GRR 3.00 vers 4.6.6

Bonjour,

Je tente une migration depuis une version 3.0.0a RC1 vers la dernière version en date 4.6.6.
Lors de la restauration de la base .sql j'ai quelques erreurs sur la page de migration.
Dès lors, la page d'accueil reste sur mettre à jour votre base et je me retrouve dans l'impossibilité de continuer, GRR m'affiche qu'il manque une/des tables dans la BDD.
Avez-vous une idée ? La base est peu-être vraiment trop vieille

Mise à jour de la base de donnéesHaut du formulaireATTENTION : Votre base de données ne semble pas être à jour. Numéro de version de la base de données : 3.0.0
Cliquez sur le bouton suivant pour effectuer la mise à jour vers la version 0400011Bas du formulaireRésultat de la mise à jour < GRR 43.0.0 => 3.5.1Mise à jour jusqu'à la version 3.1.0 :
Ok !
Mise à jour jusqu'à la version 3.2.0 :
Ok !
Mise à jour jusqu'à la version 3.3.0 :
Ok !
Mise à jour jusqu'à la version 3.3.1 :
Ok !
Mise à jour jusqu'à la version 3.4.0 :
Erreur sur la requête : INSERT INTO grr_page (`nom`, `valeur`) VALUES ('CGU', 'Les CGU') ON DUPLICATE KEY UPDATE `valeur`='Les CGU'; (1364 : Field 'statutmini' doesn't have a default value)
Mise à jour jusqu'à la version 3.4.1 :
Ok !
Mise à jour jusqu'à la version 3.4.2 :
Ok !
Mise à jour de la table grr_log:
Erreur sur la requête : ALTER TABLE grr_log CHANGE `START` `START` DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00', CHANGE `END` `END` DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00'; (1146 : Table 'grr.grr_log' doesn't exist)
Mise à jour de la table grr_entry_moderate:
Erreur sur la requête : ALTER TABLE grr_log CHANGE `START` `START` DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00', CHANGE `END` `END` DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00'; (1146 : Table 'grr.grr_log' doesn't exist)
Mise à jour jusqu'à la version 3.4.3 RC0:
Erreur sur la requête : ALTER TABLE grr_log CHANGE `START` `START` DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00', CHANGE `END` `END` DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00'; (1146 : Table 'grr.grr_log' doesn't exist)
Erreur sur la requête : ALTER TABLE grr_log CHANGE `REMOTE_ADDR` `REMOTE_ADDR` VARCHAR(40) NOT NULL DEFAULT '' (1146 : Table 'grr.grr_log' doesn't exist)
Mise à jour jusqu'à la version 3.5.0 RC0:

Passage de la base en utf8mb4 COLLATE utf8mb4_unicode_ci
character_set_database est réglé à utf8mb4
Passage de character_set_database à  utf8mb4 COLLATE utf8mb4_unicode_ci
Ok !
Passage des tables en utf8mb4 COLLATE utf8mb4_unicode_ci
Tables déjà encodées en utf8mb4 COLLATE utf8mb4_unicode_ci
Ok !
Mise à jour jusqu'à la version 3.5.1:
Erreur sur la requête : ALTER TABLE grr_log CHANGE LOGIN LOGIN varchar(190) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL default '' (1146 : Table 'grr.grr_log' doesn't exist)Résultat de la mise à jour GRR 4 et +4000 => 0400011Base déjà encodée en utf8mb4 COLLATE utf8mb4_unicode_ci Ok !
Passage de grr_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_area_periodes en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_calendar en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_calendrier_feries en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_calendrier_jours_cycle en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_calendrier_vacances en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_correspondance_statut en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_entry en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_entry_moderate en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_files en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_groupes en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_group_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_group_site en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_mailuser_room en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_site_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_type_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_user_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_user_room en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_user_site en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_useradmin_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_useradmin_site en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_j_userbook_room en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_log_mail en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_log_resa en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_modulesext en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_overload en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_page en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_participants en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_repeat en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_room en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_setting en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_site en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_type_area en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_utilisateurs en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_utilisateurs_demandes en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Passage de grr_utilisateurs_groupes en utf8mb4 COLLATE utf8mb4_unicode_ci en cours. Ok !
Migration terminée : Tables encodées en utf8mb4 COLLATE utf8mb4_unicode_ci
Ok !
Mise à jour jusqu'à la version 4.0.0 :
Erreur sur la requête : ALTER TABLE grr_participants CHANGE IF EXISTS `participant` `beneficiaire` VARCHAR(184) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL (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 'IF EXISTS `participant` `beneficiaire` VARCHAR(184) CHARACTER SET utf8mb4 COLLAT' at line 1)
Mise à jour jusqu'à la version 4.1.0 :
Ok !
Mise à jour jusqu'à la version 4.2.0 :
Ok !
Mise à jour jusqu'à la version 4.3.0 :
Ok !
Mise à jour jusqu'à la version 4.3.7 :
Ok !
Mise à jour jusqu'à la version 4.4.0 :
Ok !
Ok !
Ok !
Ok !
Ok !
Ok !

Bonjour,
pouvez-vous préciser le processus que vous avez suivi pour l'installation et la mise à jour ?
Je note que la table grr_log n'existe pas selon les messages d'erreur : pouvez-vous vérifier ce fait ?
Cordialement,
YN

Bonjour YAN,

Le nouveau GRR a été installé de zéro avec comme seule reprise la liaison LDAP, la base était vierge.
Puis j'ai tenté à la première connexion sur l'appli de faire une restauration de BDD via l'onglet sécurité/connexions.
Je vous confirme que sur l'ancien serveur (un windows sous wamp) la table grr_log est bien existante.

 

Bonjour,
il faudrait vérifier que la table grr_log existe bien avant de lancer la mise à jour de la base de données.
Ensuite, si elle n'existe pas, je doute que la connexion aboutisse.
Ce ne sont que des idées de pistes...
Cordialement,
YN

Bonjour YAN,

C'est assez étrange, après vérification, la base neuve du nouveau 4.6.6 contient bien la table grr_log (avec un ou deux log de connexions) avant la restauration du backup.
L'ancien GRR 3.0.0 dispose également d'une table grr_log avec beaucoup de logs "historiques".
A partir du moment ou la restauration est terminée, la table grr_log n'apparait plus en base

Bonjour,
c'est étonnant, j'en conviens.
Il faudrait analyser le fichier .sql de la sauvegarde et voir s'il ne contient pas une instruction "drop table grr_log" ou équivalent qui n'est pas suivie d'une création et du remplissage de cette table.
Il me semble qu'à une époque la table grr_log n'était pas prise en compte dans les sauvegardes.
Cordialement,
YN

Bonjour YAN,

J'avance doucement ! Désormais la restauration se termine sans erreurs.
Le souci pour la table grr_log provenait de la date qui ne devait pas être nulle. J'ai remis '1970-01-01 00:00:00' dans le fichier .sql comme ce que j'ai pu trouver sur un fichier plus récent.

# Structure de la table grr_log
#
DROP TABLE IF EXISTS `grr_log`;
CREATE TABLE `grr_log` (
  `LOGIN` varchar(40) NOT NULL DEFAULT '',
  `START` datetime NOT NULL DEFAULT '1970-01-01 00:00:00',
  `SESSION_ID` varchar(64) NOT NULL DEFAULT '',
  `REMOTE_ADDR` varchar(16) NOT NULL DEFAULT '',
  `USER_AGENT` varchar(255) NOT NULL DEFAULT '',
  `REFERER` varchar(255) NOT NULL DEFAULT '',
  `AUTOCLOSE` enum('0','1') NOT NULL DEFAULT '0',
  `END` datetime NOT NULL DEFAULT '1970-01-01 00:00:00',
  PRIMARY KEY (`SESSION_ID`,`START`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
#

En revanche, une fois la base restaurée, je n'ai plus du tout accès à la page d'index. Une erreur 500 vient gâcher la fête
Impossible de retrouver la page de connexion via l'url http://x.x.x.x/app.php?p=login ou encore http://x.x.x.x/login.php / http://x.x.x.x/index.html etc
 

Bonjour,
une erreur 500 est une erreur interne au serveur.
Pour en savoir plus, il faudrait regarder, si vous y avez accès, les logs d'erreur de Apache et Php.
Bonne chance,
cordialement,
YN