Migration 7.3 : "Aucun titre n'a été trouvé."

benoit.reyt@free.fr · novembre 2019

Bonjour,

Depuis que j'ai mis à jour PMB en version 7.3RC (mais peut-être est-ce une coïncidence), toutes mes recherches dans l'onglet Catalogue renvoient l'erreur : "Aucun titre n'a été trouvé".

Même si je n'utilise PMB que pour ma bibliothèque personnelle, c'est un peu handicapant. Quand j'ai besoin d'ajouter une notice dans une série par exemple, j'ai l'habitude de dupliquer la notice du précédent tome ; là, il faut que j'aille chercher la notice précédente en passant par l'onglet Autorités, je cherche l'auteur, j'affiche les notices dans lesquelles il apparaît... c'est beaucoup plus long

J'ai lu cette conversation : https://pmb.community/forum/discussion/351/base-de-donnees-erronees/p1 et j'ai ré-indexé la base MariaDB, mais le problème persiste.

J'ai regardé dans les logs de mon serveur Apache, mais je ne trouve aucune erreur lancée par PHP. PMB a-t-il son propre système de journaux ? Ou bien faut-il modifier les configurations Apache et/ou PHP pour augmenter la verbosité ?

Auriez-vous une idée pour orienter mes recherches ?

Cordialement,

Benoît

benoit.reyt@free.fr · décembre 2019

Bonjour,

J'ai mis à jour en version 7.3.1, mais je rencontre le même problème.

Je ne sais pas trop par quel bout commencer pour trouver l'origine de cette erreur...

Cordialement,

Benoît

benoit.reyt@free.fr · décembre 2019

Bonjour,

Je continue à chercher...

J'ai activé le log général pour étudier les requêtes SQL : pour le mot tintin, par exemple, je vois cela :

534 Query select id_mot from mots where mot='tintin'
534 Query select distinct id_word from words where words.word='tintin'

Ce qui m'étonne c'est que, dans PhpMyAdmin, je ne vois pas la table mots, pas plus que la table words...

Cordialement,

Benoît

abbe.andre.lamberts · janvier 2020

Bonjour,

Je suis passé de 4.1.3 à 7.3.1 et j'ai rencontré ce problème, "aucun tire trouvé...".

J'ai testé en local, et je pense, on ne peut pas passer directement à 7.3.1,

J'ai mis pmb à jour avec les versions

4.1.9, 4.2.1, 4.2.14, 5.7 et 7.3.1 la recherche part titre marche.

Cordialement

benoit.reyt@free.fr · janvier 2020

Bonjour,

Merci pour votre réponse et votre conseil.

Cela m'a conduit à installer une seconde instance de PMB 7.3.1, pour comparer les tables d'une installation fraîche et de la mienne : il semble y avoir pas mal de différences

Par exemple, si je fais une recherche d'autorité avec le joker *, j'obtiens plusieurs fois le message d'erreur suivant avant l'affichage des résultats (j'ai activé l'affichage des erreurs PHP) :

select * from aut_link where (aut_link_from='6' and aut_link_from_num='1')
		order by aut_link_type, aut_link_string_start_date, aut_link_string_end_date, aut_link_rank

J'ai ressaisi cette requête directement dans PhpMyAdmin, ce qui donne :

#1054 - Champ 'aut_link_rank' inconnu dans order clause

J'ai comparé la table aut_link dans les deux installations : la fraîche a 14 champs, contre seulement 11 dans mon installation de "production" ! Ça m'a d'abord paru anecdotique, mais il semble que ce soit le cas pour beaucoup de mes tables...

Pourtant, ma base de données est bien en version 5.33. Y a-t-il un moyen de corriger cela sans perdre mes données ?

J'ai poursuivi en réalisant une sauvegarde de ma base de production, pour la restaurer dans l'installation fraîche : plantage dans les grandes largeurs !

Dans un premier temps, lorsque j'upload mon fichier de sauvegarde, j'ai trois messages d'erreur sur la page de choix des tables à restaurer :

Notice: Undefined variable: current_module in /home/apache2/pmb7/admin/sauvegarde/restaure.php on line 34

Notice: Undefined variable: logid in /home/apache2/pmb7/admin/sauvegarde/restaure.php on line 38

