¡Hola, chicos del scripting!

Bienvenido a la columna TechNet en la cual, por medio de Microsoft Scripting Guy, se abordan las preguntas frecuentes acerca de las secuencias de comandos para la administración de sistemas. ¿Tiene alguna pregunta sobre las secuencias de comandos para la administración de sistemas? Envíe un correo electrónico a scripter@microsoft.com. No podemos garantizarle que seremos capaces de responder todas las preguntas que nos lleguen, pero haremos todo lo posible.

Y no se olvide de consultar el Archivo de ¡Hola, chicos del scripting!.

Pregunta del día: ¿cómo puedo guardar un conjunto de registros desconectado?


¿Cómo puedo guardar un conjunto de registros desconectado?

P

¡Hola, chicos del scripting! ¿Cómo puedo guardar un conjunto de registros desconectado?

-- RW

R Hola RW. Ya sabe que a los chicos del scripting nos gusta que las cosas sean los más simples posible. Por ejemplo, cuando uno de nosotros hace unos años tuvo que comprar una corbata nueva, simplemente pidió a su padre que le hiciera el nudo; en las escasas ocasiones en las que este chico del scripting tiene que llevar corbata, al final del día simplemente se la quita con cuidado, sin deshacer el nudo, la cuelga y la deja hasta la próxima vez que debe llevarla. Seguro que hay otras formas de tratar este asunto (digamos, por ejemplo, aprendiendo a hacerse el nudo de la corbata), pero esta es desde luego la forma más sencilla de tratar la situación, así que es la alternativa que ha elegido.

Hemos seguido el mismo enfoque para responder a su pregunta. Existen varias formas de guardar un conjunto de registros desconectado: se podría abrir una base de datos existente y copiar en ella los registros, emplear FileSystemObject para guardar los datos en un archivo de texto o utilizar el modelo de objetos de Excel y escribir la información en una hoja de cálculo. Sin embargo, a pesar de todas estas maravillosas posibilidades, decidimos mantener las cosas con la mayor simplicidad posible y guardar el conjunto de registros desconectado como archivo XML, un enfoque que requiere tan sólo dos líneas de código. Como ya indicamos, hay otras formas de tratar este asunto, pero esta era definitivamente la forma más sencilla de tratar la situación, así que es la alternativa que elegimos.

Una nota rápida: en la columna de hoy no vamos a tratar los conjuntos de registros desconectados, ni siquiera a explicar el código con el que se crean; la verdad es que no tenemos espacio para hacerlo. Por ahora nos debe bastar comprender que un conjunto de registros es como una base de datos que existe sólo en memoria y que se considera “desconectado” porque no está enlazado con ninguna base de datos real. Los conjuntos de registros desconectados pueden resultar muy útiles para los escritores de secuencias de comandos, en primer lugar porque permiten almacenar en ellos datos WMI y posteriormente ordenar dichos datos en cualquier valor de propiedad que se desee. Muy útil ciertamente; como seguro que sabe, cuando se trata de datos WMI, normalmente se está a merced de cualquier tipo de orden que WMI utilice.

Nota. Entonces ¿cómo se puede obtener información adicional sobre los conjuntos de registros desconectados? Para comenzar recomendamos que consulte esta sección (en inglés) de la guía Microsoft Windows 2000 Scripting Guide.


Aquí se muestra una secuencia de comandos de ejemplo con la que se obtiene una lista de todos los servicios que se ejecutan en un equipo y que posteriormente almacena el nombre y el estado de cada uno de ellos en un conjunto de registros desconectado. Tras crear y rellenar el conjunto de registros, empleamos el método Save para guardar los datos en un archivo XML:

Const adPersistXML = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adFldIsNullable = 32

Set DataList = CreateObject("ADOR.Recordset") DataList.Fields.Append "ServiceName", adVarChar, MaxCharacters, adFldIsNullable DataList.Fields.Append "State", adVarChar, MaxCharacters, adFldIsNullable DataList.Open

