Corrections de la base de données - Script inconsistencies

Corrections de la base de données - Script inconsistencies

Un nouveau fichier est déposé sur les instances, dans les outils, sous Accès aux fichiers. Le fichier s'appelle inconsistencies_CÉGEP (CÉGEP étant le nom de votre établissement).

Ce fichier est créé par un script qui est roulé sur les instances afin de faire de la validation des données de votre base de données. Ainsi, les problèmes d'encodage, de zones et sous-zones non remplies ou des valeurs autorisées non valides sont trouvés par le script et compilés dans ce fichier pour que vous soyez en mesure d'apporter les corrections nécessaires.

Le présent article vous aidera à décoder les erreurs décrites par le fichier, mais vous propose également des rapports SQL pour effectuer les actions en lot. Chaque section de cet article présente le problème tel que décrit dans le rapport.

Dans le rapport, les sections sont toujours présentées comme suit :
== Description du problème ==
* Cas spécifique
=> Solution pour régler le problème

Bibliothèque propriétaire et bibliothèque actuelle (952$a et $b) vides / == Not defined items.homebranch and/or items.holdingbranch ==

Sous ce problème, vous aurez une liste d'exemplaires, identifiés par leur numéro Koha, soit le itemnumber.
Jusqu'à la version 22.05, un 952 $a ou $b vide ne posait pas de problème dans Koha, mais à partir de la version 23.05, un exemplaire ayant un $a ou $b vide provoque un problème d'affichage de la notice à l'OPAC.

Le rapport suivant présente tous les exemplaires qui n'ont pas de $a ou de $b. À partir de ce rapport, vous pourrez modifier en lot les exemplaires pour mettre un $a et un $b. Le rapport présente maximum 10 000 exemplaires au total. Pour pouvoir modifier en lot les 10 000 exemplaires, il faudra que la préférence système MaxItemsToProcessForBatchMod soit à 10 000.

Attention ! Si vous êtes un établissement avec plusieurs campus/bibliothèques dans Koha, il sera important de valider dans quelle bibliothèque les exemplaires doivent effectivement aller avant de faire la modification en lot.

Ce rapport a été enregistré dans la majorité des sites Koha en prévention pour la migration 23.05, sous le nom Inconsistencies - Bibliothèque propriétaire et actuelle vides. Il se peut que le code varie d'un site à l'autre, il a été ajusté dans certains cas, notamment pour les Koha multisites.
SELECT
items.biblionumber,
itemnumber,
homebranch "Bibliothèque propriétaire",
holdingbranch "Bibliothèque actuelle",
authorised_values.lib "Statut",
itemtypes.description "Type de document"

FROM items
LEFT JOIN itemtypes ON (items.itype=itemtypes.itemtype)
LEFT JOIN authorised_values ON (items.notforloan=authorised_values.authorised_value)

WHERE (holdingbranch IS NULL OR homebranch IS NULL)
AND authorised_values.category='NOT_LOAN'

ORDER BY homebranch,holdingbranch

LIMIT 10000

Notice sans titre (245$a vide) / == Biblio without title 245$a ==

Sous ce problème, vous aurez une liste de notices, identifiées par leur numéro Koha, soit le biblionumber. Une notice sans titre (245$a), a toujours été problématique de façon aléatoire dans Koha. Cela cause parfois des problèmes de recherche, des problèmes d'affichage à l'intranet et OPAC, etc.

Le rapport suivant vous donne la liste des notices qui n'ont pas de titre.

SELECT
biblionumber,
title

FROM biblio

WHERE title IS NULL

Exemplaires et notices sans type de document défini (952$y) / == Items do not have itype defined ==