Notice: Undefined index: Crypt in /home/apache2/pmb7/admin/sauvegarde/restaure.php on line 84

Ça sent déjà pas bon...

Je continue tout de même, en entrant les paramètres de la base de destination, et c'est un festival :

Notice: Undefined index: compress in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 10

Notice: Undefined index: crypt in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 11

Notice: Undefined index: decompress in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 13

Notice: Undefined index: decompress_ext in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 14

Notice: Undefined index: decompress_type in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 15

Notice: Undefined index: phrase1 in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 16

Notice: Undefined index: phrase2 in /home/apache2/pmb7/admin/sauvegarde/emergency/messages_env_ract.inc.php on line 17

Notice: Undefined variable: class_path in /home/apache2/pmb7/includes/mysql_functions.inc.php on line 7

Warning: require_once(/pmb_mysqli.class.php): failed to open stream: No such file or directory in /home/apache2/pmb7/includes/mysql_functions.inc.php on line 7

Fatal error: require_once(): Failed opening required '/pmb_mysqli.class.php' (include_path='.:/usr/share/php') in /home/apache2/pmb7/includes/mysql_functions.inc.php on line 7

Cela me paraît indiquer peut-être un problème dans ma configuration PHP, avec des chemins que PMB ne trouve pas...

Je ne parviens pas à déterminer si PMB génère des logs quelque part, ça aiderait.

Cordialement,

Benoît

cedgoo · janvier 2020

Bonjour,

effectivement, la procédure de mise à jour proposée par #abbe.andre.lamberts évite ce genre de problème. Il y a la possibilité de redescendre en version de noyau de base afin de relancer la mise à jour. Dans Administration\Outils\paramètres\paramètres généraux, à bdd_version, modifier la valeur v5.33 par v5.28 (si la base d'origine était sous PMB 5.0.7), enregistrer puis se déconnecter et se reconnecter afin de relancer la mise à jour. C'est ainsi que j'ai pu corriger les bugs liés au passage par la 7.0 avant la 7.3.

benoit.reyt@free.fr · janvier 2020

Bonjour,

D'abord, merci beaucoup cedgoo pour votre message : grâce à cette astuce, j'ai pu refaire les mises à jour successives de la base, qui se rapproche désormais beaucoup mieux d'une installation fraîche.

Au passage, j'ai rencontré l'erreur suivante, qui empêchait la création de certaines tables avec des index trop grands :

#1071 - Specified key was too long; max key length is 767 bytes

Cela vient d'une limite de mysql/mariadb, qui a été levée avec leurs versions respectives 5.7 et 10.2 (source : https://florent.poinsaut.fr/2018/08/17/mysql-mariadb-index-column-size-too-large-the-maximum-column-size-is-767-bytes/).

Comme j'utilise mariadb sous Ubuntu 18.04, j'étais en version 10.1 : j'ai fait la mise à jour en suivant ce lien (et en remplaçant 10.3 par 10.4, tant qu'à faire). Ça a très bien marché.

J'ai ensuite réindexé ma base, en croisant les doigts... en vain

Mon problème est toujours le même : aucun titre trouvé sur une recherche de notices dans le catalogue, sauf avec le joker * qui me renvoie bien toutes mes notices (comme dans cette autre discussion).

Y a-t-il un moyen de connaître la ou les requêtes SQL qui sont exécutées lors d'une recherche de notice dans le catalogue ? J'aimerais les exécuter directement dans PhpMyAdmin pour voir si je n'obtiens pas une erreur qui pourrait m'aiguiller...

Cordialement,

Benoît

cedgoo · janvier 2020

A tout hasard, les urls de connexion au portail et au backoffice sont bien renseignées dans les paramètres ?

benoit.reyt@free.fr · janvier 2020

L'adresse externe du site est renseignée dans les paramètres suivants :

url_base_cms_build
biblio_website
url_base
url_internal

Y a-t-il d'autres paramètres que je dois contrôler ?

Cordialement,

Benoît REYT

cedgoo · janvier 2020

il y a aussi aussi url_base_cms_build dans la section Portail mais je ne pense pas que cela influe sur les résultats de recherche

