Jaa

實際經驗分享：解決 OMPM 問題：「資料表 'osWarning' 中資料行 'WarningInfo' 的型別太小，無法保存資料」

  • Artikkeli

英文原文已於 2011 年 8 月 25 日星期四發佈

我是 Anthony Cafarelli，在 Microsoft 諮詢服務擔任顧問的工作。最近我根據在客戶端執行 OMPM 掃描的經驗，彙整了一份我認為十分實用的建議清單。在這篇部落格文章中，我將與您分享其中部分資訊，希望每個人在看到這些建議時，都覺得有所助益。

在這篇文章中，我想要探討的主題是匯入錯誤。一般當掃描的檔案之檔名很長，超過 250 個字元時，就會發生此錯誤。這項錯誤雖然不常發生，但萬一發生這種情況時，這些步驟可以協助您解決匯入問題。當您將資料匯入 OMPM 資料庫時，可能會收到下列錯誤：

資料表 'osWarning' 中資料行 'WarningInfo' 的型別太小，無法保存資料

發生此錯誤表示您嘗試匯入之 XML 檔案中的檔名及路徑，對於 "osWarning" 資料表的 “Warninginfo” 欄位而言太長。也因為這項長度問題，因此無法將資訊匯入資料庫，並會略過該 XML 檔案。通常在出現此錯誤時，如有顯示「上次存取日期」或「上次修改日期」警告，您可以無須擔心檔案未匯入資料庫；但檔案若是包含多個 XML 檔案之 .cab 檔案的一部分 (而且大部分都是這種情況，倘若您未修改 offscan.ini 檔案以變更這些設定，CAB 很有可能會包含 10,000 個檔案)。另請特別注意，CAB 檔案中如有任何 XML 檔案無法匯入，則所有檔案都不會匯入。發生此情況時，您可以採取下列幾種作法：

1)      忽略匯入失敗的 CAB 檔案，並以其他正確匯入的 CAB/XML 檔案為結果。

2)      解壓縮 CAB 檔案，然後匯入各個 XML 檔案。

3)      修改資料庫。

選擇第一種作法並沒有其他特別需要注意的地方。那雖然是最簡單的作法，但卻會遺失大量可能十分有用的資料。

而第二種作法相形之下就比較複雜。在我提出的兩種解決問題的方法中，這種方法十分需要仰賴技術人員的協助，但可大幅提升匯入資料庫的時間。

這裡簡單地說明一下匯入的幕後作業方式：當 CAB 中如有任何一個 XML 檔案發生錯誤，就不匯入整個 CAB 檔案的原因，與 OMPM 的匯入方式有關。匯入處理序會解壓縮該 CAB ，然後一次剖析所有的 XML 檔案。這種處理方式雖然可以大幅加快 (差別「非常之大」) CAB 檔案的匯入速度，但卻也降低了解決錯誤的能力。

當您解壓縮出 XML 檔案之後，即可將其他 9,999 (平均) 個 XML 檔案匯入資料庫。我並未實際測量過整個過程的時間，也沒有就此進行過比較，但我相信個別匯入這些數量之 XML 檔案的時間，至少慢了 10 倍之多。另外還有一種方法可以加快匯入速度，但同樣也是十分需要仰賴技術人員的協助 (我個人比較偏好這種方式，因為我十分討厭為了支援某項功能而修改資料庫，對於這部分，稍後我將會再稍加說明)。以下是第二種作法的修正版：

1)      解壓縮 CAB 檔案。

2)      使用 findstr 命令找出發生錯誤的解壓縮 XML 檔案。

3)      刪除該 XML 檔案。

4)      將剩餘的檔案重新封裝成 CAB 檔案。

這種作法不只可以保有極快的匯入速度，同時可以解決具有超長檔名之檔案所造成的錯誤。使用 findstr 及刪除 XML 檔案是十分容易的操作，因此我將不再多加贅述。不過，重新封裝 CAB 的方法可能各有巧妙，建議您前往以下網頁 (沒錯，在另一個 TechNet 網頁) 執行其所列的 PowerShell 指令檔：

https://technet.microsoft.com/zh-tw/magazine/2009.04.heyscriptingguy.aspx (可能為英文網頁)

當您重新壓縮成另一個 CAB 檔案之後，即可以飛快的速度匯入您的檔案了。這個作法是不是很棒？

現在讓我們談談第三種作法。這個作法曾讓我感到十分掙扎，它的操作簡單且效果優異，但卻會壓縮支援能力。簡單地說，因為資料庫中 oswarning 欄位不夠大，無法容納我們想要放入的資料，所以這個作法的目的，就是要放大 Bucket 的容量。我找到兩種方法可以達成這個目的。寫到這裡，我發現自己挺偏愛編號清單的，所以在這邊繼續使用這種方式列出這兩種方法：

1)      使用 SQL Management Studio 修改欄位大小。

2)      修改 OMPM 用以建立資料庫的檔案，讓您所建立的每一個資料庫，在一開始就擁有比較大的欄位大小。

SQL Management Studio 的用法十分簡單，但不同的 SQL 版本在用法上可能會有些許的差異。在此將不就這點多加描述。如果您有所疑慮，不妨向常用的 SQL 資源 (朋友、同事、書籍、部落格等) 尋求協助，或是使用第二種方法。

第二種方法必須啟動文字編輯器。我最常用「記事本」，因此在這個範例中，我也會使用它。首先啟動 [記事本]，然後開啟 OMPM/Database/Include 資料夾中的 ProvisionDB.sql。

當您開啟檔案之後，請搜尋 “oswarning”，然後按一下 [找下一個] (Find Next)。

「記事本」中應會顯示下列內容：

由此您可以知道 WarningInfo 欄位 255 個字元的限制。只要將該數字變更成更高的數字 (例如 285)，然後存檔即可。如此一來，每當您執行 createdb 命令時，新資料庫就會擁有比較大的欄位。注意：這個動作並不會變更現有的資料庫，因此您必須建立新的資料庫，並對該資料庫執行匯入動作。您或許會想要提取您先前匯入舊資料庫之 OMPMimported 資料夾中的檔案，將其匯入新的資料庫。

Office 相容性小組已經獲悉這項限制，並努力在後續更新版本中解決此問題。

我由衷期望這篇文章對大家能夠有所幫助。我還會陸續在部落格上張貼一些文章探討其他的問題，以及我所發現的「創意」解法。

Anthony

這是翻譯後的部落格文章。英文原文請參閱 Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”