Experiência de campo: resolvendo o problema do OMPM "Tipo de coluna 'WarningInfo' na tabela 'osWarning' é muito pequeno para conter dados"

Artigo original publicado quinta-feira, 25 de agosto de 2011

Meu nome é Anthony Cafarelli, sou um consultor dos Serviços de Consultoria da Microsoft e compilei recentemente uma lista de conselhos úteis que obtive ao executar varreduras do OMPM nos sites do cliente. Neste blog, gostaria de compartilhar um pouco deste conhecimento e espero que vocês possam tirar proveito.

O problema que abordarei neste blog é um erro de importação. Este erro é causado quando os arquivos digitalizados têm nomes de arquivo muito longos, com mais de 250 caracteres. Portanto, não é um erro muito comum, mas estas atapas irão ajudá-lo a corrigir a importação se você se encontrar nessa situação. Ao importar dados para o banco de dados do OMPM, você poderá receber o seguinte erro:

Tipo de coluna 'WarningInfo' na tabela 'osWarning' é muito pequeno para conter dados

O que esse erro indica é que o nome e caminho de um arquivo arquivo XML que você está tentando importar é muito longo para o campo "Warninginfo" na tabela osWarning. Devido a esse problema de tamanho, as informações não são importadas para o banco de dados, e o arquivo XML é ignorado. Normalmente, isso é mostrado no aviso de data Último Acesso ou Última Modificação; portanto, deixar de ter os arquivos no banco de dados não é tão importante. No entanto, se ele fazia parte de um arquivo .cab que contém vários arquivos XML (e provavelmente fazia e esse CAB deve conter 10 mil arquivos, a menos que você tenha modificado o arquivo offscan.ini para alterar essas configurações). E isso é importante observar, se não for possível importar algum arquivo XML contido em um arquivo CAB, nenhum desses arquivos irá para o banco de dados. Nesse ponto, você tem algumas opções:

1)      Ignore o arquivo CAB que não foi importado e tenha como base seus resultados encontrados nos outros arquivos CAB/XML que foram importados corretamente.

2)      Extraia o arquivo CAB e importe cada XML.

3)      Modifique o banco de dados.

Se a opção 1 for aceitável, não há nada mais que posso acrescentar. Essa é a opção mais fácil, mas você perde uma quantidade significativa de dados que podem ser úteis.

A opção 2 é interessante. Das 2 opções que listei para resolver o problema, esta é a que exige mais trabalho do técnico, mas aumenta significativamente o tempo de importação para o banco de dados.

Só para aprofundar um pouco de forma simplificada: a razão pela qual o CAB inteiro não é importado quando um único arquivo XML tem erro é devido à maneira na qual o OMPM faz a importação. O CAB é extraído pelo processo de importação e todos os arquivos XML são analisados ao mesmo tempo. Isso acelera significativamente a importação de um arquivo CAB, mas também reduz a capacidade de resolver erros.

Se você extrair os arquivos XML, poderá obter (em média) os outros 9.999 arquivos XML importados para seu banco de dados. Eu realmente não cronometrei e comparei, mas eu diria que a importação dos arquivos XML individuais é pelo menos 10 vezes mais lento, se não mais. Há outra maneira de aumentar a velocidade da importação, mas envolve mais trabalho do técnico (e este é meu método preferido porque odeio modificar o banco de dados devido às preocupações com suporte e abordarei esse aspecto um pouco mais abaixo). Aqui está a opção modificada 2:

1)      Extraia o arquivo CAB.

2)      Use o comando findstr para localizar o arquivo XML extraído que está com erro.

3)      Exclua esse arquivo XML.

4)      Empacote novamente o arquivo CAB com os arquivos restantes.

Com esse método, você mantém a alta velocidade de importação e lida com o arquivo de nome longo. Usar findstr e excluir o arquivo XML é bem simples, por isso, não vou explicá-los. Mas encontrar uma boa maneira para empacotar novamente o CAB pode ser difícil. Meu melhor conselho é ir a esta página (sim, outra página do TechNet) e implementar os scripts do PowerShell listados:

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

Depois que tiver recompactado em outro arquivo CAB, você poderá importá-lo e ainda manter sua alta velocidade de importação. Truque muito bom, não acha?

Agora vamos falar sobre a Opção 3. Tenho opiniões muito ambíguos sobre esta. É fácil e eficaz, mas ela definitivamente sobrecarrega a capacidade de suporte. A explicação simples desta abordagem é a seguinte: o campo oswarning no banco de dados não é suficientemente grande para armazenar os dados que estamos tentando colocar nele, então vamos aumentá-lo. Encontrei dois métodos para fazer isso. E com base no que eu escrevi até agora, eu amo listas numeradas, então aqui vai outra:

1)      Use o SQL Management Studio para modificar o tamanho do campo.

2)      Modifique os arquivos que o OMPM usa para criar o banco de dados, para que cada banco de dados que você criar tenha o tamanho de campo maior no início.

Usar o SQL Management Studio é bem intuitivo, mas dependendo da sua versão do SQL, ele pode ser ligeiramente diferente. Não vou entrar em detalhes sobre essa solução; portanto, se tiver dúvidas, consulte seu recurso de SQL (amigo, colega, livro, blog etc.) e pesquise, ou use o segundo método.

O segundo método exige que você acione um editor de texto. Notepad.exe é o meu favorito e vou usá-lo como um exemplo. Inicie o notepad e abra o ProvisionDB.sql na pasta OMPM/Database/Include.

Depois de abrir o arquivo, pesquise por "oswarning" e clique em Find Next.

Você visualizará o seguinte:

Aqui você visualizará o campo WarningInfo (com 255 caracteres). Basta mudar o número para algo maior (digamos 285) e salvar o arquivo. Agora, toda vez que você executar o comando createdb, o novo banco de dados terá um campo maior. OBSERVAÇÃO: isso não modificará seus bancos de dados existentes; portanto, verifique se criou um novo banco de dados e execute suas importações lá. Você desejará obter todos os arquivos da pasta OMPMimported que você importou para o antigo banco de dados para que possa importar novamente para o novo.

A equipe de Compatibilidade do Office está ciente desta limitação e está analisando este desafio para as próximas atualizações.

Espero que tenha sido útil a todos que leram. Planejo escrever mais algumas postagens de blog sobre outros problemas e soluções "criativas" que encontrei na prática.

Anthony

Esta é uma postagem de blog traduzida. O artigo original está em Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”