Experiencia de campo: resolución del problema de OMPM “El tipo de columna ‘WarningInfo’ de la tabla ‘osWarning’ es demasiado pequeño para contener datos ”
Artículo original publicado el jueves, 25 de agosto de 2011
Me llamo Anthony Cafarelli y soy consultor de los Servicios de Consultoría de Microsoft; hace poco recopilé una lista de consejos útiles que adquirí mientras realizaba exámenes de OMPM en sitios cliente. En esta entrada de blog me gustaría compartir un poco de ese conocimiento que espero que sea útil para quien lo lea.
El problema en el que me voy a centrar en esta entrada de blog es un error de importación. Dicho error se produce cuando los archivos examinados tienen nombres muy largos; más de 250 caracteres. Aunque no es un error muy común, estos pasos le ayudarán a resolver la importación si se encuentra con esta situación. Al importar datos en la base de datos de OMPM, es posible que se encuentre con el siguiente error:
El tipo de columna ‘WarningInfo’ de la tabla ‘osWarning’ es demasiado pequeño para contener datos
Lo que indica este error es que el nombre de archivo y la ruta de acceso de un archivo XML que está intentando importar es demasiado largo para el campo “Warninginfo” de la tabla "osWarning". Debido a este problema de longitud, la información no se importa a la base de datos y se omite el archivo XML. Normalmente, esto se muestra junto con un aviso de fecha de Último acceso o Última modificación, de modo que no sería de demasiada importancia si los archivos no estuvieran en la base de datos. Sin embargo, si se trata de una parte de un archivo .cab que contiene varios archivos XML (y hay muchas posibilidades de que lo sea, así como de que el archivo CAB contenga 10.000 archivos a menos que haya modificado el archivo offscan.ini para cambiar dicha configuración). También es importante recalcar que si algún archivo XML de un archivo CAB no puede importarse, ninguno de los archivos llegarán a la base de datos. Llegado este punto, tiene algunas opciones:
1) Ignorar que el archivo CAB no se ha importado y basar los resultados en los demás archivos CAB o XML que sí se importaron correctamente.
2) Extraer el archivo CAB e importar cada archivo XML.
3) Modificar la base de datos.
Si la opción 1 es aceptable, no hace falta que diga nada más. Esa es la opción más fácil pero perderá una cantidad importante de datos que podrían ser útiles.
La opción 2 es interesante. De las 2 opciones que he mencionado para solucionar el problema, esta es la que más trabajo requiere por parte del técnico y aumenta de forma importante el tiempo de importación hacia la base de datos.
Solo para proporcionar conocimientos básicos de forma simple: la razón por la que no se importa todo el archivo CAB cuando un solo archivo XML tiene un error es por la manera en que OMPM realiza la importación. El proceso de importación extrae el archivo CAB y cada archivo XML se analiza a la vez. Esto acelera de forma importante (MUY importante) la importación de un archivo CAB pero, al mismo tiempo, reduce la capacidad de tratar errores.
Cuando se extraen los archivos XML, podrá importar los otros 9.999 archivos (de promedio) en la base de datos. Nunca lo he cronometrado ni comparado, pero diría que importar los archivos XML individuales es por lo menos 10 veces más lento, o más. Hay otra manera de acelerar la velocidad de importación, pero es necesario más trabajo por parte del técnico (y este es mi método preferido ya que odio tener que modificar la base de datos por asuntos de compatibilidad; hablaré más a fondo sobre ello más adelante). He aquí la opción 2 modificada:
1) Extraiga el archivo CAB.
2) Utilice el comando findstr para ubicar el archivo XML extraído que tiene el error.
3) Elimine ese archivo XML.
4) Vuelva a empaquetar el archivo CAB con los demás archivos.
Con este método, mantiene la alta velocidad de importación y soluciona el archivo que tiene el nombre largo. Utilizar el comando findstr y eliminar el archivo XML es bastante sencillo, de modo que no voy a profundizar en ello. No obstante, puede ser algo difícil encontrar un buen modo de volver a empaquetar el archivo CAB. El mejor consejo que puedo ofrecer es ir a esta página (exacto, otra página de TechNet page) e implementar los scripts de PowerShell que se enumeran:
https://technet.microsoft.com/en-us/magazine/2009.04.heyscriptingguy.aspx?pr=blog
Una vez haya vuelto a comprimir otro archivo CAB, puede importarlo y mantener la importación de alta velocidad. ¿A que es un buen truco?
Hablemos ahora de la opción 3. Tengo emociones encontrados respecto a esta opción. Es fácil y efectiva pero en definitiva pone en riesgo la compatibilidad. El campo oswarning no es suficientemente grande para contener los datos que estamos intentando meter en él, de modo que hagamos que el contenedor sea más grande. He encontrado dos métodos para hacerlo y, aparentemente, teniendo en cuenta lo que he escrito hasta ahora, me encantan las listas de enumeración, de modo que aquí va otra:
1) Utilice SQL Management Studio para modificar el tamaño del campo.
2) Modifique los archivos que utiliza OMPM para crear la base de datos para que todas las bases de datos que se creen tengan el tamaño ampliado de campo desde el principio.
Es bastante sencillo utilizar SQL Management Studio aunque en función de su versión de SQL podría ser algo diferente. No voy a profundizar demasiado en esta solución, así que si tiene dudas, encuentre su recurso SQL preferido (un amigo, un compañero, un libro, un blog, etc.) e investigue, o utilice el segundo método.
El segundo método requiere que inicie un editor de texto, Mi preferido es Notepad.exe [bloc de notas], de modo que eso es lo que utilizaré como ejemplo. Inicie el bloc de notas y abra el archivo ProvisionDB.sql de la carpeta OMPM/Database/Include.
Una vez haya abierto el archivo, busque “oswarning” y haga clic en Buscar siguiente.
Verá lo siguiente:
Aquí verá el campo WarningInfo (con 255 caracteres). Cambie el número a un valor mayor (por ejemplo 285) y guarde el archivo. Ahora, cada vez que ejecute el comando createdb, la nueva base de datos tendrá un campo más grande. NOTA: esto no modificará las bases de datos existentes; por lo tanto, asegúrese de crear una nueva base de datos y de ejecutar las importaciones en ella. Convendría extraer de la carpeta OMPMimported los archivos que importó a la antigua base de datos para poder volver a importarlos a la nueva.
El equipo de compatibilidad de Office es consciente de esta limitación y estamos revisando el problema para futuras actualizaciones.
Espero que esto haya servido de ayuda para quien lo haya leído. Tengo la intención de escribir más entradas de blog sobre otros problemas y soluciones "creativas" que encontré en el campo.
Anthony
Esta entrada de blog es una traducción. Puede consultar el artículo original en Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”