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

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

«1

Réponses

  • 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
  • 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
  • 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
  • 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
  • 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.
  • janvier 2020 modifié
    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
  • A tout hasard, les urls de connexion au portail et au backoffice sont bien renseignées dans les paramètres ?
  • 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
  • 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
  • janvier 2020 modifié
    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
  • 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.
  • Actuellement, la valeur de ce paramètre est relative (./opac_css/) ; faut-il que je mette l'URL complète ?
  • oui, surtout si le dossier de l'OPAC/portail utilisé n'est pas dans le dossier de PMB
  • OK, merci.

    J'ai fait la modification, mais sans effet : toujours aucun titre trouvé lors des recherches de notices depuis le catalogue.
  • 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
  • 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 ?
  • Nous rencontrons ce problème depuis que nous sommes passé à la version 7.3.
  • 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 !
  • 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 ?
  • 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.
  • 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).


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



  • 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.
  • janvier 2020 modifié
    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.
  • 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.


  • janvier 2020 modifié
    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 ?
  • 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

  • janvier 2020 modifié
    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;

    ```



  • 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...
  • Merci pour vos solutions. Que faites vous des nouvelles notices ? Il faut les recréer ?

Connectez-vous ou Inscrivez-vous pour répondre.