|
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.) |