strComputer = "." Set objWMIService = GetObject("winmgmts:\" & strComputer& "\root\cimv2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Service") For Each objItem in colItems DataList.AddNew DataList("ServiceName") = objItem.Name DataList("State") = objItem.State DataList.Update Next

DataList.Sort = "ServiceName"

DataList.Save "C:\Scripts\Test.xml", adPersistXML

No se preocupe demasiado por el tamaño de la secuencia; gran parte del código se destina a crear y rellenar el conjunto de registros desconectado. En realidad nos interesan estas dos líneas de código: la primera y la última. En la línea 1 definimos una constante llamada adPersistXML y establecemos su valor como 1; esto indica a la secuencia que deseamos guardar los datos en formato XML:

Const adPersistXML = 1
Nota. ¿Qué ocurre ni no somos entusiastas de XML? ¿podríamos utilizar otro formato? Bien, como alternativa se podría definir una constante llamada adPersistADGT y establecer su valor como 0; con ello podríamos guardar los datos en formato Advanced Data Tablegram, que es un formato de archivo de propietario empleado por los objetos de datos ActiveX (ADO). Sin embargo, siendo fieles a nuestra filosofía, pensamos que XML sería el formato más fácil para la mayoría de usuarios.


En la última línea de la secuencia llamamos al método Save y guardamos los datos:

DataList.Save "C:\Scripts\Test.xml", adPersistXML

Como puede observar, pasamos a Save un par de parámetros: la ruta completa al nuevo archivo XML y la constante adPersistXML. Así de sencillo.

Nota. Bueno, hay que tener precaución con una pequeña cosa: asegúrese de que el archivo Test.xml no existe antes de llamar al método Save. Imagine que Test.xml ya existe y que ejecuta la secuencia de comandos, al llamar a Save la secuencia daría error. Al contrario, imagine que Test.xml no existe y que ejecuta la secuencia. Desde ella puede llamar al método Save (con lo que se crea el archivo) y, posteriormente en la misma secuencia, volver a llamar a Save. Ningún problema: el método Save no cierra el archivo, por lo que puede continuar trabajando con el XML siempre que el archivo esté abierto. Únicamente recibirá un error del tipo “el archivo ya existe” si cierra el archivo XML e intenta sobrescribirlo.


Sabemos lo que está pensando, por supuesto: ¿qué se supone que voy a hacer con un archivo XML? Bueno, he aquí una sugerencia: utilice ADO para abrirlo posteriormente. A continuación se proporciona una secuencia muy simple que abre el archivo Test.xml y envía posteriormente un eco de su contenido:

Set DataList = CreateObject("ADOR.Recordset")
DataList.Open "C:\Scripts\Test.xml"

DataList.MoveFirst Do Until DataList.EOF Wscript.Echo DataList.Fields.Item("ServiceName") _ & " - " & DataList.Fields.Item("State") DataList.MoveNext Loop

Muy fácil, ¿verdad? Crea una instancia del objeto ADOR.Recordset y después llama al método Open, pasando la ruta al archivo XML que desea abrir.

Con suerte esto debe solucionar su problema, RW; si no es así, comuníquenoslo. Después de todo somos muy conscientes de que las cosas se pueden torcer cuando se toma la ruta más sencilla. Por ejemplo, por una trágica equivocación la corbata de nuestro compañero se envió a la lavandería. Se la devolvieron limpia y planchada, pero sin el nudo hecho. Ahora reza para que ninguno de sus amigos o familiares se case o gane un prestigioso premio antes de que tenga la oportunidad de volver a casa y pedirle a su padre que se la vuelva a anudar. (Aunque, teniendo en cuenta todos los aspectos, eso nos sigue pareciendo más sencillo que aprender a anudarla.)


Para más Información

Consulte el Archivo de ¡Hola, chicos del scripting!.

Arriba Arriba