Sous ce problème, vous aurez une liste d'exemplaires et de notices, identifiés par leur numéro Koha, soit le itemnumber et le biblionumber. Si l'exemplaire et la notice n'ont pas de type de document, les deux apparaitront ensemble sur la même ligne. S'il y a un type de document au niveau de la notice, le script vous indiquera que c'est ce type qui sera utilisé pour gérer la règle de circulation.
Depuis la version 23.05, le type de document vide cause une erreur d'affichage à l'OPAC. L'erreur sera causé par le type de document vide au niveau de l'exemplaire OU au niveau de la notice, en fonction de ce qui se trouve dans la préférence item-level_itypes. Cette préférence indique quel type de document, entre celui de la notice et celui de l'exemplaire, est utilisé pour sélectionner la règle de circulation. Si cette préférence indique d'utiliser le type de document de l'exemplaire (c'est habituellement l'option choisie), la zone 952$y vide va causer l'erreur. Si cette préférence indique d'utiliser le type de document de la notice, la zone 942$c vide va causer l'erreur.

Si votre préférence système item-level_itypes est à Exemplaire, il faut remplir la zone 952$y. Le rapport suivant vous donne la liste des exemplaires qui n'ont pas de type de document.
SELECT
items.itemnumber,
items.biblionumber,
items.itype "952$y",
biblioitems.itemtype "942$c"

FROM items
LEFT JOIN biblioitems USING (biblionumber)

WHERE items.itype IS NULL

ORDER BY biblioitems.itemtype

Si votre préférence système item-level_itypes est à Notice bibliographique, il faut remplir la zone 942$c. Le rapport suivant vous donne la liste des notices qui n'ont pas de type de document.
SELECT
items.itemnumber,
items.biblionumber,
items.itype "952$y",
biblioitems.itemtype "942$c"

FROM items
LEFT JOIN biblioitems USING (biblionumber)

WHERE biblioitems.itemtype IS NULL

ORDER BY biblioitems.itemtype


Autorité ayant un type d'autorité invalide (942$a) / == Invalid auth_header.authtypecode ==

Sous ce problème, vous aurez une liste d'autorités, identifiés par leur numéro Koha, soit le authid. Les autorités identifiées ont un type d'autorité qui est vide ou qui ne correspond pas à ce que vous avez dans vos types d'autorités, c'est-à-dire les codes des grilles de catalogage d'autorités. Vous trouverez ceux-ci dans le module Administration, sous Catalogue puis Types d'autorités. Ces codes apparaissent dans la zone 942$a des autorités.



Le rapport SQL suivant vous permettra de trouver les autorités mentionnées dans le fichier Inconsistencies.


SELECT
authid,
marcxml "Détails",
authtypecode "Type d'autorité"

FROM auth_header

WHERE authtypecode NOT IN (SELECT authtypecode FROM auth_types)

Dans la colonne Type d'autorité, vous aurez des codes qui ne sont pas dans le tableau des types d'autorité. Ces codes sont donc invalides. Sinon, vous aurez la mention undefined pour ceux qui sont vides.

    • Related Articles

    • La BD SIS et ses mystères : inscriptions avec Admin Cégep et base de données externes

      BD: base de données SIS: système d'information scolaire (student information system) Pour la création des cours et l'inscription des groupes classes, nous avons recours à deux plugins, soit Admin Cégep, qui offre une interface de création des cours ...
    • Impression en lot de fiches

      Dans la recherche d'inventaire, il est possible d'imprimer plusieurs fiches de données de sécurité en même temps, plutôt que de façon individuelle. Pour ce faire, vous devez cocher les cases localisées à gauche de la liste de produits après avoir ...
    • Base de connaissance Mana 19.05

      Mana est une base de connaissances qui vous donne accès à une immense banque de données. La base mana vous donne accès à des connaissances de la communauté internationale telle que des rapports SQL, des modèles de prévision de publication de ...
    • Comment faire une demande de nouvelle fiche

      La banque de fiche contient plus de 34 000 fiches de données de sécurité de fournisseurs différents. Ces fiches sont à votre disposition pour lier votre produit de votre inventaire pour ainsi garder vos informations à jour si telle est le cas. Il se ...
    • Réinitialisation de cours

      Réinitialisation La réinitialisation permet de vider les données utilisateur d'un cours en conservant les activités. Attention! Le contenu réinitialisé sera supprimé de manière définitive. Il est judicieux de faire une sauvegarde du cours comprenant ...