Aus der Praxis: Beheben des OMPM-Problems „Spaltentyp 'WarningInfo' in Tabelle 'osWarning' ist zu klein, um Daten zu enthalten“

Veröffentlichung des Originalartikels: 25.08.2011

Ich heiße Anthony Cafarelli und bin Berater bei den Microsoft Consulting Services. Ich habe kürzlich eine Liste mit nützlichen Ratschlägen zusammengestellt, die sich beim Durchführen von OMPM-Prüfungen an Clientstandorten ergeben haben. In diesem Blogbeitrag möchte ich meine gewonnenen Erkenntnisse mit Ihnen teilen und hoffe, dass diese für Sie von Nutzen sind.

Der Schwerpunkt dieses Blogbeitrags liegt auf einem Fehler, der verursacht wird, wenn die überprüften Dateien sehr lange Dateinamen (mit mehr als 250 Zeichen) haben. Dieser Fehler beim Importieren tritt nicht häufig auf. Falls doch, können Sie ihn mithilfe der folgenden Schritte beheben. Beim Importieren von Daten in die OMPM-Datenbank wird ggf. der folgende Fehler gemeldet:

Spaltentyp 'WarningInfo' in Tabelle 'osWarning' ist zu klein, um Daten zu enthalten

Dieser Fehler bedeutet, dass der Dateiname und Pfad in einer XML-Datei, die Sie zu importieren versuchen, für das Feld Warninginfo in der Tabelle osWarning zu lang ist. Aufgrund dieses Problems mit der Länge werden die Informationen nicht in die Datenbank importiert, und die XML-Datei wird übersprungen. In der Regel wird auch eine Warnung zum Datum des letzten Zugriffs oder der letzten Änderung angezeigt, weshalb es meist unproblematisch ist, dass diese Dateien nicht in der Datenbank enthalten sind. Etwas anderes gilt, wenn die Datei zu einer CAB-Datei mit mehreren XML-Dateien gehört (was höchstwahrscheinlich der Fall ist, und höchstwahrscheinlich enthält diese CAB-Datei 10.000 Dateien, es sei denn, Sie haben diese Einstellungen in der Datei offscan.ini geändert). Wichtig ist hier der Hinweis, dass wenn eine beliebige in einer CAB-Datei enthaltene XML-Datei nicht importiert werden kann, keine dieser Dateien in die Datenbank gelangt. An dieser Stelle haben Sie verschiedene Möglichkeiten:

1)      Ignorieren, dass die CAB-Datei nicht importiert wurde, und die Ergebnisse auf anderen CAB-/XML-Dateien basieren lassen, die ordnungsgemäß importiert wurden.

2)      Die CAB-Datei extrahieren und jede XML-Datei importieren.

3)      Die Datenbank ändern.

Falls Option 1 in Frage kommt, bleibt mir hier nichts mehr hinzuzufügen. Dies ist die einfachste Option, bei der aber viele ggf. nützliche Daten verloren gehen.

Option 2 ist interessant. Von den beiden Optionen, die ich zur Behebung des Problems aufgeführt habe, bedeutet diese eine Menge Arbeit für den IT-Techniker, aber auch eine wesentliche Beschleunigung des Datenimports in die Datenbank.

Doch zunächst ein paar Hintergrundinformationen: Der Grund, warum die gesamte CAB-Datei nicht importiert wird, wenn eine einzelne XML-Datei einen Fehler aufweist, ist die Weise, in der OMPM den Import durchführt. Die CAB-Datei wird im Verlauf des Importprozesses extrahiert, wobei alle XML-Dateien auf einmal analysiert werden. Dies beschleunigt (sehr stark) den Import einer CAB-Datei, schränkt aber auch die Fähigkeit ein, Fehler zu beheben.

Beim Extrahieren der XML-Dateien können die (im Schnitt) 9999 anderen XML-Dateien in die Datenbank importiert werden. Ich habe es nicht tatsächlich gestoppt und verglichen, doch ich würde sagen, dass der Import der einzelnen XML-Dateien mindestens 10-mal, wenn nicht noch länger dauert. Es gibt eine weitere Möglichkeit zum Beschleunigen der Importgeschwindigkeit, die jedoch mehr Arbeit durch den IT-Techniker verlangt (was mir besser gefällt, da ich es nicht mag, die Datenbank aufgrund von Problemen bei der Unterstützung zu ändern, was ich weiter unten detaillierter behandeln werde). Hier nun die geänderte Option 2:

