Bonjour

J'ai passé Joomla de 3.6.3 à 3.6.5 : un alter de table a échoué (un Alter d'une table %feedsnews) que j'ai effectué manuellement ensuite.
J'ai ensuite passé ICagenda en 3.6.6 et là encore un problème de SQL. J'ai malheureusemenr perdu la page avec le message d'erreur exact. Le message d'erreur faisait référence à une table LOCK impossible à écrire. Le verrou induit la notion de transaction et je suppose que d'autres ordres SQL de mise à jour n'ont pas pu être effectués.

Le problème est le suivant : je ne connais pas les SQL qui ont échoué et ICagenda est considéré à jour alors qu'il ne peut pas l'être.

J'envisage 2 solutions :
Il est possible de ne rattraper que les SQL et vous me dites où les trouver.
il est possible de repasser l'upgrade comme un sauvage, sans risque. C'est plus bestial et c'est plus simple.

Vos conseils éclairés sont les bienvenus. Merci de l'attention portée à mon message.

Je ne m'explique pas pourquoi mais mon user propriétaire du schéma Joomla n'avait aucun privilege alors qu'il avait été créé par un Kickstart Akeeba Backup d'une autre machine où ce même user avait les droits..

Voilà pourquoi les SQL de mise à jour ne passent pas sans doute.

Bon ,c'est une explication de mon problème, c'est bien. Une résolution, ce serait mieux...

Merci de votre réponse.

Je crois avoir l'explication du problème. En attendant, un conseil, une réponse sur ce forum, j'ai bidouillé légèrement mon site et surprise je ne pouvais même pas faire de mise à jour, style ajouter un évènement. J'ai investigué et j'ai découvert que mon schéma database n'avait aucun privilege sur les tables. Et en voulant affecter ces privileges, j'ai constaté que, sur mySQL, le statement "grant all privileges on <my_db>.* to <my_user> ; " fonctionne, ne retourne pas d'erreur et indique "0 rows affected". Bref, il a l'air de fonctionner mais ne fonctionne pas !

L'explication de ce user SANS privileges est la suivante :
1° J'ai développé mon site sur un PC
2° J'ai installé un serveur Raspberry Pi et créé manuellement la database. Le "grant all privileges" a dû être aussi inefficace.
3° Par Akenna Backup+kickstart, j'ai installé mon site sur ce serveur
Et depuis les mises à jour SQL échouent sur ce site.

Depuis, j'ai pu affecter les droits par phpmyadmin, j'ai pu restaurer et je recommencerai les mises à jour la semaine prochaine.

Il me semblait avoir été assez clair dans mon explication. Oui.
Une fois les privilèges correctement affectés à mon user database, j'ai restauré la sauvegarde AkeenaBackup d'avant la montée de version !Cagenda pour faire régresser mon site, Puis j'ai repassé l'update !Cagenda et cette fois il n'y a eu aucune erreur SQL.

Je pensais également que l'icône "coche verte" signifiait que le post était résolu mais visiblement, non. J'édite donc le titre du post en Résolu.

Conclusion n°1 : Les mises à jour !Cagenda fonctionnent bien (ce dont je doutais (forcément))
Conclusion n°2 : Le "grant all privileges on <schema>.* to <schema> ; " de mySQL ne fonctionne pas ! (Dans les tutos Raspbian, on ne trouve pas ce que j'ai fait : {1° create schema, 2°grant} mais une création implicite au grant par : grant ...identified by <password>;}