benoit.reyt@free.fr · janvier 2020

Comme j'utilise mariadb sous Ubuntu 18.04, j'étais en version 10.1 : j'ai fait la mise à jour en suivant ce lien (et en remplaçant 10.3 par 10.4, tant qu'à faire). Ça a très bien marché.

Une précision toutefois, quoique sans aucun rapport avec mon problème : la mise à jour de mariadb en version 10.4 modifie le paramètre sql_mode, en ajoutant par défaut STRICT_TRANS_TABLES, ce qui a pour effet de générer des erreurs avec beaucoup de requêtes de PMB, qui remplissent par exemple un champ numérique avec la chaîne vide ''.

Pour que cela fonctionne normalmeent, j'ai dû adapter le fichier de configuration mariadb avec la ligne :

sql_mode = ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

(donc en retirant le paramètre STRICT_TRANS_TABLE, source : https://mariadb.com/kb/en/sql-mode/)

Moyennant quoi, mon problème principal reste entier à ce jour

Cordialement,

Benoît REYT

cedgoo · janvier 2020

Je me suis trompé, il y a opac_url dans les paramètres généraux et si celui-ci n'est pas renseigné, cela peut-être l'origine du problème.

benoit.reyt@free.fr · janvier 2020

Actuellement, la valeur de ce paramètre est relative (./opac_css/) ; faut-il que je mette l'URL complète ?

cedgoo · janvier 2020

oui, surtout si le dossier de l'OPAC/portail utilisé n'est pas dans le dossier de PMB

benoit.reyt@free.fr · janvier 2020

OK, merci.

J'ai fait la modification, mais sans effet : toujours aucun titre trouvé lors des recherches de notices depuis le catalogue.

Immaculeedamville · janvier 2020

Bonjour,

Nous avons dans l'établissement école/collège deux PMB. Nous avons le même problème. Lors des recherches par titre, nous avons le résultat "aucun titre trouvé" dans l'onglet catalogue mais également sur l'OPAC. Cependant, lorsque nous faisons des recherches par l'auteur, cela fonctionne.

Si vous avez des solutions, merci d'avance,

Cordialement,

Julien

benoit.reyt@free.fr · janvier 2020

Je vous confirme que nous avons les mêmes symptômes : les recherches sur les auteurs fonctionnent.

Depuis quand, ou à la suite de quel événement rencontrez-vous ce problème ?

Immaculeedamville · janvier 2020

Nous rencontrons ce problème depuis que nous sommes passé à la version 7.3.

delphine.metten@usaintlouis.be · janvier 2020

Bonjour, je reprends le fil de cette discussion un peu ancienne pour savoir quelle solution vous avez pu trouver ? A la suite d'une opération de transfert de notre PMB + mise à jour, je ne parviens pas à rétablir l'index global ce qui donne lieu aux même symptômes à savoir : pas de résultat sur la recherche globale ou sur les titres (ni dans la catalogue, ni dans l'OPAC). Les autres index fonctionnent (auteur, éditeur, type...). Merci !

camille.brouzes · janvier 2020

Avez vous essayé de faire la manip conseillée par @cedgoo sur ce fil dans un message du 07 janvier, à savoir downgradé votre base, puis refaire la montée de version ?

benoit.reyt@free.fr · janvier 2020

Bonjour,

J'ai fait une seconde fois la manip indiquée par @cedgoo, en partant de plus loin (v4.94) : ça m'a permis de corriger encore quelques erreurs dans la structure de la base, mais le problème reste entier.

delphine.metten@usaintlouis.be · janvier 2020

Pour ma part, je suis parvenue à résoudre mon problème : la table notices_mots_global_index était vide et l'outil Nettoyage de base > Réindexer l'index global n'a pas fonctionné. Mais j'ai pu réimporter la table directement dans phpMyAdmin depuis une sauvegarde (en local).

cedgoo · janvier 2020

Il s'agissait à l'origine d'une restauration sans les tables notices_fields_global_index, notices_mots_global_index et notices_global_index ?

delphine.metten@usaintlouis.be · janvier 2020

Pas exactement. Le module de sauvegarde/restauration n'a pas fonctionné dans mon cas. Dans phpMyAdmin lors de l'export puis import de la DB de PMB, la table notices_mots_global_index a généré une erreur. J'ai finalement importé cette table séparément.

freynaud · janvier 2020

De mon côté, après avoir vu ça, et comme la recherche fonctionnait avant la réindexation, j'ai refait la manip et constate que la réindexation vide ces deux tables. WTF ;-)

Je précise que la maintenance MySql est RAS, et que la mise à jour de la base se déroule bien, sans vidage lors de cette mise à jour, c'est donc bien lors de la réindexation.

benoit.reyt@free.fr · janvier 2020

Bonjour,

Merci @delphine.metten@usaintlouis.be pour cette piste : j'ai pu restaurer la table notices_mots_global_index à partir d'une ancienne sauvegarde, et effectivement les recherches de notices renvoient à nouveau des résultats. Évidemment, ces résultats omettent les notices saisies depuis ladite sauvegarde...

N'étant pas en environnement de production, j'ai pu me permettre de relancer une réindexation de l'index global : cela recrée le problème, les recherches de notices n'aboutissent pas, et je constate que la table notices_mots_global_index est à nouveau complètement vide.

Il me semble voir furtivement passer des messages d'erreur pendant la réindexation, je vais essayer de les identifier.

cedgoo · janvier 2020

restaurer une table, surtout celle-là, après avoir saisi de nouvelles notices ne peut provoquer que des erreurs ensuite lors de la réindexation. En fait, la réindexation vide la table mais ne la remplit pas... Dans Administration\Outils\Maintenance MySQL\vérifier la présence des index sur les tables, des problèmes sont-ils reportés ?

benoit.reyt@free.fr · janvier 2020

Merci pour cette précision. Qu'est-ce qui remplit la table ?

Voici les problèmes reportés chez moi par la vérification des index :

Erreurs constatées, vérifiez les index suivants :
--------- aut_link PRIMARY aut_link_from missing
--------- aut_link PRIMARY aut_link_from_num missing
--------- aut_link PRIMARY aut_link_to missing
--------- aut_link PRIMARY aut_link_to_num missing
--------- aut_link PRIMARY aut_link_type missing

cedgoo · janvier 2020

Je me suis mal exprimé : la réindexation vide la table mais ne la remplit pas... alors qu'elle devrait le faire.

.Voici en piece jointe la table aut_link de PMB 7.3.1. Elle est vide (même dans ma base de 34.000 notices). Il faudra juste renommer l'extension en sql ou sav selon la procédure de restauration (j'ai dû la nommer en .jpg afin de pouvoir l'uploader

)

Bon, ca n'a pas marché, du coup voici le code de la sauvegarde de la table

```

drop table if exists aut_link;
CREATE TABLE `aut_link` ( `aut_link_from` int(2) NOT NULL DEFAULT '0', `aut_link_from_num` int(11) NOT NULL DEFAULT '0', `aut_link_to` int(2) NOT NULL DEFAULT '0', `aut_link_to_num` int(11) NOT NULL DEFAULT '0', `aut_link_type` varchar(2) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `aut_link_reciproc` int(1) NOT NULL DEFAULT '0', `aut_link_comment` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `aut_link_string_start_date` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `aut_link_string_end_date` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `aut_link_start_date` date NOT NULL DEFAULT '0000-00-00', `aut_link_end_date` date NOT NULL DEFAULT '0000-00-00', PRIMARY KEY (`aut_link_from`,`aut_link_from_num`,`aut_link_to`,`aut_link_to_num`,`aut_link_type`), KEY `i_from` (`aut_link_from`,`aut_link_from_num`), KEY `i_to` (`aut_link_to`,`aut_link_to_num`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

```

benoit.reyt@free.fr · janvier 2020

Ah, OK, compris.

J'ai des difficultés à tracer les erreurs MySQL : j'ai configuré mon serveur pour qu'il enregistre toutes les requêtes, mais je ne trouve pas comment le configurer pour qu'il enregistre également les réponses...

Immaculeedamville · janvier 2020

Merci pour vos solutions. Que faites vous des nouvelles notices ? Il faut les recréer ?

Migration 7.3 : "Aucun titre n'a été trouvé."

Réponses