Expérience sur le terrain : résolution du problème OMPM « Type de colonne "WarningInfo" de la table "osWarning" trop petit pour contenir les données »
Article initial publié le jeudi 25 août 2011
Je m’appelle Anthony Cafarelli et je suis consultant chez Microsoft Consulting Services qui a récemment rassemblé une liste de conseils utiles recueillis lors de la réalisation d’analyses OMPM sur les sites clients. Dans ce billet de blog, je souhaiterais partager une partie de cette connaissance et j’espère que les lecteurs trouveront celle-ci utile !
Le problème sur lequel je vais me concentrer sur ce billet de blog concerne une erreur d’importation. Celle-ci se produit lorsque les fichiers analysés ont des noms très longs, dépassant 250 caractères. Ainsi, il ne s’agit pas d’une erreur extrêmement courante, mais ces étapes vous aideront à traiter l’importation si vous vous trouvez face à une telle situation. Lors de l’importation de données dans la base de données OMPM, il se peut que vous receviez le message d’erreur suivant :
« Type de colonne "WarningInfo" de la table "osWarning" trop petit pour contenir les données »
Ce message signifie que le nom et le chemin du fichier XML que vous voulez exporter sont trop longs pour le champ Warninginfo de la table osWarning. En raison de ce problème de longueur, les informations ne sont pas importées dans la base de données et le fichier XML est ignoré. Généralement, un avertissement de dernière date d’accès ou de modification s’affiche simultanément. Cependant, si le fichier faisait partie d’un fichier .cab contenant plusieurs fichiers XML (et tel est probablement le cas, et plus probablement le fichier CAB contient 10 000 fichiers à moins que vous n’ayez modifié le fichier offscan.ini pour modifier ces paramètres). Et, point important à noter, si un fichier XML contenu dans un fichier CAB ne peut pas être importé, aucun des fichiers n’entrera dans la base de données. À ce stade, vous avez quelques options :
1) Ignorer que le fichier CAB n’a pas pu importer et fonder vos résultats sur les autres fichiers CAB/XML importés correctement.
2) Extraire le fichier CAB et importer chaque fichier XML.
3) Modifier la base de données.
Si l’option 1 convient, je n’ai rien d’autre à ajouter. Il s’agit de l’option la plus simple, mais vous perdrez une quantité importante de données qui pourraient être utiles.
L’option 2 est intéressante. Sur les 2 options répertoriées qui traitent le problème, celle-ci nécessite un travail important pour le technicien, mais accroît de façon significative le temps d’importation dans la base de données.
Juste pour donner un peu le contexte de façon simple : le fait que la totalité du fichier CAB ne s’importe pas quand un seul fichier XML présente une erreur s’explique par la façon dont OMPM réalise l’importation. Le fichier CAB est extrait par le processus d’importation et chaque fichier XML est analysé simultanément. Cela accélère significativement (TRÈS significativement) l’importation d’un fichier CAB, mais réduit aussi la possibilité de traiter les erreurs.
Lorsque vous extrairez les fichiers XML, vous pourrez faire en sorte que les 9 999 (en moyenne) autres fichiers XML soient importés dans votre base de données. Sans avoir réellement chronométré et comparé, je dirais que l’importation de fichiers XML est au moins 10 fois plus lente, si ce n’est plus. Il existe un autre moyen d’augmenter la vitesse d’importation, mais cela requiert plus de travail du technicien (et c’est ma méthode préférée parce que je déteste modifier la base de données en raison de problèmes de soutenabilité, et j’y reviendrai un peu plus loin). Voici l’option 2 modifiée :
1) Extraire le fichier CAB.
2) Utiliser la commande findstr pour retrouver le fichier XML extrait comportant l’erreur.
3) Supprimer le fichier XML.
4) Repackager le fichier CAB avec les fichiers restants.
Grâce à cette méthode, vous maintenez une vitesse d’importation élevée et traitez le fichier avec le nom long. L’utilisation de findstr et la suppression du fichier XML étant assez simples, je n’insisterai pas. Mais, trouver un bon moyen de repackager le fichier CAB peut être complexe. Mon meilleur conseil est d’accéder à cette page (oui, une autre page TechNet) et d’implémenter les scripts PowerShell répertoriés :
https://technet.microsoft.com/en-us/magazine/2009.04.heyscriptingguy.aspx?pr=blog
Une fois la recompression en un autre fichier CAB réalisée, vous pouvez l’importer et continuer à conserver une vitesse d’importation élevée ! Pas mal, non ?
Parlons maintenant de l’option 3. J’ai des sentiments très mélangés à son égard. Elle est simple et efficace, mais, à coup sûr, elle pousse la soutenabilité. Une explication simple de cette approche est celle-ci : comme le champ oswarning de la base de données n’est pas assez grand pour contenir les données que nous souhaitons y placer, il est nécessaire de l’agrandir. J’ai trouvé 2 méthodes pour cela. Et apparemment, en fonction de ce que j’ai écrit jusqu’à présent, il semble que j’aime les listes numérotées, aussi en voici une autre :
1) Utiliser SQL Management Studio pour modifier la taille du champ.
2) Modifier les fichiers que OMPM utilise pour créer la base de données, afin que chaque base de données que vous créez ait au départ la plus grande taille de champ.
L’utilisation de SQL Management Studio est assez simple, mais selon votre version de SQL, il peut exister de légères différences. Comme je en vais pas rentrer dans les détails de cette solution, en cas de doute de votre part, recherchez votre ressource SQL préférée (ami, collègue, livre, blog, etc.) ou utilisez la seconde méthode.
La seconde méthode requiert que vous ouvriez un éditeur de texte. Comme ma préférence va à Notepad.exe, c’est celui que j’utiliserai à titre d’exemple. Lancez Notepad et ouvrez ProvisionDB.sql dans le dossier OMPM/Database/Include.
Une fois le fichier ouvert, recherchez « oswarning », puis cliquez sur Suivant.
Le contenu suivant apparaît :
Vous verrez ici le champ WarningInfo (255 caractères). Modifiez simplement le nombre en une valeur plus grande (par exemple, 285) et enregistrez le fichier. Maintenant, chaque fois que vous exécuterez la commande createdb, la nouvelle base de données aura un champ plus grand. Remarque : comme cela ne modifiera pas les bases de données existantes, veillez à avoir créé une nouvelle base de données et à y avoir exécuté vos importations. Vous souhaiterez extraire les fichiers du dossier OMPMimported que vous avez importés dans l’ancienne base de données afin de pouvoir les réimporter dans la nouvelle.
L’équipe de compatibilité Office est consciente de cette limitation et envisage d’y remédier pour les prochaines mises à jour.
Nous espérons que ces informations vous auront été utiles ! Je prévois d’écrire quelques billets de blog supplémentaires sur d’autres problèmes et sur les solutions que j’y ai apportées.
Anthony
Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”