1)      Extrahieren Sie die CAB-Datei.

2)      Suchen Sie mit dem Befehl findstr die extrahierte XML-Datei mit dem Fehler.

3)      Löschen Sie diese XML-Datei.

4)      Packen Sie die CAB-Datei mit den restlichen Dateien erneut.

Bei dieser Methode wird die hohe Importgeschwindigkeit beibehalten und die Datei mit dem langen Namen entfernt. Das Auffinden und Löschen der XML-Datei mit findstr ist unkompliziert, weshalb hierfür keine weiteren Erläuterungen erfolgen. Doch das Bestimmen einer geeigneten Methode zum Neupacken der CAB-Datei kann schwierig sein. Die beste Möglichkeit ist es, zur folgenden TechNet-Seite zu wechseln und die aufgeführten PowerShell-Skripts zu implementieren:

https://technet.microsoft.com/en-us/magazine/2009.04.heyscriptingguy.aspx?pr=blog

Nachdem die Komprimierung in eine andere CAB-Datei erfolgt ist, können Sie diese importieren und weiter vom Hochgeschwindigkeitsimport profitieren! Guter Trick, oder?

Nun wollen wir uns Option 3 zuwenden, für die ich gemischte Gefühle habe. Sie ist einfach und effektiv, gelangt aber definitiv an die Grenzen der Unterstützbarkeit. Die einfache Erklärung dieses Ansatzes ist wie folgt: Das Feld oswarning in der Datenbank ist für die Daten, die Sie in ihm ablegen möchten, nicht groß genug, weshalb zunächst der Bucket vergrößert werden soll. Hierfür habe ich zwei Möglichkeiten herausgefunden. Und basierend auf dem bisherigen Verlauf mag ich anscheinend nummerierte Listen, sodass nun eine weitere folgt:

1)      Ändern Sie die Feldgröße in SQL Management Studio.

2)      Ändern Sie die Dateien, mit deren Hilfe OMPM die Datenbank erstellt, sodass jede Datenbank, die Sie erstellen, eine höhere Ausgangsfeldgröße hat.

Das Arbeiten mit SQL Management Studio ist recht unkompliziert, kann jedoch abhängig von Ihrer SQL Server-Version unterschiedlich sein. Ich will diese Lösung nicht weiter vertiefen. Wenn Sie also eher unsicher sind, konsultieren Sie Ihre bevorzugte SQL Server-Ressource (Freund, Kollege, Buch, Blog usw.) oder greifen auf die zweite Methode zurück.

Bei der zweiten Methode muss ein Texteditor gestartet werden. Ich bevorzuge Notepad.exe (Editor), den ich auch im folgenden Beispiel verwende. Starten Sie Editor, und öffnen Sie im Ordner OMPM/Database/Include die Datei ProvisionDB.sql.

Suchen Sie in der geöffneten Datei nach oswarning, und klicken Sie auf Weitersuchen.

Folgendes wird angezeigt:

Hier sehen Sie nun das Feld WarningInfo (mit dem Wert 255). Ändern Sie den Wert einfach in einen höheren Wert (z. B. 285), und speichern Sie die Datei. Wenn Sie nun den Befehl createdb ausführen, steht der neuen Datenbank ein größeres Feld zur Verfügung. HINWEIS: Dies hat keine Auswirkung auf Ihre vorhandenen Datenbanken. Vergewissern Sie sich deshalb, dass Sie eine neue Datenbank erstellen, und führen Sie Importvorgänge in diese aus. Sie sollten alle Dateien aus dem Ordner OMPMimported abrufen, die Sie in die alte Datenbank importiert haben, damit Sie sie anschließend in die neue Datenbank erneut importieren können.

Das Office-Kompatibilitätsteam kennt diese Einschränkung und beschäftigt sich für künftige Updates mit dieser Problemstellung.

Ich hoffe, dass diese Informationen für Sie hilfreich sind. Ich plane, weitere Blogbeiträge zu anderen Problemen und „kreativen“ Lösungen zu verfassen, die ich in der Praxis gefunden habe.

Anthony

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”