ADO es lo último de Microsoft en acceso a bases de datos. No se porqué, pero desde su inicio, ADO está como metido en una aureola de dificultad a la que solamente pueden acceder informáticos especialmente elegidos. Quizás sea el uso de palabras de argot muy rebuscadas, que más que facilitar el estudio, atemorizan al principiante. La Guía del Estudiante pretende quitar esos velos que ocultan la sencillez de lo cotidiano y mostrar la facilidad de esta técnica. Con el estilo didáctico que caracteriza a este libro, pasaremos de las definiciones gloriosas e iremos a lo verdaderamente importante: saber programar con ADO\nADO permite crear aplicaciones capaces de manipular bases de datos a través de un proveedor OLE DB (Object Linking and Embedding for DataBase). El objetivo de OLE DB es poner a disposición del programador una herramienta de nivel inferior que le de acceso universal a los datos con independencia del origen de datos, ya sea un servidor de correo electrónico, una hoja de cálculo u otro tipo de almacenamiento de datos. Debido a la complejidad de los elementos de OLE DB, no se puede acceder a ellos directamente desde Visual Basic; para ello utilizaremos los objetos ADO que permiten acceder a la práctica totalidad de las funciones de OLE DB.\nLas características generales de ADO son:\nFig 72.1 Jerarquía de Objetos ADO.\n* Todos los objetos marcados con un asterisco contienen la colección Properties con un subconjunto de objetos Property.\nComo puede verse en la figura, existen tres objetos principales dentro de ADO: El objeto Connection, el objeto Command y el objeto recordset. Luego veremos algunas de las características principales de cada uno de estos objetos.\nAntes de proseguir con estos objetos vamos a explicar donde y porqué se deben utilizar objetos ADO en vez de objetos DAO u objetos RDO\nHasta ahora habíamos utilizado bases de datos Access, y también otras bases de datos sencillas como dBase. Acceder a Access es extremadamente fácil. Y ello es debido a que Access es una base de datos sin grandes aspiraciones en cuanto a seguridad. Es una gran base de datos, y tiene sus dispositivos de seguridad en cuanto a permisos de acceso (Vea El dbEngine. Visión desde DAO y la propiedad SystemDB en el Capítulo 12) sin embargo estas posibilidades se usan en muy pocas ocasiones, y estos mecanismos de seguridad de Access tampoco son una maravilla. Por lo tanto Access se ha quedado como una gran base de datos para aplicaciones que no pasen de algunos centenares de miles de registros y con pocos puestos de operación. En esta base de datos, el método ideal de acceso es DAO, bien directamente o a través de ODBC Direct. Cuando se accede directamente, la BD se suele buscar bien mapeando el disco del servidor como una unidad más del puesto cliente, o bien accediendo a través de la dirección IP del servidor.\nCuando queremos empezar a tener una seguridad en los accesos, disponer de privilegios distintos para cada usuario, trabajar en una red de área local con muchos usuarios, hay que recurrir a bases de datos tipo Oracle o SQLServer. Ya empezamos a tener problemas: Visual Basic no puede acceder directamente a abrir estas bases de datos. Podemos acceder a través de ODBC, pero como ya se dijo en el, capítulo correspondiente, ODBC se ha quedado obsoleto. Y Microsoft ha sacado para ello ADO. Y ADO permite abrir la base de datos usando para ello un dispositivo intermedio que es el proveedor OLE DB. Este no es más que una DLL. Mejor dicho, un juego de DLLs que puede ver en la carpeta:\nC:\_Archivos de Programa\_Archivos Comunes\_System\_Ado\nEstas DLLs permiten conectar con las bases de datos más conocidas (Oracle, SQLServer, Access y las demás BD controladas por el motor Jet). ADO funciona de forma diferente a ODBC. Con ODBC se preparan conexiones permanentes en el ordenador, y cualquier programa puede acceder a la BD a través de esas conexiones. Con ADO no hay que preparar previamente ninguna conexión. Es el propio programa el que llama al proveedor de datos OLE DB y le pasa como parámetros los datos necesarios para que este realice la conexión y abra la BD. Si hubiese dos programas ejecutándose simultáneamente y accediendo a la misma base de datos a través de ADO, cada programa prepara una conexión a esa BD. En ODBC podríamos ver las conexiones existentes en el PC a través del Panel de Control | Fuentes de Datos ODBC. En ADO no existe esa posibilidad ya que, como se ha dicho, es el propio programa quien crea esa conexión al ajecutarse.\nPara que VB pueda acceder a ADO es necesario introducir en el programa la referencia a Microsoft ActiveX Data Objets 2.1 Library (Proyecto|Referencias)\nUna particularidad de ADO frente a lo ya visto con DAO o RDO es que ADO se salta la jerarquía a la hora de crear nuevos objetos. En DAO, el objeto DAO superior creaba al objeto DAO inferior (Recuerde aquello del juego de niños). En ADO podemos crear cada objeto sin que exista el objeto inmediatamente superior. Por ejemplo podemos crear un recordset sin que exista el objeto Connection. Claro que en este caso, a la hora de crear el objeto recordset deberemos indicarle, mediante los parámetros que debemos aportar en la sintaxis de creación del recordset, todos aquellos datos que le aportaríamos a la creación del objeto Connection. Como ve no tiene ventajas. Solamente que nos desentendemos un poco de abrir y cerrar el objeto Connection.\nVeamos como se crea la conexión: Mediante el Objeto Connection\nEl sitio donde se debe declarar depende como siempre, del ámbito que deseamos que tenga ese objeto.\nNota: En el caso de que ejecutemos la aplicación y nos salga un error diciendo que el tipo no está definido por el usuario, es que no hemos añadido la referencia de “Microsoft Actives Data Objects Library x.x”\nLa conexión ¿está creada?. Sí, pero de momento es completamente inútil ya que no sabe ni siquiera que base de datos debe abrir, ni con que usuario, ni las condiciones en las que debe abrir esa base (Solo lectura, etc.) Esta información se la pasamos mediante la propiedad ConnectionString (Cadena de conexión)\nProvider Especifica el nombre del proveedor que se usa en la conexión. (Oracle, SQLServer, Jet, etc)\nData Source Especifica el nombre de la fuente de datos para la conexión. (Nombre de la base de datos a la que se va a acceder.\nUser Id Especifica el nombre de usuario que abre la conexión. Debe ser un usuario ya declarado en la base de datos.\nPassword Especifica la clave utilizada por el usuario para abrir la conexión. Debe coincidir con el que tiene ese usuario registrado en la Base de datos.\nFile Name Especifica el nombre del fichero específico de proveedor, que contiene la información de configuración de la conexión. Este fichero es útil en instalaciones en red que requieran modificaciones de conexión frecuentes.\nRemote Provider Especifica el nombre de un proveedor de datos remoto cuando se utiliza una conexión cliente/servidor\nRemote Server Especifica el nombre del camino al servidor que se va a usar cuando se establece una conexión cliente/servidor\nComo ejemplo para la conexión a una base de datos Oracle, con el usuario que esa BD tiene por defecto (scott) y el Password de este usuario (tiger) tendremos que especificar en el ConnectionString la siguiente cadena de caracteres.\n‘Provider=MSDAORA.1;Password=tiger;User ID=scott;Data Source=MADRID;’\ndonde el valor de Source es la cadena de conexión de Oracle que previamente tiene que estar configurada con el SQL*Net o Net8 de Oracle.\nSi lo que queremos es crear una conexión con una base de datos Access 2000\nSi la base de datos es de Access 97 entonces tendremos que especificar otro provider:\nPara una base de datos SQLServer\n"Provider=SQLOLEDB.1;Password=ayudas01; User ID=ayudas01; Initial Catalog=Ayudas_M; Data Source=ayudas_sql" (en una línea única)\nComo puede comprobar, resulta una tanto complicado construir la cadena de conexión y mientras que seamos novatos en ADO podemos tener problemas para crear esta cadena. ¿Pero es que no existe una manera más fácil de construir esta cadena? Efectivamente. Hay un pequeño truco mediante el cual no solo podemos crearla con un asistente, sino que además probaremos si la conexión es satisfactoria o no.\nTruco para construir la cadena de conexión.\n1) Primero tenemos que incluir el componente “Microsoft ADO data control 6.0 (OLEDB)”. Podemos hacerlo pulsando Ctrl.-T o en el menú Proyecto à Componentes.\n2) Metemos en nuestro formulario el control y pulsamos F4 para ver sus propiedades.\n3) Hacemos Click en la propiedad ConnectionString y nos aparecerá el botón de puntos suspensivos. Hacemos Click en el botón.\n4) Ahora nos aparece el asistente que nos mostrará 3 opciones. Utilizar un DSN de archivo, utilizar un controlador ODBC o utilizar una cadena de conexión. En todos los casos, a la derecha de la opción hay una opción que nos permite seleccionar o generar el origen de los datos. Usaremos la cadena de conexión (opción por defecto) y pulsaremos el botón generar.\n5) Al pulsar el botón generar, nos aparece otra ventana en la que tenemos cuatro pestañas aunque únicamente necesitaremos dos de ellas para crear una cadena de conexión correcta y probada. El resto de las pestañas forman parte de otro capítulo exclusivo del control data de ADO, aunque le invito a que curiosee por ellas. Seleccionaremos el proveedor de datos que queramos utilizar y pulsaremos el botón siguiente para pasar a la siguiente pestaña.\n6) En la Pestaña conexión, tenemos que proporcionar los datos correspondientes al proveedor de la base de datos a la que queremos conectar. Por ejemplo para conectar con una base de datos de tipo MS Access (MS Jet 4.0 OLEDB Provider para la versión 2000 de Access, MS Jet 3.5 OLEDB Provider para la versión 97 de Access), tenemos que decirle el nombre y path de la BD. Para ello podemos utilizar el botón de los puntos suspensivos, que abrirá una ventana que permitirá seleccionar el archivo .mdb . Si utilizamos el proveedor de datos de Oracle, tendremos que indicarle como nombre de servidor la cadena de conexión utilizada en el SQL Net o en el Net8 de Oracle (la misma cadena que especifica cuando se conecta a través de SQL*Plus).\nEn esta pestaña existen dos opciones interesantes:\n· “Contraseña en Blanco”, si la marcamos no nos permitirá teclear la contraseña.\n· “Permitir guardar la contraseña”, dependiendo de si está o no seleccionada, incluirá o no en la cadena de conexión la clave del usuario. Para la primera prueba le recomiendo que la marque. No obstante, haga diferentes pruebas con ellas para ver los resultados.\nDespués de haber dado esta información, pulsaremos el botón Probar conexión. En el caso de que haya algún error, el asistente nos lo indicará con un mensaje.\nPrueba de conexión (fallida) con Proveedor de datos de Oracle\n7) Una vez que hemos probado satisfactoriamente la conexión, pulsaremos aceptar y volveremos a la pantalla inicial, la de las 3 opciones. La diferencia es que ahora tenemos la cadena de conexión rellenada por el asistente. Ahora podemos copiarla con ctrl.-C y llevarla a la parte del código donde queremos establecer la conexión. No se olvide de que es una cadena y que cuando se asigne a la propiedad ConnectionString debe ir entre comillas dobles.\n8) Una vez que hemos probado que funciona al abrir el objeto Connection, No debemos olvidarnos de eliminar el control data de ADO y de quitar el componente de nuestro proyecto, salvo que lo vayamos a utilizar para otra cosa.\nYa conocemos el truco para formar la cadena de conexión y se la hemos introducido en la propiedad ConnectionString ¿Ya está creada la conexión? Sí, pero todavía no sirve para obtener datos de la base de datos. Pero ya hemos avanzado mucho. Ahora nuestro programa ya sabe al menos, como poder abrir esa base de datos, pues conoce su nombre, usuario que la abre y Password. Solamente queda aplicar un método del objeto Connection: el método Open con una sintaxis que no es excesivamente difícil:\nLa conexión se va a realizar a una base de datos que está en un servidor. Este servidor puede definirse, bien por su dirección IP o por su nombre. Lo normal es definirlo por su nombre (Server_SQL_Mae) y no por su dirección IP. Obviamente el nombre del servidor corresponderá a una dirección IP (Vamos a considerar una red IP estática, pues si pretendemos entrar a explicar lo que es una red con direcciones IP asignadas dinámicamente se nos complica la explicación). Esa dirección IP debemos indicársela al PC en el fichero Hosts (o Lmhosts) que están en la carpeta Windows o en una de sus subcarpetas. En estos ficheros explica como hacerlo. No se extrañe si, una vez indicado en ese fichero, sigue sin encontrarlo. La primera conexión con el servidor la busca mediante llamadas broadcast en la red que no siempre son bien tratadas por los routers. En muchas ocasiones he tenido que buscar el servidor a mano (entorno de red) y, milagros de Windows, a partir de esa operación ya lo encuentra sin problemas.\nPara seguir un poco el ejemplo que acompaña a este capítulo, vamos a ver el código utilizado para crear la conexión. En el ejemplo usamos una base de datos Access (No es la mejor para demostrar como funciona ADO, pero es la que los alumnos van a tener con mayor facilidad. Una base Oracle o SQL no se instala fácilmente en un ordenador personal)\n'MiConexion.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\_GuiaDelEstudiante\_ADO\_PruebaADO.mdb;Persist Security Info=False"\nAhora nuestro programa ya está en contacto con la base de datos. Lo que falta ya lo puede suponer: crear un recordset.\nAquí vamos a ver la primera diferencia con DAO. El recordset no lo crea el objeto Connection. Se crea él a sí mismo. Para que pueda existir un objeto Recordset primero hay que declararlo:\nDim MiRecordset As ADODB.Recordset (Hay que declararlo en el sitio adecuado dependiendo del ámbito que necesite)\nEn el procedimiento donde se vaya a crear el recordset, para crearlo utilizaremos la siguiente sintaxis:\nSet MiRecordset = New ADODB.Recordset (Ya está creado. Pero no está abierto, ahora hay que abrirlo)\nMiRecordset.Open "Alumnos", MiConexion, adOpenDynamic, adLockOptimistic\nYa tenemos abierto el recordset. En este caso el recordset está formado por todos los registros con todos sus campos de la tabla Alumnos, que está en la base de datos definida en la conexión MiConexion, es del tipo Dynamic y el bloqueo de escritura es optimista.\nPodríamos elegir ciertos registros, y solamente unos campos. Utilizaríamos una sentencia SQL\nMiRecordset.Open "Select Alumno_Nombre, Alumno_Ape1, Alumno_Ape2 From Alumnos " _\n& “Where Alumno_Nombre = ‘Luis’”, MiConexion, adOpenDynamic, adLockOptimistic\nSi no hubiésemos creado previamente el objeto Connection, podríamos crear y abrir igualmente este objeto recordset, pero, en vez de pasarle el nombre de la conexión (MiConexion) le pasaríamos la cadena de conexión usada para crear ese objeto Connection.\nMiRecordset.Open "Alumnos", "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\_GuiaDelEstudiante\_ADO\_PruebaADO.mdb;Persist Security Info=False", adOpenDynamic, adLockOptimistic\n(Es solamente una línea. Ha sido Word quien la ha troceado)\nAhora ya podemos presentar los campos del recordset, usando la sintaxis que ya conocemos de DAO\nTbNombre = “” & MiRecordset!Alumno_Nombre\nTbApe1 = “” & MiRecordset!Alumno_Ape1\nTbApe2 = “” & MiRecordset!Alumno_Ape2\nHagamos una pequeña pausa. Observe que hay diferencias de trabajar con ADO o hacerlo con DAO.\nDeclarar MiSesion, MiBase y MiRecordset\nDim MiSesion as Workspace\nDim MiRecordset as Recordset\nCrear el objeto Workspace, el objeto DataBase y el objeto Recordset\nSet MiSesion = Workspaces(0)\nSet MiBase = MiSesion.OpenDatabase (“C:\_GuiadelEstudiante\_Alumnos.Mdb”)\nSet MiRecordset = MiBase.OpenRecordset (“Alumnos, dbOpenDynaset)\nCon ADO (Creando el objeto Connection)\nDeclarar MiConexion y MiRecordset\nCrear la conexión y ponerle la cadena de conexión en su propiedad ConnectionString\nMiConexion.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\_GuiaDelEstudiante\_ADO\_PruebaADO.mdb;Persist Security Info=False"\nAbrir el objeto Connection\nCrear el objeto recordset\nAbrir el objeto Recordset\nCon ADO (Sin crear el objeto Connection)\nCrear el Recordset\nObserve siempre que tanto en las declaraciones del objeto Connection y del objeto Recordset, como en su creación, debemos anteponer siempre la palabra ADODB\nTanto el objeto Recordset como el objeto Connection se deberán cerrar cuando ya no se utilicen, o al menos, al cerrar la aplicación. Esto es tanto más necesario cuanto mayor sea la seguridad de la base de datos que vamos a utilizar. En algunas bases de datos, dejar una sesión abierta significa dejar una aplicación zombie ejecutándose en el servidor, que habrá que cerrar desde su propio sistema operativo. Este problema no le va a ocurrir utilizando Access, pero como ya se dijo al principio, Access no es el mejor ejemplo de utilización de ADO. Para cerrar una sesión y un recordset utilizaremos el método Close\nMiSesion.Close (Recuerde que debe cerrar antes el recordset que la conexión)\n¿Qué pasa con el equivalente del Workspace?\nCuando resumíamos en la página anterior el código a usar si usábamos DAO o ADO, parecía (aunque no fuese cierto) que podíamos asimilar estos objetos\nEfectivamente el Workspace no tiene algo que pudiésemos decir “equivalente” en ADO. Esto es debido a que ADO ya considera que el acceso desde los usuarios lo gestiona directamente la base de datos. Recuerde que el Workspace en DAO era una “sesión de trabajo” de la base de datos, donde podíamos asociar un Workspace a cada usuario. ADO ya le pasa a la BD el nombre del usuario y su Password para que la propia base de datos quien autorice a ese usuario.\nAlgunas cosas que le van a ocurrir cuando ya haya creado el recordset.\nEl empleo de bases de datos complejas en cuanto a seguridad nos va a obsequiar con limitaciones a los recordsets que vamos a abrir en ADO. Y además esas sorpresas van a ser distintas si usa uno u otro tipo de base de datos. (nos centraremos solamente en Oracle y SQLServer. Access, con la modestia que le caracteriza, no va a dar ningún problema.)\nLos recordsets abiertos mediante una consulta SQL (aquellos en los que seleccionamos parte de los registros mediante Select … Where van a crearse solo de lectura. Independientemente de los parámetros que le pasemos a la hora de crearlos. La descripción del error va a ser algo así como que el cursor es solamente de lectura. También observará con frecuencia, cuando intente ir a un registro anterior al actual, MiRecordset.MoveFirst, p.e.) que le enviará un error diciendo que el cursor es solamente de avance hacia a delante. Estos efectos los observará también cuando use la instrucción SQL Order By. No hay que arrojar la toalla solamente por esto. Cuando eso ocurra, lo que hay que hacer es volver a crear el recordset de forma que acepte escritura y movimiento hacia atrás. Eso generalmente se logra abriendo el recordset con todos los registros de la tabla, e incluyendo en él todos los campos.\nusar esta otra alternativa:\nPosiblemente necesitemos crear dos recordsets en un mismo procedimiento. Por ejemplo, es muy típico tener que buscar el último registro para ver el último número de un identificador de registro (Alumno_ID) y poner en este campo, al registro que vamos a crear, un número igual a ese más 1. En ese caso, abriríamos el recordset usando la sentencia Order By Alumno_ID. Cuando queramos introducir un nuevo registro mediante:\nMiRecordset.AddNew nos dirá que el cursor (el recordset, para entendernos) es solamente de lectura. La solución es, abrir el recordset con la sintaxis anterior, leer el número de Alunmo_ID, cerrar el recordset, crear otro recordset con el mismo nombre, usando la sintaxis:\nAhora ya nos permitirá usar el método AddNew. Basta con añadir las líneas de código adecuado para introducir los valores en cada campo:\nMiRecordset!Alumno_ID = Valor numérico\nMiRecordset!Alumno_Nombre = Valor string\nNo renuncie nunca a intentar hacer esto. No siempre funciona. Pero esto es mucho más sencillo que introducir los datos “a capón” utilizando la instrucción SQL Insert que ya veremos más adelante. SQLServer es bastante más dócil que Oracle para usar el método AddNew.\nA este respecto, hay que citar la propiedad CursorLocation que veremos más adelante. Si creamos un cursor lado cliente, seguramente nos permitirá utilizar más opciones (entre ellas AddNew) que si lo establecemos de lado servidor. Tenga en cuenta que si usa un cursor lado cliente, el recordset no se actualiza cuando otro usuario realiza modificaciones en la base.\nModificar datos mediante EDIT\nEn ADO no hace falta usar Edit para modificar los datos del registro actual. Edit no existe en ADO. Para modificar un dato basta con poner el mismo código que utilizábamos en DAO, pero sin comenzar por la línea Mirecordset.Edit. Colocándonos en el registro a modificar pondremos:\nMiRecordset!Alumno_Nombre = “Pedro”\nMiRecordset!Alumno_Ape1 = “Perez”\nDe cualquier forma, esto tampoco tiene porque funcionar en todas las bases de datos. En ese caso tendremos que recurrir, al igual que para un registro nuevo, a las instrucciones SQL, que en este caso será Update. Pero ya lo veremos más adelante. Hasta ahora solamente he querido usar el código más simple para que pueda empezar con ADO, y sobre todo, para que vea que esta es una técnica completamente accesible, aunque, dadas las grandes prestaciones que tiene, un poco más adelante se va a complicar algo.\nYa ha visto que podemos trabajar perfectamente con recordsets, tal como lo hemos hecho con el DAO de toda la vida. Pero ya lo comentábamos al principio, parece que hay que adornar lo obvio para que no lo parezca tanto. Y ahí viene el Objeto Command, que como habrá podido ver en la figura de la Jerarquía de los objetos ADO, es un objeto que aún no sabemos lo que hace.\nEl objeto Command lo que va a hacer es crear un recordset. O también, meter “a capón” un nuevo registro, o borrarlo, utilizando directamente instrucciones SQL. Hay que darse cuenta que ADO trabaja con una gran diversidad de bases de datos, y no todas trabajan igual. Por eso, muchas veces fallan operaciones tan sencilla como añadir un nuevo registro con el método AddNew del recordset\nY hay que emplear una instrucción SQL: INSERT\nEn estos casos, en ADO utilizamos el método EXECUTE sobre el objeto Connection. Creamos una variable, StrIntroducir, con el contenido de la instrucción SQL y ejecutábamos esa instrucción mediante Execute\nStrIntroducir = "Insert Into INT_DOCUMENTOS " _\n& "(CL_DOC,NOM_DOC,TITULO_DOC,AUTOR_DOC,CL_TEMA_DOC,CL_DPT_DOC,” _\n& “L_TIPO_DOC,FICH_DOC,FECHA_EMISION_DOC,ULTIMA_HORA_DOC,VISIBLE_DOC)"_ & "Values (" & NumeroDocumento & ",'" & TbTitulo & "','" & TbTitulo & "','" & TbTitulo.Tag _\n& "',19,2,1,'" & HRefPrensa & "/" & TbNombFichTIF & "','" & Date & "',0,1)"\nEsta línea (StrIntroducir) es el contenido de la propiedad CommandText de un objeto Command de ADO. Ni más ni menos que una instrucción que queremos realizar sobre la BD. Un objeto Command tiene pocas cosas más. Como objeto ADO que es tiene sus propiedades y métodos. Pero en esencia es lo que acaba de ver con la instrucción EXECUTE del objeto Connection. Lo que pasa, que ADO lo han hecho muy organizado, y por eso tiene la categoría de Objeto. Es hacer lo mismo, utilizando las mismas expresiones, pero dándole más cuerpo.\nCon la instrucción anterior, lo que hacíamos era añadir un registro. Si lo que queremos hacer es crear un recordset, la instrucción SQL comenzaría por “Select * From ….” Y el método EXECUTE devolvería un Recordset\nStrIntroducir = “Select * From Alumnos Where Apellido1 = ‘Suarez’”\nPodemos crear un recordset (MiRecordset, previamente declarado como tal) con esta instrucción\nMiRecordset = ConexBDPrensa.Execute StrIntroducir\nO con estas otras\nSet MiComando as New ADODB.Command\nMiComando.ActiveConnection = ConexBDPrensa\nMiComando.CommandText = “Select * From Alumnos Where Apellido1 = ‘Suarez’”\nMiRecordset = MiComando.Execute\nVerá el ejemplo completo al final del capítulo.\nAhora, tras la explicación informal de cómo se crea una conexión y un recordset en ADO, y que es un Command, vamos a entrar a conocer sus propiedades y métodos. Al final, y con un buen ejemplo realizado de varias formas, entenderá perfectamente la forma de trabajar con ADO.\nUn objeto Connection representa una conexión abierta con un origen de datos. Ya hemos visto como crear un objeto Connection, por lo que vamos a pasar directamente a ver sus objetos, colecciones, propiedades y métodos.\nComo puede verse en la figura, el Objeto Connection tienen los objetos Command y Recordset, y la colección Errors.\nEl Objeto Recordset es el recordset de toda la vida: un conjunto de registros que contienen datos. El Objeto Recordset, aunque pertenece al objeto Connection, puede crearse sin que exista previamente un objeto Connection. Esta es una de las propiedades de los objetos ADO: no necesita cumplir estrictamente con la jerarquía.\nEl Objeto Command es una definición de un comando específico que se piensa ejecutar contra un origen de datos. Los objetos Command sirven para tener almacenadas operaciones de acceso a datos y usarlas en el momento adecuado, simplemente citándolas. Lo que obtenemos de un objeto Command es, o un recordset (verá que no merece la pena usar un objeto Command para crear un recordset, puesto que se pueden crear directamente) o una operación que afecte a los registros de la base de datos (añadir registros, borrarlos, si es que no se deja hacer eso mediante recordsets)\nLa Colección Errors es el conjunto de errores generados por el proveedor de datos ante el fallo de una operación de acceso. La colección Errors se refiere únicamente a los errores generados por el proveedor, no a los fallos interceptables producidos por el programa, que deben ser tratados de la forma habitual: mediante Err\nPropiedades del Objeto Connection (Lea esto de las propiedades sin complicarse demasiado la vida. Las realmente importantes verá que están advertidas debidamente)\nLas propiedades del objeto Connection dependen de cada proveedor. No todos se comportan de igual forma, por lo que cada propiedad debe condicionarse a si el proveedor es capaz de ofrecerla.\nEs un Long. Acepta dos valores o la suma de los dos:\nEstos atributos condicionan el modo de operación de la conexión con los métodos CommitTrans y RollBackTrans.\nIndica, en segundos, el intervalo de espera para que se ejecute un comando (Objeto Command) antes de que finalice el intento y se genere un error. Es un Long. El valor predeterminado es 30.\nIndica, en segundos, el intervalo de espera para establecer una conexión antes de que finalice el intento y se genere un error. Es un Long y el valor predeterminado es 15.\nPropiedad ConnectionString (IMPORTANTE)\nEs una cadena de caracteres que contiene la información que se utiliza para establecer una conexión a un origen de datos. (Vea la explicación amplia más atrás)\nLa cadena de conexión tiene varios argumentos, todos ellos separados por un punto y coma (;) de la forma\nargumento1 = valor; argumento2 = valor; argumento3 = valor etc.\nADO procesa solamente cuatro argumentos: Provider, File Name, Remote Provider y Remote Server. Los demás argumentos los pasa al proveedor para que el los procese (Usuario, Password, etc)\nSi al emplear el método Open se utiliza el parámetro Connection String, este parámetro utilizado en el método Open sustituirá a cualquier otro existente anteriormente. Una vez abierta la conexión, esta propiedad no se puede cambiar puesto que es solamente de lectura.\nLos argumentos File Name y Provider son excluyentes.\nPropiedad CursorLocation (IMPORTANTE)\nEstablece o devuelve la posición de un servicio de cursores. Es un Long, y acepta las siguientes constantes:\nAdUseNone No se usan servicios de cursor. (Esta constante es obsoleta y aparece únicamente por compatibilidad con versiones anteriores.)\nAdUseClient Usa cursores del lado del cliente.\nAdUseServer Predeterminado. Usa cursores del lado servidor.\nEsta propiedad parece que no dice nada. Y es sumamente importante.\nLos cursores son, por decirlo de alguna manera, los mecanismos de la base de datos donde se crean los recordsets. Se estará dando cuenta que las bases de datos que tienen cursores son ya bases de datos con mecanismos propios para la creación de recordsets. (SQL Server u Oracle, p.e.) Estas bases de datos trabajan como aplicaciones cliente – servidor. Tienen en el servidor, aparte de los datos, la mayoría de sus recursos. En el cliente tienen prácticamente los recursos de conectividad, y poco más. Esta conectividad permite enviar desde el cliente una petición a la base de datos alojada en el servidor. Esa petición será el resultado por ejemplo, de una sentencia SQL. Al recibirla el servidor, gestionará la obtención de los resultados y una vez que los haya conseguido viene su primera duda: ¿Dónde los almaceno? Puede almacenarlos en el servidor, y cada vez que necesitemos un nuevo registro, por ejemplo al ejecutar la sentencia MiRecordset.MoveNext, el cliente se lo indica al servidor y este le envía el nuevo registro. También puede almacenar los datos obtenidos en el cliente, y de esta forma el cliente puede moverse con entera libertad a lo largo de los registros del recordset. Puede hasta contarlos y saber en que posición está. La diferencia entre uno y otro sistema es que en el primer caso el tráfico por la red es mínimo (solamente se envía la información estrictamente necesaria) y en el segundo caso, se envía mucha información de un golpe, la correspondiente a todos los registros del recordset, independientemente de si se va a usar en el servidor o no.\nConsiderando el tráfico generado, parece que es mejor crear los cursores en el lado servidor. Pero esto trae también sus dificultades. Nos priva de muchas propiedades del recordset. Una propiedad muy usada, AbsolutePosition, no la tienen los cursores de lado servidor, circunstancia que no nos debe sorprender, ya que al no estar todos los registros en el cliente, éste, aunque disponga de todos los datos guardados en todos los campos de un determinado registro, no puede saber que posición ocupa ese registro dentro de la totalidad de registros del recordset. Por lo tanto, usar cursores de lado cliente o lado servidor será siempre una decisión a tomar dependiendo de la velocidad de la red, de la memoria disponible en el cliente, de la complejidad del programa, etc.\nRecuerde que por defecto, ADO crea cursores de lado servidor. Para que la conexión le cree todos los cursores de lado cliente basta ejecutar la instrucción:\nSi desea hacer transacciones, deberá crear cursores del lado servidor, ya que los de lado cliente no las admiten. Comprenderá según vaya programando y encontrándose con problemas, que esta propiedad es absolutamente importante.\nEste valor debe establecerlo antes de crear la conexión. De esta forma, todos los cursores creados con esa conexión serán de lado cliente o lado servidor, según haya elegido. Pero muchas veces sería ideal que unos recordsets tuvieran el cursor de un tipo y otros de otro. Los recordsets también tienen esta propiedad, por lo que puede elegir el lado deseado para cada recordset utilizando esta propiedad aplicada no a la conexión, sino al recordset.\nEl número de registros que el servidor envía al cliente, cuando el cursor es de lado servidor, se controla mediante la propiedad CacheSize del recordset. Lo verá más adelante.\nEstablece la base de datos predeterminada para un objeto Connection. Es un string con el nombre de la base de datos por defecto de esa conexión. Solamente es válida con aquellos proveedores que permiten varias bases de datos por conexión.\nEsta propiedad afecta al comportamiento de un objeto Connection durante una transacción. Una vez establecida esta propiedad, solamente será efectiva cuando se invoque el método BeguinTrans. Vea la ayuda para mayor información de los valores posibles.\nEstablece los permisos disponibles para modificar datos en un objeto Connection.\nAdModeUnknown Predeterminada. Indica que los permisos no se han establecido aún o que no se pueden determinar.\nAdModeRead Indica que son permisos de sólo lectura.\nAdModeWrite Indica que son permisos de sólo escritura.\nAdModeReadWrite Indica que son permisos de lectura/escritura.\nAdModeShareDenyRead Impide que otros abran una conexión con permisos de lectura.\nAdModeShareDenyWrite Impide que otros abran una conexión con permisos de escritura.\nAdModeShareExclusive Impide que otros abran una conexión.\nAdModeShareDenyNone Impide que otros abran una conexión con cualquier tipo de permiso.\nSólo puede establecer la propiedad Mode cuando el objeto Connection está cerrado. Cuando se usa en un objeto Connection del lado del cliente, la propiedad Mode sólo se puede establecer a adModeUnknown.\nEs un string que indica el nombre del proveedor de un objeto Connection. Si no se especifica ningún proveedor, la propiedad tendrá el valor predeterminado MSDASQL (Proveedor de Microsoft OLE DB para ODBC).\nDevuelve el estado del objeto Connection: abierto (adStateOpen = 1) o cerrado (adStateClosed = 0).\nDevuelve el número de versión de ADO. Es un String.\nMétodos del Objeto Connection\nMétodos BeginTrans, CommitTrans y RollbackTrans\nEstos métodos de transacción administran el proceso de la transacción dentro de un objeto Connection de la forma siguiente:\n· BeginTrans: inicia una nueva transacción.\n· CommitTrans: guarda las modificaciones y termina la transacción actual. También puede iniciar una nueva transacción.\n· RollbackTrans: cancela las modificaciones efectuadas durante la transacción actual y termina la transacción. También puede iniciar una nueva transacción.\nDespués de invocar el método BeginTrans, el proveedor ya no aplicará inmediatamente las modificaciones hasta que invoque CommitTrans o RollbackTrans para terminar la transacción. Los métodos BeginTrans, CommitTrans y RollbackTrans no están disponibles en los objetos Connection del lado del cliente.\nCancela la ejecución de una llamada asíncrona pendiente a un método Execute u Open.\nEl método Cancel se utiliza para terminar la ejecución de una llamada asíncrona a un método Execute o Open (es decir, el método fue invocado con la opción adAsyncConnect, adAsyncExecute o adAsyncFetch). Cancel devolverá un error de ejecución si no se utilizó adAsyncExecute en el método que quiere terminar.\nCierra el objeto Connection.\nEl cierre de un objeto Connection mientras hay objetos Recordset abiertos en la conexión cancela las modificaciones pendientes en todos los objetos Recordset. El cierre explícito de un objeto Connection (llamando a su método Close) mientras una transacción está en progreso genera un error. Si un objeto Connection cae fuera del alcance mientras la transacción está en progreso, ADO cancela automáticamente la transacción.\nEl cierre de un objeto Connection no lo elimina de la memoria; puede modificar los valores de sus propiedades y volver a abrirlo más tarde. Para eliminar completamente un objeto de la memoria, establezca la variable de objeto a Nothing.\nSet NombredelObjetoConnection = Nothing\nMétodo Execute (Vea también Método Execute para el objeto Command)\nEjecuta una consulta, instrucción SQL, procedimiento almacenado especificados o texto específico del proveedor.\nSintaxis (Para una cadena de comando que no devuelva filas):\nconexión.Execute CommandText, RecordsAffected, Options\n(Para una cadena de comando que devuelva filas):\nSet MiRecordset = connection.Execute (CommandText, RecordsAffected, Options)\n(MiRecordset debe ser una variable declarada tipo ADODB.Recordset)\nCommandText Es un String que contiene la instrucción SQL, el nombre de la tabla, el procedimiento almacenado o el texto específico del proveedor que se va a ejecutar.\nRecordsAffected Opcional. Una variable Long en la que el proveedor devuelve el número de registros afectados por la operación.\nOptions Opcional. Una constante o valor Long que indica cómo debe evaluar el proveedor el argumento CommandText. Puede ser uno de los siguientes valores.\nIndica que el proveedor tiene que evaluar CommandText como definición textual de un comando, como una instrucción SQL.\nIndica que ADO tiene que generar una consulta SQL para devolver todas las filas de la tabla mencionada en CommandText.\nIndica que el proveedor tiene que devolver todas las filas de la tabla mencionada en CommandText.\nIndica que el proveedor tiene que evaluar CommandText como procedimiento almacenado.\nIndica que el tipo de comando en CommandText es desconocido.\nIndica que el comando se tiene que ejecutar de forma asíncrona.\nIndica que el resto de las filas siguientes a la cantidad inicial especificada en la propiedad CacheSize tiene que ser recuperada de forma asíncrona.\nCuando esta operación termina se genera el evento ExecuteComplete.\nMétodo Open (IMPORTANTE)\nAbre una conexión a un origen de datos.\nSintaxis MiConnection.Open ConnectionSTring, UserID, Password, Options\nLos parámetros ConnectionSTring, UserID, Password, Options puede introducirlos previamente a abrir la conexión, y utilizar la segunda sintaxis cuando desee abrirla realmente. Estos parámetros se le pasan en la cadena de conexión:\nConexBDPrensa.ConnectionString = "Provider=MSDAORA.1;User ID=INTRANET;” & _\n“Password=INTRANET;Data Source=intranet;Persist Security Info=False"\nOptions Opcional. Puede ser una de las constantes siguientes:\nAdConnectUnspecified Abre la conexión de forma sincronía\nAdAsyncConnect Abre la conexión de forma asíncrona\nCuando se usa un objeto Connection del lado del cliente, el método Open no establece realmente una conexión con el servidor hasta que se abre un Recordset del objeto Connection.\nContiene todos los objetos Error creados en respuesta a un único fallo relacionado con el proveedor. Cada objeto Error representa un error específico del proveedor, no un error ADO. Los errores ADO se exponen al mecanismo de control de excepciones en tiempo de ejecución. Por ejemplo, en Microsoft Visual Basic, cuando ocurre un error específico de ADO dispara un evento On Error y aparece en el objeto Err.\nCuando otra operación ADO genera un error, se borra la colección Errors y el nuevo conjunto de objetos Error se coloca en la colección Errors. Las operaciones ADO que no generan un error no tienen ningún efecto sobre la colección Errors. Para borrar manualmente la colección Errors utilice el método Clear.\nCada objeto Error de la colección, nos dará información sobre un error producido en la conexión. Sus propiedades son las siguientes:\nDescription: Contiene la descripción del error producido (String).\nNativeError: Indica el error devuelto por la base de datos (Long).\nNumber: Es el código de error (Long).\nSource: Indica el nombre del objeto o aplicación que ha generado el error (String).\nSQLState: Indica el error SQL estándar asociado.(String).\nDebido a que este objeto será de gran utilidad a continuación se incluye un ejemplo de su uso.\nEjemplo del tratamiento de errores:\nComo puede observarse, algunas de las propiedades no devuelven los valores esperados: NativeError vale 0 cuando debería valer –1017, que es el error asociado de Oracle. Aún así podemos capturar el código del error desde la cadena de caracteres description. Con este comentario se pretende sugerir que se realicen pruebas con el proveedor de datos que vayamos a utilizar para conocer su comportamiento respecto a este objeto error y dónde nos devuelve los códigos.\nObservese en el código que la declaración de MiError se hace con ADODB.Error\nEs el conjunto de objetos Property\nUn objeto Property representa una característica dinámica de un objeto ADO que está definida por el proveedor.\nLos objetos ADO tienen dos tipos de propiedades: intrínsecas y dinámicas.\nLas propiedades intrínsecas son aquellas propiedades implementadas en ADO e inmediatamente disponibles para cualquier nuevo objeto, utilizando la sintaxis Objeto.Propiedad. No aparecen como objetos Property en la colección Properties de un objeto, de forma que aunque puede modificar sus valores, no puede modificar sus características.\nLas propiedades dinámicas están definidas por el proveedor de los datos y aparecen en la colección Properties del objeto ADO apropiado. Por ejemplo, una propiedad específica del proveedor puede indicar si un objeto Recordset acepta transacciones o actualizaciones. Estas propiedades adicionales aparecerán como objetos Property en la colección Propiedades de dicho objeto Recordset. A las propiedades dinámicas se les puede hacer referencia sólo a través de la colección, utilizando la sintaxis Objeto.Properties(0) u Objeto.Properties("Name").\nUn objeto Property dinámico tiene cuatro propiedades incorporadas propias:\n· La propiedad Name es una cadena que identifica la propiedad.\n· La propiedad Type es un entero que especifica el tipo de datos de la propiedad.\n· La propiedad Value es un variant que contiene el valor de la propiedad.\n· La propiedad Attributes es un valor Long que indica características de la propiedad específicas del proveedor.\nEl objeto Recordset representa un conjunto de registros. El recordset en ADO puede crearse abriéndolo, tomando todos los registros de una tabla o seleccionándolos con una consulta SQL, o ejecutando un comando que contienen el nombre de esa tabla o la consulta. En un momento determinado, el objeto Recordset sólo hace referencia a un único registro dentro del conjunto de registros, llamado registro actual.\nEl recordset de ADO tiene propiedades iguales al recordset de DAO, pero tienen otras que no tienen el de DAO. Se van a estudiar todas, profundizando más en las que son particulares del recordset ADO.\nPropiedad AbsolutePosition (ADO)\nEspecifica la posición ordinal del registro actual de un objeto Recordset. Esta propiedad devuelve un Long con el número de orden del registro. Es posible que el recordset no acepte esta propiedad, dependiendo del proveedor de datos, y del tipo de cursor (lado cliente o lado servidor. El cursor tipo lado servidor no permite esta propiedad) Esta propiedad devolverá 1 cuando el registro actual sea el primer registro del recordset.\nPropiedades BOF y EOF\nIndican si la posición del puntero del Recordset está apuntando a un registro anterior al primero (BOF = True) o posterior al último (EOF = True). Esta propiedad siempre la podremos mirar, independientemente si el cursor es lado cliente o lado servidor.\nPropiedad ActiveConnection (ADO)\nIndica a qué objeto Connection pertenece actualmente el objeto Recordset especificado. Devuelve un string con el nombre del objeto Connection.\nDevuelve un marcador que identifica unívocamente al registro actual de un objeto Recordset o establece el registro actual de un objeto Recordset al registro identificado por un marcador válido. El valor del Bookmark hay que introducirlo en una variable tipo Variant.\nLa propiedad Bookmark solo podrá establecerse cuando el proveedor lo permita. Puede utilizarse el método Supports para averiguarlo. Cuando el recordset es de lado cliente, siempre está disponible el Bookmark.\nIndica el número de registros del objeto Recordset que están en la memoria caché local. Es un Long de lectura y escritura. El valor predeterminado es 1.\nEsta propiedad nos permite conocer cuantos registros están en la memoria local. Si ponemos esta propiedad por ejemplo a 10, al abrir la primera vez el objeto Recordset, el proveedor recupera los 10 primeros registros en la memoria local. A medida que se desplaza por el objeto Recordset, el proveedor devuelve los datos desde el búfer de memoria local. Tan pronto como pasa del último registro de la memoria caché, el proveedor recupera los 10 registros siguientes desde el origen de datos y los carga en la memoria caché.\nLos registros recuperados desde la memoria caché no reflejan los cambios concurrentes que hagan otros usuarios en el origen de datos. Para forzar una actualización de todos los datos en la memoria caché, debe usarse el método Resync.\nIndica el número máximo de registros que se devuelven a un Recordset desde una consulta. Es un Long y el valor predeterminado es 0, que significa sin límite (Obtienen todos los registros). Esta propiedad es de lectura y escritura cuando el recordset está cerrado, y solamente de lectura cuando está abierto.\nEsta propiedad debe usarse solamente cuando se prevé que se pueden obtener un número muy grande de registros. Es prudente tomar medidas frente a aquellas operaciones en las que el ordenador pueda meterse en un proceso excesivamente largo o que ocupe más recursos de los disponibles. Estas cosas son las que suelen “colgar” al ordenador y en las que es muy frecuente echarle luego la culpa a Windows Si estamos frente a una base de datos con todos los datos de los afiliados a la Seguridad Social, no es del todo prudente crear un recordset mediante esta sentencia:\nSELECT * From Afiliados Where Apellido1 = ‘Fernandez’\nIncluso las hay peores:\nSELECT * From Afiliados\nA nadie se le ocurriría, pero puede surgir involuntariamente cuando ese acceso se realiza desde un puesto de operación público (Acceso desde Internet por ejemplo). Con la propiedad MaxRecords puede limitar el número de registros obtenidos. Posiblemente no llegue a obtener el dato deseado, y se vea en la obligación de realizar la misma consulta sucesivas veces hasta encontrarlo.\nEstablece o devuelve la posición de un servicio de cursores. Es idéntica a la propiedad del mismo nombre vista más atrás con todo detalle para el objeto Connection.\nIndica el tipo de cursor que se usa en un objeto Recordset. Es de lectura y escritura si el recordset está cerrado, y solo de lectura si está abierto. Puede tomar uno de los siguientes valores:\nAdOpenForwardOnly Predeterminado. Idéntico a un cursor estático, excepto sólo permite desplazarse hacia delante en los registros. Esto mejora el rendimiento en situaciones en las que sólo se quiere pasar una vez por cada registro.\nEn muchas ocasiones es necesario moverse por el recordset hacia delante y hacia atrás. Este tipo de cursor solamente permite moverse hacia delante. Tenga presente que este es el tipo predeterminado.\nAdOpenKeyset Cursor de conjunto de claves. Igual que un cursor dinámico, excepto que no se pueden ver los registros que agregan otros usuarios, aunque los registros que otros usuarios eliminan son inaccesibles desde su conjunto de registros. Los cambios que otros usuarios hacen en los datos permanecen visibles.\nAdOpenDynamic Cursor dinámico. Las incorporaciones, cambios y eliminaciones que hacen otros usuarios permanecen visibles, y se admiten todo tipo de movimientos entre registros, a excepción de los marcadores si el proveedor no los admite. Es el equivalente en DAO al tipo Dynaset\nAdOpenStatic Cursor estático. Una copia estática de un conjunto de registros que se puede usar para buscar datos o generar informes. Las incorporaciones, cambios o eliminaciones que hacen otros usuarios no son visibles. Es el equivalente en DAO al tipo Snapshot\nNOTA. Si un proveedor no admite el tipo de cursor solicitado, el proveedor puede que devuelva otro tipo de cursor. La propiedad CursorType cambiará para coincidir con el tipo de cursor en uso cuando el objeto Recordset se abra. Para comprobar la funcionalidad específica del cursor devuelto, use el método Supports. Cuando cierre el Recordset, la propiedad CursorType volverá a su configuración original.\nIndica el tipo de bloqueo que se pone en los registros durante el proceso de edición. Establece también si el recordset se actualiza registro a registro o por lotes. Este último sistema permite realizar varios cambios en el recordset y mantenerlos en la caché durante cierto tiempo, y proceder a la actualización de todos los cambios pendientes en una sola operación. Esto es muy importante cuando se está trabajando con una base de datos situada en un servidor con un acceso lento (conexión vía Internet, por ejemplo)\nLos valores de la propiedad LockType pueden ser:\nAdLockReadOnly Predeterminado. Sólo lectura—no puede modificar los datos\nAdLockPessimistic Bloqueo pesimista, registro a registro: el proveedor hace lo necesario para asegurar la modificación correcta de los registros, generalmente bloqueando registros en el origen de datos durante todo el proceso de modificación. Este valor solamente es válido si el cursor (Propiedad CursorLocation) esta establecido a lado servidor.\nAdLockOptimistic Bloqueo optimista, registro a registro: el proveedor usa bloqueo optimista, bloqueando registros sólo cuando llama al método Update.\nAdLockBatchOptimistic Actualizaciones optimistas por lotes: requerido para el modo de actualización por lotes como contraposición al modo de actualización inmediata.\nIndica el estado de modificación del registro actual. Es solamente de lectura. Devuelve uno de las siguientes constantes:\nAdEditNone Indica que no hay ninguna operación de modificación en ejecución.\nAdEditInProgress Indica que los datos del registro actual se han modificado pero que no se han guardado.\nAdEditAdd Indica que se ha invocado el método AddNew y que el registro situado actualmente en el búfer de copia es un nuevo registro que no se ha guardado en la base de datos.\nAdEditDelete Indica que el registro actual se ha eliminado.\nEsta propiedad solamente la tienen los recordset ADO. Y es que ADO presupone que está obteniendo datos de una base de datos alojada en un servidor y que la comunicación entre servidor y cliente puede ser especialmente lenta. Mediante Filter puede descartar registros que no cumplan una determinada condición. En realidad lo que hacemos mediante Filter es crear un nuevo Recordset a partir de otro Recordset.\nLa propiedad Filter se utiliza también para actuar sobre determinados registros en varios métodos del recordset (Resync, Save, …) pero no se va a explicar en este manual la explicación de la utilización de esta propiedad en esos métodos, ya que el nivel del programador que utiliza esos recursos debe ser elevado. Le reservamos por tanto la posibilidad de conocerlo directamente desde la ayuda de Visual Basic, que en este caso es bastante buena.\nDe momento lo que vamos a hacer con Filter es crear un nuevo recordset ¿Por qué no creamos directamente el nuevo recordset utilizando una sentencia SQL que lleve implícito ese filtro?\nPersonalmente no me gusta utilizar la propiedad Filter, y prefiero crear un nuevo recordset. Creo que solamente lo he usado para rellenar un MSHFlexGrid con parte de los datos del recordset que uso en una parte de la aplicación. Veamos un ejemplo:\n(MiConexion es una conexión ya creada)\nDim RsInicial As ADODB.Recordset\nDim RsFiltrado As ADODB.Recordset\nSet RsInicial = New ADODB.Recordset\nSet RsFiltrado = New ADODB.Recordset\nRsInicial.Open "Autores", MiConexion, adOpenDynamic, adLockOptimistic\n‘Este es el recordset que uso para muchas cosas dentro de la aplicación. Ahora quiero presentar en un MSHFlexGrid solamente los datos de los autores de nacionalidad española. Filtro el recordset anterior utilizando un criterio de igualdad de un campo: Nacionalidad\nRsFiltrado = RsInicial.Filter (“Nacionalidad = ‘Española’”)\n‘Ahora ya podemos aplicar este recordset al MSHFlexGrid:\nSet MSHFlexG1.Recordset = RsFiltrado\n‘Y cuando queremos presentar todos los autores, basta con poner la línea:\nSet MSHFlexG1.Recordset = RsInicial\nEste es el único ejemplo que puedo sacar de todas mis aplicaciones. Seguro que el alumno va a ver más aplicaciones de esta propiedad.\nLa propiedad Filter puede mostrar también aquellos registros que han sido manipulados recientemente, mediante las constantes siguientes:\nAdFilterNone Quita el filtro actual y vuelve a poner todos los registros a la\nAdFilterPendingRecords Permite ver sólo los registros que han cambiado, pero que no han sido enviados aún al servidor. Aplicable sólo para el modo de actualización por lotes.\nAdFilterAffectedRecords Permite ver sólo los registros afectados por la última llamada a Delete, Resync, UpdateBatch o CancelBatch\nAdFilterFetchedRecords Permite ver los registros de la caché actual, es decir, los resultados de la última llamada para recuperar registros de la base de datos\nAdFilterConflictingRecords Permite ver los registros que fallaron en el último intento de actualización por lotes.\nIndica el nombre del índice que se utiliza actualmente en el Recordset. Es un String con el nombre del índice.\nEl índice se utiliza para moverse a lo largo del recordset mediante el método Move. El índice ya debe estar creado en la tabla de la base de datos.\nAl utilizar un índice, el orden de los registros se cambia al orden establecido en ese índice. Por lo tanto, los valores obtenidos anteriormente por la propiedad AbsolutePosition cambiarán completamente.\nNo todos los proveedores de datos aceptan la propiedad Index. Puede comprobarlo mediante el método Supports.\nEsta propiedad se usa cuando estamos trabajando con cursores lado cliente. En este caso, como vimos más atrás, los registros del recordset están en el equipo cliente. Todas las operaciones realizadas sobre el recordset se realizan en el cliente, por lo tanto llegará el momento en que habrá que actualizar en el servidor los datos que hayamos modificado en el recordset que está en el equipo cliente. Mediante esta propiedad podemos hacer que se envíen al servidor todos los registros (filas) o solamente los que han cambiado. Acepta estas dos constantes:\nAdMarshalAll Predeterminada. Indica que todos los registros se devuelven al servidor.\nAdMarshalModifiedOnly Indica que sólo los registros modificados se devuelven al servidor.\nEsta propiedad puede mejorar el rendimiento de la aplicación para aquellos casos en los que se use un canal de comunicación lento.\nIndica cuántos registros constituyen una página del objeto Recordset. Es de lectura y escritura. Devuelve un Long y su valor predeterminado es 10.\nEsta propiedad permite determinar cuántos registros componen una página lógica de datos. Al establecer un tamaño de página, puede utilizar la propiedad AbsolutePage y se moverá al primer registro de una página específica. Esto es útil en las situaciones de servidor Web cuando se desea permitir que el usuario pase páginas de datos y vea cierto número de registros al mismo tiempo. Esta propiedad se puede establecer en cualquier momento y su valor se utilizará para calcular la ubicación del primer registro de una página específica.\nIndica cuántas páginas de datos contiene el objeto Recordset. Es solamente de lectura. Devuelve un Long. Si el objeto Recordset no admite esta propiedad, el valor será -1 para indicar que no se puede determinar el valor de PageCount.\nEspecifica en qué página reside el registro actual. Es de lectura y escritura. Devuelve un Long o una de las siguientes constantes:\nAdPosUnknown El objeto Recordset está vacío, la posición actual se desconoce o el proveedor no admite la propiedad AbsolutePage.\nAdPosBOF El puntero del registro actual está al comienzo del archivo (es decir, la propiedad BOF tiene el valor True).\nAdPosEOF El puntero del registro actual está al final del archivo (es decir, la propiedad EOF tiene el valor True).\nIndica el número actual de registros de un objeto Recordset. Devuelve un Long\nEs posible que esta propiedad no la permita el proveedor de datos, o que no pueda llegar a averiguarse, ya que dependiendo del tipo de cursor utilizado puede que no suministre ese dato.\nDevuelve la tabla, consulta o sentencia SQL utilizado en el método Open para crear el recordset. Es un String.\nIndica el estado (abierto, cerrado, proceso de ejecución) en el que se encuentra el recordset. Devuelve uno de los siguientes valores:\nValor predeterminado. Indica que el objeto está cerrado.\nIndica que el objeto está abierto.\nIndica que el objeto Recordset se está conectando.\nIndica que el objeto Recordset está ejecutando un comando.\nIndica que se está obteniendo el conjunto de filas del objeto Recordset.\nPuede tener una combinación de valores. Por ejemplo, si se está ejecutando una instrucción, esta propiedad tendrá un valor combinado de adStateOpen y adStateExecuting.\nEsta propiedad se refiere al registro actual. Indica el estado de este registro respecto a las operaciones de actualización por lotes u otras operaciones masivas. No es una propiedad que se use todos los días. Vea la ayuda para mas detalles.\nPropiedades dinámicas del objeto recordset\nLas propiedades anteriores se refieren a propiedades del recordset que se refieren a unas características propias del recordset una vez creado. Son estas:\nUnique Table, Unique Schema y Unique Catalog\nUnique Table especifica la tabla sobre la que se permite realizar modificaciones de datos (Insertar o actualizar), en el caso de que el recordset se haya creado mediante una operación JOIN\nUnique Schema indica el nombre del propietario de la tabla\nUnique Catalog indica el nombre de la base de datos a la que pertenece la tabla. Estas dos últimas propiedades deben tener un valor para poder poner valor a la propiedad Unique Table. Estas propiedades son tipo String\nEstas propiedades dinámicas se anexan a la colección Properties del objeto Recordset al asignar el valor adUseClient a la propiedad Cursor Location.\nMétodos del objeto Recordset de ADO\nEste método es muy útil para ver si un recordset acepta una determinada funcionalidad. Devuelve un Booleano y es solamente de lectura. De esta forma puede consultar si un recordset admite el método MoveFirst, la propiedad AbsolutePosition, Bookmark, etc., antes de invocar ese método o leer esa propiedad, y evitar de esta forma un error en la ejecución. Esto es muy útil habida cuenta que no todos los proveedores funcionan de la misma forma. Es por lo tanto muy prudente consultar si el Recordset soporta una funcionalidad antes de pedírsela.\nEstas funcionalidades se le pasan como parámetro mediante una de las siguientes constantes:\nAdAddNew Puede usar el método AddNew para agregar nuevos registros.\nAdApproxPosition Puede leer y establecer las propiedades AbsolutePosition y AbsolutePage.\nAdBookmark Puede usar la propiedad Bookmark para tener acceso a registros específicos\nAdDelete Puede usar el método Delete para eliminar registros.\nAdHoldRecords Puede recuperar más registros o cambiar la posición de recuperación siguiente sin efectuar todos los cambios pendientes.\nAdMovePrevious Puede usar los métodos MoveFirst y MovePrevious, y los métodos Move o GetRows para desplazar hacia atrás la posición del registro actual sin que se requiera marcadores.\nAdResync Puede usar el método Resync para actualizar el cursor con los datos visibles en la base de datos subyacente.\nAdUpdate Puede usar el método Update para modificar datos existentes.\nAdUpdateBatch Puede usar actualización por lotes (métodos UpdateBatch y CancelBatch) para transmitir grupos de cambios al proveedor.\nAdIndex Puede utilizar la propiedad Index para dar nombre a un índice.\nAdSeek Puede utilizar el método Seek para encontrar una fila en un Recordset.\nEn este ejemplo vemos la sintaxis de Supports:\nIf RsSeg.Supports(adApproxPosition) = True Then\nNota Aunque el método Supports puede devolver True para una funcionalidad determinada, eso no garantiza que el proveedor pueda hacer que la característica esté disponible bajo cualquier circunstancia. El método Supports devuelve simplemente si el proveedor puede admitir la funcionalidad especificada, dando por supuesto que se reúnen determinadas condiciones. Por ejemplo, el método Supports puede indicar que un objeto Recordset admite actualizaciones aunque el cursor se base en una unión de múltiples tablas, de las que algunas columnas no son actualizables.\nEl valor devuelto por el método Supports dependerá del tipo de recordset elegido. En la siguiente tabla puede ver el tipo de recordset y las constantes para las que va a devolver True:\nEs el método que ABRE el recordset. Este método es el que busca los registros que han de rellenar el recordset.\nSintaxis. Esta es la sintaxis general:\nMiRecordset.Open Source, ActiveConnection, CursorType, LockType, Options\nUn recordset puede abrirse partiendo de una conexión ya abierta. Pero también puede crearse directamente, sin abrir previamente la conexión. Al final, deberá aportar todos los datos necesarios para determinar en que base de datos se abre ese recordset. Sobre que tabla, consulta o sentencia SQL., que tipo de cursor va a ser, etc. Lo que ocurre es que ADO es muy flexible y nos permite hacerlo de varias formas, aunque todas ellas conducen a lo mismo.\nSource (Opcional) Es el nombre de una tabla, consulta o sentencia SQL de la cual se obtienen los registros del Recordset.\nActiveConnection (Opcional). Es el nombre de un objeto Connection abierto o una cadena de conexión válida. Esta cadena es la misma que la que emplearíamos para abrir el objeto Connection.\nCursorType (Opcional). Un valor que determina el tipo de cursor que el proveedor debe usar al abrir el Recordset. Puede ser una de las siguientes constantes\nAdOpenForwardOnly (Predeterminado) Abre un cursor de tipo sólo avance.\nAdOpenKeyset Abre un cursor de tipo conjunto de claves.\nAdOpenDynamic Abre un cursor de tipo dinámico. (Igual que el Dynaset de DAO)\nAdOpenStatic Abre un cursor de tipo estático.\nLockType (Opcional). Un valor que determina el tipo de bloqueo que debe usar el proveedor al abrir el Recordset. Con este parámetro se le indica también si debe hacer las actualizaciones registro a registro o en bloque. Puede ser una de las siguientes constantes\nAdLockReadOnly (Predeterminado) Sólo lectura. No puede modificar los datos.\nAdLockPessimistic Bloqueo pesimista, registro a registro. El proveedor hace lo necesario para asegurar una modificación correcta de los registros, normalmente bloqueando registros en el origen de datos inmediatamente antes de la modificación.\nAdLockOptimistic Bloqueo optimista, registro a registro. El proveedor usa bloqueooptimista, bloqueando registros sólo cuando se llama al método Update.\nAdLockBatchOptimistic Actualizaciones optimistas por lotes. Requeridas en el modo de actualización por lotes en oposición al modo de actualización inmediata. (Actualización en bloque)\nOptions (Opcional). Constante que determina como va a evaluar el proveedor de datos el argumento Source. Puede ser una de las siguientes constantes de esta lista.\nAdCmdText Indica que el proveedor debe evaluar Source como una definición textual de un comando.\nAdCmdTable Indica que ADO debe generar una consulta SQL para devolver todaslas filas de la tabla nombrada en Source.\nAdCmdTableDirect Indica que el proveedor debe devolver todas las filas de la tabla nombrada en Source.\nAdCmdStoredProc Indica que el proveedor debe evaluar Source como un procedimiento almacenado\nAdCmdUnknown Indica que el tipo de comando del argumento Source es desconocido.\nAdCmdFile Indica que el Recordset guardado se debe restaurar desde el archivo nombrado en Source.\nAdAsyncExecute Indica que Source se debe ejecutar de forma asíncrona.\nAdAsyncFetch Indica que, tras alcanzar la cantidad inicial especificada en la propiedad Initial Fetch Size, las filas restantes deben buscarse de forma asíncrona. Si se requiere una fila que no se ha encontrado, se bloqueará el subproceso principal hasta que se disponga de la fila solicitada.\nAdAsyncFetchNonBlocking Indica que el subproceso principal nunca se bloquea durante la búsqueda. Si no se encuentra la fila solicitada, la fila actual se desplaza automáticamente al final del archivo.\nHabrá observado que hemos remarcado que el método Open ABRE un recordset. No lo crea. El recordset debe estar creado previamente. ¿Qué cuando se crea? Mediante la instrucción:\nActualiza los datos de un objeto Recordset volviendo a ejecutar la consulta utilizada para abrirlo. Se obtiene el mismo resultado que si se cerrara el recordset y se volviera a abrir.\nSintaxis MiRecordset.Requery Opciones\nOptiones Opcional. Máscara de bits que indica opciones que afectan a esta operación. Si el valor de este parámetro está establecido a adAsyncExecute, esta operación se ejecutará de forma asíncrona y se emitirá un evento RecordsetChangeComplete cuando concluya.\nActualiza los datos del objeto Recordset actual. Este método, a diferencia del método Requery, no vuelve a ejecutar el comando de creación del recordset, sino que lee los registros existentes en el recordset para actualizar su valor, pero no presenta aquellos registros que hubieran sido creados con posterioridad a la apertura del recordset. Es más rápido que el método Requery, y en muchos casos solamente nos interesa actualizar los registros sobre los que estamos trabajando.\nSintaxis MiRecordset.Resync AffectRecords, ResyncValues\nLos parámetros AffectRecords y ResyncValues determinan que registros se van a volver a leer y sobreescribir. Vea la ayuda para mas detalles.\nCrea un nuevo registro en un objeto Recordset actualizable.\nSintaxis NombreDelRecordset.AddNew FieldList, Values\nLos parámetros FieldList y Values son opcionales. En caso de ponerlos, FieldList serán los nombres de los campos a los que se les va a poner un valor, y Values son los valores de cada uno de estos campos. El orden nombre - valor debe mantenerse estrictamente.\nSiempre recomendaré que, en vez de meter los datos mediante estos parámetros, se metan posteriormente linera a línea, tal como se hizo siempre con los recordsets\nNombreDelRecordset!NombredelCampo = ValorDelCampo\nNombreDelRecordset(“NombredelCampo”) = ValorDelCampo\nEsta segunda forma es necesaria cuando el nombre del campo tiene espacios. Nunca es recomendable poner espacios en los nombres de campos, pero en caso de que existan, debe optar por utilizar la sintaxis segunda, con los paréntesis y comillas dobles.\nNo siempre se puede utilizar el método AddNew. Puede comprobar si se puede utilizar, usando el método Supports visto anteriormente.\nEl método AddNew convierte a este registro recién creado en registro actual. Pero este registro solamente existe en el recordset. Para introducir los datos en la base de datos, (Y por lo tanto en el disco duro) es necesario invocar el método Update una vez introducidos todos los valores de los campos que deseamos introducir. Con algún tipo de cursor es necesario también utilizar el método Requery para poder acceder al registro recién creado.\nSi se invoca el método AddNew mientras se está editando el registro actual, o durante otra operación AddNew, ADO invoca automáticamente el método Update para guardar los cambios. Vea más adelante los métodos Update y UpdateBatch.\nGuarda los cambios realizados en el registro actual de un objeto Recordset. Se utiliza tanto para “rematar” una operación de creación de un registro iniciada con AddNew, como para guardar los nuevos datos del registro actual (Recuerde que en ADO no existe el método Edit, tal como ocurría en DAO)\nSintaxis NombreDelRecordset.Update Fields, Values\nEn esta sintaxis, Fields y Values son opcionales, y solamente tienen aplicación cuando se trata de cambiar los valores del registro actual, no de terminar una operación de creación de un nuevo registro mediante AddNew.\nVuelvo a recomendar lo anterior. Para cambiar los valores de varios campos de un registro, nos colocaremos sobre ese registro, y sin invocar ningún método, ejecutaremos este código\nMiRecordset!Campo1 = Valor1\nMiRecordset!Campo2 = Valor2\nMiRecordset!CampoN = ValorN\nPero en ADO pasa una cosa que no pasaba en DAO. Si cambiamos de registro una vez modificado el valor de un registro, ADO invoca automáticamente el método Update. Por lo tanto, el código siguiente:\nTendrá el mismo resultado que el anterior cuando cambiemos de registro actual. Esto puede ser bueno a malo, pero personalmente pienso que no es práctico porque implica tener mucho más cuidado que en DAO. Hace lo mismo que cuando tenemos unos controles enlazados a datos mediante un control Data.\nSi una vez que ejecutamos una línea tal como esta\nQueremos que ese nuevo valor no entre en la base de datos, debemos cancelarlo mediante el método CancelUpdate.\nEscribe en disco todas las actualizaciones pendientes de proceso por lotes. En ADO un recordset puede actualizarse registro a registro o por lotes. Todo dependerá de cómo se ha abierto (Si el valor LockType se ha puesto a AdLockBatchOptimistic)\nSintaxis MiRecordset.UpdateBatch AffectRecords\nAffectRecords Constante que determina a cuántos registros afectará el método UpdateBatch. Puede tomar uno de los siguientes valores.\nAdAffectCurrent Escribe solamente los cambios pendientes en el registro actual.\nAdAffectGroup Escribe los cambios pendientes que cumplen el valor de la propiedad Filter.\nAdAffectAll (Predeterminado) Escribe los cambios pendientes en todos los registros del objeto Recordset.\nCancela la ejecución del método Open.\nEl método Cancel solamente puede usarse si el método Open fue invocado con la opción adAsyncConnect, adAsyncExecute o adAsyncFetch.\nElimina el registro actual o un grupo de registros. Por defecto elimina solamente el registro actual. Vea la ayuda para ampliar los detalles respecto al parámetro opcional AffectRecords\nSintaxis MiRecordset.Delete AffectRecords\nHabíamos visto más atrás que el ADO no existe el método Edit. Para modificar un registro basta con poner una instrucción tal como esta:\nMiRecordset!MiCampo = MiNuevoValor\nY a continuación rematar la operación mediante el método Update\nSi por cualquier circunstancia se ha ejecutado la primera instrucción, y luego queremos volvernos atrás, antes de ejecutar el método Update debemos deshacer el cambio con el método CancelUpdate, con lo que el registro afectado recuperará nuevamente su valor original.\nRecuerde que ADO funciona de forma distinta a DAO con estos métodos de modificación de los registros. Recuerde que si está en proceso de modificación de un registro (Ha ejecutado la primera línea del ejemplo anterior) y cambia de registro, por el hecho de cambiar de registro, ADO invoca automáticamente el método Update.\nCancela una actualización por lotes pendiente. Es similar a la anterior, pero para actualización por lotes.\nSintaxis MiRecordset.CancelBatch AffectRecords\nCrea un objeto Recordset duplicado a partir de un objeto Recordset existente. Opcionalmente, puede especificarse que el nuevo recordset sea solamente de lectura\nSintaxis Set rstDuplicate = rstOriginal.Clone (LockType)\n(El objeto rstDuplicate debe estar declarado previamente como objeto ADODB.Recordset)\nLockType puede tomar uno de los siguientes valores:\nAdLockUnspecified (Predeterminado) El recordset resultante tendrá el mismo tipo de bloqueo que el original.\nAdLockReadOnly El recordset creado es solamente de lectura.\nEl recordset resultante del método Clone, aunque igual al original en el momento de su creación, es completamente independiente de este a partir de ese momento, por lo que las actualizaciones efectuadas en el original no afectan al clonado.\nMueve la posición del registro actual de un objeto Recordset\nSintaxis MiRrecordset.Move NumRecords, Start\nNumRecords Un valor Long con signo que especifica el número de registros que debe moverse a partir de la posición del registro actual o del registro especificado en el parámetro Start, si es que se especifica.\nStart Opcional. Un String o Variant cuyo resultado sea un marcador del tipo Bookmark. Puede utilizar también una de las siguientes constantes:\nAdBookmarkCurrent (Predeterminado) Cuenta a partir del registro actual\nAdBookmarkFirst Cuenta a partir del primer registro\nAdBookmarkLast Cuenta a partir del último registro\nMétodos MoveFirst, MoveLast, MoveNext y MovePrevious\nPasa al primer, último, siguiente o anterior registro de un objeto Recordset especificado y lo convierte en el registro actual. Funciona igual que en DAO\nTenga en cuenta a la hora de usar los métodos Move que pueden existir Recordsets que no permiten el movimiento hacia atrás.\nBusca el primer registro del recordset que satisfaga los criterios especificados en el criterio de búsqueda. Si se cumple el criterio de búsqueda, la posición del recordset se establece en el primer registro encontrado; si no, la posición se establece al final del recordset.\nSintaxis MiRecordset.Find (criterio, SkipRows, searchDirection, start)\ncriterio Es el criterio de búsqueda. Por ejemplo “Pais = España” siendo Pais el nombre del campo en el cual buscamos el valor España\nSkipRows (Opciopnal) Es un Long, cuyo valor predeterminado es cero, que especifica el número de registros a partir del registro actual donde debe empezar la búsqueda.\nsearchDirection (Opcional) Un valor que especifica si la búsqueda se realiza en dirección al final del recordset (adSearchForward) o en dirección hacia el principio del recordset (adSearchBackward). La búsqueda termina al final o al principio del recordset, dependiendo del valor de searchDirection.\nstart (Opcional) Un marcador tipo BookMark que se utiliza como posición inicial de la búsqueda.\nEl operador de comparación de criterio puede ser ">", "<", "=", ">=" , "<=", "<>" (distinto de) o "like" (coincidencia parcial de cadenas). El valor de comparación puede ser una cadena, un número en coma flotante o una fecha. Los valores de cadena están delimitados con comillas sencillas (por ejemplo, "Pais = 'España'"). Los valores de fecha están delimitados con signos "#" y con formato mm/dd/yy (por ejemplo, "fecha_inicial > #7/22/97#"). Si el operador de comparación es "like", el valor de la cadena puede contener los caracteres comodín "*" o "_". (Funcionan de forma idéntica, sustituyendo a cualquier sucesión de caracteres.) No acepta el carácter “?” (Por ejemplo, "Pais like ‘Es_’" o “Pais Like ‘Es*’ encuentra España y Estonia)\nADO no tiene los métodos FindFirst, FindNext, FindPrevious y FindLast. Deberá emplear el método Find de forma inteligente para implementar estos otros.\nEste método permite guardar el contenido de un Recordset en un fichero. Puede ser muy útil cuando queremos exportar ese recordset hacia otra aplicación.\nSintaxis MiRecordset.Save FileName, PersistFormat\nFileName es la ruta completa del fichero en el que se guardará el Recordset.\nPersistFormat (Opcional). Un valor que especifica el formato en que se guardará el Recordset. Puede ser una de las constantes siguientes.\nAdPersistADTG (Valor predeterminado) Se guarda en un formato propietario (Advanced Data Tablegram). No es inteligible a simple vista, pero genera ficheros bastante cortos.\nAAdPersistXML Se guarda en formato XML. Es un formato puramente en ASCII donde pueden verse los nombres de los campos y su contenido. Este formato genera ficheros más grandes que el ADT\nSi el recordset tienen aplicado un filtro (Mediante la propiedad Filter) solamente guarda los registros que deja ver ese filtro.\nSi ya existe el fichero le dará un error. Cerciórese que no existe (Mediante la función Dir) y bórrelo antes de volver a utilizar el método Save.\nEste método busca un registro desplazándose por el recordset a lo largo de un índice o un conjunto de índices. La búsqueda mediante Seek es mucho más rápida que con Find, ya que la realiza siguiendo el ordenamiento de los registros según un índice.\nPara poder usar el método Index es necesario que el proveedor acepte índices en el objeto recordset. Esto ha llevado al autor a no poder presentar ningún ejemplo de este método, ya que todas las bases de datos ensayadas no permitían índices. Puede ver si acepta índices mediante el método Supports:\nIf MiRecordset1.Supports(adIndex) = True Then\nVea la ayuda de VB para mayor información\nPara entender este método es necesario explicar previamente como se puede crear un recordset compuesto.\nUn recordset compuesto es un recordset que se crea concatenando sentencias SELECT, y cada una de ellas creará, dentro del mismo Recordset, un recordset particular. Al crear el recordset, el recordset particular que va a estar activo es el correspondiente a la primera sentencia SELECT. Mediante el método NextRecordset podemos ir avanzando a través de los siguientes recordsets particulares. El carácter de separación entre las sentencias SELECT es el punto y coma ( ; )\nMiRecordset1.Open "Select * From Regimenes; Select * From Regimen_Seguimiento Where Rs_Origen = 'LSB'", MiConexionADO, adOpenDynamic, adLockOptimistic\n(La instrucción anterior debe leerse como una sola línea)\nMiRecordset es un recordset compuesto. Toma datos de dos tablas distintas, pero podría haberlo hecho solamente de una tabla con una condición distinta en la SELECT.\nCuando se ejecuta esa línea, el recordset actual es el correspondiente a la primera selección. (Select * From Regimenes). Ejecutando el método NextRecordset ese recordset primero se borra y pasa a ser recordset actual el creado con la selección segunda (Select * From Regimen_Seguimiento Where Rs_Origen = 'LSB'")\nSet MiRecordset1 = MiRecordset1.NextRecordset\nPuede usar también este recordset para crear un nuevo recordset a partir del primero\nSet MiRecordset2 = MiRecordset1.NextRecordset\nMiRecordset2 debe estar declarado como objeto recordset, y creado con la instrucción New:\nSet MiRecordset2 = New ADOBD.Recodset\nLa colección Fields de un recordset ADO\nUn objeto Recordset tiene una colección Fields que contiene todos los objetos Field. Cada objeto Field se corresponde a una columna del Recordset.\nVamos a ver aquí un truco que nos permite ADO. Podemos crear un recordset ¡Sin necesidad de una base de datos!\nCuando estudiamos el objeto recordset vimos que el recordset se crea con una instrucción como esta:\nSet MiRecordset1 = New ADODB.Recordset\nAhora ya podemos abrir el recordset leyendo los datos desde una base de datos. Utilizamos para ello el método Open del recordset:\nMediante el método Open lo que hace el recordset es conocer su estructura (Que campos tiene, propiedades de estos campos, etc) y el valor de cada uno de los campos de sus registros. ¿Qué pasaría si en vez de abrir el recordset le vamos añadiendo objetos Field a su colección Fields? Lo hacemos mediante el método Append:\nMiRecordset1.Fields.Append "MiCampo1", adBigInt\nMiRecordset1.Fields.Append "MiCampo2", adChar, 25\nMiRecordset1.Fields.Append "MiCampo3", adBSTR\nLo que ocurre es que el recordset ya tiene tres campos, el primero de nombre MiCampo1, numérico Long, el segundo, un string de 25 caracteres de nombre MiCampo2, y el tercero, de nombre MiCampo3, una cadena de caracteres de longitud indefinida, terminada en un carácter nulo. Ya tenemos una estructura de un recordset sin necesidad de haber leído la base de datos. No es necesario por lo tanto que exista una tabla o consulta almacenada con esa estructura. Ahora podemos abrir el recordset:\nLo abrimos sin pasarle ningún parámetro. Ahora ya está abierto y podemos trabajar con el como con un recordset cualquiera. Recuerde que al principio está vacío.\nMiRecordset1!MiCampo1 = 34\nMiRecordset1!MiCampo2 = "Guía del Estudiante"\nMiRecordset1!MiCampo3 = "Hola mi amor" & vbCrLf & "Yo soy tu lobo"\nYa tenemos un registro dentro del recordset. Podemos introducirle tantos registros como queramos, y luego movernos por el recordset mediante los métodos Movexxxx. Ahora podremos leer el contenido del registro actual:\nLabel1 = MiRecordset1!MiCampo1\nLabel2 = MiRecordset1!MiCampo2\nLabel3 = MiRecordset1!MiCampo3\nEl resultado del código de el ejemplo se traducirá en algo como esto:\nY ahora vienen lo mejor. ¿Para que queremos un recordset que no tienen datos leídos desde una base de datos? Las aplicaciones de esto solamente está limitadas por la imaginación. Pienso, por ejemplo, en introducir en un recordset todos los datos leídos de un fichero de configuración, y así tener todos esos datos disponibles durante toda la aplicación, en vez de en variables, como MiRecordset!MiDato1\nEs una idea, pero piense que esto no regala nada. El espacio de memoria consumido será similar a si usa variables. Pero posiblemente estará más cómodo y más inteligible su código.\nVeamos los métodos de la colección Fields\nAgrega un campo a una colección Fields de un Recoprdset.\nSintaxis MiRecordset.Fields.Append Name, Type, DefinedSize, Attrib\nName Un String con el nombre del nuevo objeto Field, que tiene que ser único dentro de la coleccón Fields.\nType Tipo de datos que va a contener ese campo. Puede tomar uno de estos valores:\nSe une en una instrucción OR lógica con otro tipo para indicar que los datos son una matriz segura de ese tipo (DBTYPE_ARRAY).\nUn entero con signo de 8 bytes (DBTYPE_I8).\nUn valor binario (DBTYPE_BYTES).\nUn valor Boolean (DBTYPE_BOOL).\nSe une en una instrucción OR lógica con otro tipo para indicar que los datos son un puntero a los datos del otro tipo (DBTYPE_BYREF).\nUna cadena de caracteres terminada en nulo (Unicode) (DBTYPE_BSTR).\nUn valor de tipo String (DBTYPE_STR).\nUn valor de tipo Currency (DBTYPE_CY). Un valor Currency es un número de coma fija con cuatro dígitos a la derecha del signo decimal. Se almacena en un entero con signo de 8 bytes en escala de 10.000.\nUn valor de tipo Date (DBTYPE_DATE). Un valor Date se almacena como un valor de tipo Double; la parte entera es el número de días transcurridos desde el 30 de diciembre de 1899 y la parte fraccionaria es la fracción de un día.\nUn valor de fecha (aaaammdd) (DBTYPE_DBDATE).\nUn valor de hora (hhmmss) (DBTYPE_DBTIME).\nUna marca de fecha y hora (aaaammddhhmmss más una fracción de miles de millones) (DBTYPE_DBTIMESTAMP).\nUn valor numérico exacto con una precisión y una escala fijas (DBTYPE_DECIMAL).\nUn valor de coma flotante de doble precisión (DBTYPE_R8).\nNo se ha especificado ningún valor (DBTYPE_EMPTY).\nUn código de error de 32 bits (DBTYPE_ERROR).\nUn identificador único global (GUID) (DBTYPE_GUID).\nUn puntero a una interfaz Idispatch de un objeto OLE (DBTYPE_IDISPATCH).\nUn entero firmado de 4 bytes (DBTYPE_I4).\nUn puntero a una interfaz Iunknown de un objeto OLE (DBTYPE_IUNKNOWN).\nUn valor binario largo (sólo para el objeto Parameter).\nUn valor largo de tipo String (sólo para el objeto Parameter).\nUn valor largo de tipo String terminado en nulo (sólo para el objeto Parameter).\nUn valor numérico exacto con una precisión y una escala exactas (DBTYPE_NUMERIC).\nUn valor de coma flotante de simple precisión (DBTYPE_R4).\nUn entero con signo de 2 bytes (DBTYPE_I2).\nUn entero con signo de 1 byte (DBTYPE_I1).\nUn entero sin signo de 8 bytes (DBTYPE_UI8).\nUn entero sin signo de 4 bytes (DBTYPE_UI4).\nUn entero sin signo de 2 bytes (DBTYPE_UI2).\nUn entero sin signo de 1 byte (DBTYPE_UI1).\nUna variable definida por el usuario (DBTYPE_UDT).\nUn valor binario (sólo para el objeto Parameter).\nUn valor de tipo String (sólo para el objeto Parameter).\nUn tipo Variant de automatización (DBTYPE_VARIANT).\nSe une en una instrucción OR lógica con otro tipo para indicar que los datos son una estructura DBVECTOR, tal como está definida por OLE DB, que contiene un contador de elementos y un puntero a los datos del otro tipo (DBTYPE_VECTOR).\nUna cadena de caracteres Unicode terminada en nulo (sólo para el objeto Parameter).\nUna cadena de caracteres Unicode terminada en nulo (DBTYPE_WSTR).\nDefinedSize Un Long que define el tamaño del campo si fuese necesario. (Por ejemplo para un string)\nAttrib (Opcional). Especifica los atributos del campo a añadir. Puede tomar estos valores:\nIndica que el campo se aplaza, es decir, los valores del campo no se recuperan del origen de datos con todo el registro, sino solamente cuando se tiene acceso explícito a los mismos.\nIndica que se puede escribir en el campo.\nIndica que el proveedor no puede determinar si se puede escribir en el campo.\nIndica que el campo contiene datos de longitud fija.\nIndica que el campo acepta valores Null.\nIndica que se pueden leer valores Null del campo.\nIndica que se trata de un campo binario largo. También indica que se pueden utilizar los métodos AppendChunk y GetChunk.\nIndica que el campo contiene un identificador de fila persistente en el que no se puede escribir y que no tiene ningún valor significativo excepto la identificación de la fila (como por ejemplo un número de registro, un identificador único, etc.).\nIndica que el campo contiene algún tipo de marca de hora o de fecha que se utiliza para efectuar actualizaciones.\nIndica que el proveedor almacena los valores del campo en la memoria caché y que las lecturas siguientes se efectúan en dicha memoria .\nTeóricamente elimina un objeto de la colección Fields.\nSintaxis Fields.Delete Field\nField Un Variant que designa el objeto Field que se va a eliminar. Este parámetro tiene que ser el nombre del objeto Field; no puede ser una posición ordinal o el propio objeto Field.\nLa llamada al método Fields.Delete en un Recordset abierto provoca un error de ejecución.\n(Como ha ocurrido en otras ocasiones, al autor le ha sido imposible ejecutar este método con los resultados esperados)\nDevuelve el elemento de la colección Fields especificado en el índice. Devuelve el objeto, por lo tanto, y sobre ese objeto, podemos obtener las propiedades que deseemos. En el ejemplo siguiente, introducimos los nombres de todos los campos en un ComboBox llamado ComboCampos\nDim MM As String, I As Integer\nFor I = 0 To MiRecordset1.Fields.Count - 1\nMM = MiRecordset1.Fields.Item(I).Name\nAunque la colección Fields tiene este método, la verdad es que no tienen efectos visibles sobre esa colección.\nPropiedades de la colección Fields\nDevuelve el número de campos de la colección Fields. Es un Long.\nUn objeto Command es la definición de un comando específico que se piensa ejecutar contra un origen de datos. Mediante un objeto Command podemos crear un recordset, pero recuerde que un recordset lo podemos también crear directamente.\nUtilice un objeto Command para consultar una base de datos y obtener registros en un objeto Recordset, para añadir o eliminar registros, ejecutar una operación de manejo masivo de datos o para manipular la estructura de una base de datos.\nPropiedades del Objeto Command\nIndica a qué objeto Connection pertenece actualmente el objeto Command. Es un string con el nombre de la conexión.\nContiene el texto del comando que se quiere emitir al proveedor. Es un string. Suele ser una instrucción SQL, un nombre de tabla o un procedimiento almacenado, o cualquier otra instrucción que reconozca el proveedor. El valor predeterminado es una cadena vacía.\nEspecifica el intervalo de espera para que se ejecute un comando antes de que finalice el intento y se genere un error. Es un Long que indica en segundos ese tiempo. El valor predeterminado es 30.\nPropiedad CommandType (IMPORTANTE)\nIndica el tipo de un objeto Command. Esta propiedad se usa para optimizar la evaluación de la propiedad CommandText, ya que de esta forma el proveedor no tiene que perder tiempo examinando si es una instrucción SQL, un procedimiento almacenado o un nombre de tabla. Si el valor de esta propiedad es adCmdUnknown (valor predeterminado), estamos forzando al proveedor a que realice esa investigación lo que provocará probablemente un descenso en su rendimiento. Si sabe qué tipo de comando está usando, el establecimiento de la propiedad CommandType instruye a ADO a que vaya directamente al código relevante. Si la propiedad CommandType no coincide con el tipo de comando de la propiedad CommandText, ocurre un error cuando llama al método Execute.\nAdCmdText Indica que es una definición textual de un comando o una llamada a un procedimiento almacenado.\nAdCmdTable Indica que es un nombre de tabla cuyas columnas se devuelven todas mediante una consulta SQL generada internamente.\nAdCmdTableDirect Indica que es un nombre de tabla en la que se devuelven todas las columnas.\nAdCmdStoredProc Indica que es un nombre de procedimiento almacenado\nAdCmdUnknown Predeterminado. El tipo de comando de la propiedad CommandText es desconocido.\nAdCmdFile Evalúa CommandText como el nombre de archivo de un valor Recordset persistente.\nAdExecuteNoRecords Indica que es un comando o un procedimiento almacenado que no devuelve filas (por ejemplo, un comando que sólo inserta datos). Si se recupera alguna fila, se descarta y no se devuelve. Siempre se combina con adCmdText o adCmdStoredProc.\nEs un Booleano que indica si se debe guardar una versión compilada de un comando antes de su ejecución. Esta propiedad fuerza al proveedor a guardar una versión preparada (compilada) de la consulta especificada en la propiedad CommandText antes de la primera ejecución de un objeto Command. Esto puede disminuir el rendimiento de la primera ejecución de un comando, pero cuando el proveedor haya compilado el comando, utilizará la versión compilada del mismo para las ejecuciones siguientes, lo cual aumentará el rendimiento.\nSi el proveedor no admite la preparación del comando, puede devolver un error cuando esta propiedad se establezca a True. Si no devuelve un error, simplemente ignora la solicitud de preparar el comando y establece la propiedad Prepared a False.\nDescribe el estado del objeto: abierto o cerrado. Devuelve un Long o una constante: adStateClosed o adStateOpen\nMétodos del Objeto Command\nMétodo Execute (IMPORTANTE, más bien diríamos, el objetivo del Command)\nEjecuta la consulta, la instrucción SQL o el procedimiento almacenado especificado en la propiedad CommandText. Devuelve un recordset o modifica la base de datos.\nPara un Command que devuelva filas:\nPara un Command que no devuelva filas:\ncommand es el nombre del Objeto Command\nParameters Opcional. Una matriz Variant con los valores de los parámetros pasados con una instrucción SQL. (Los parámetros de salida no devuelven valores correctos cuando se pasan en este argumento).\nOptions Opcional. Un valor Long o una constante. Acepta estos valores\nadCmdText Indica que el proveedor tiene que evaluar CommandText como definición textual de un comando, como una instrucción SQL.\nadCmdTable Indica que ADO tiene que generar una consulta SQL para devolver todas las filas de la tabla mencionada en CommandText.\nadCmdTableDirect Indica que el proveedor tiene que devolver todas las filas de la tabla mencionada en CommandText.\nAdCmdStoredProc Indica que el proveedor tiene que evaluar CommandText como procedimiento almacenado.\nadCmdUnknown Indica que el tipo de comando en CommandText es desconocido.\nadAsyncExecute Indica que el comando se tiene que ejecutar de forma asíncrona.\nadAsyncFetch Indica que el resto de las filas siguientes a la cantidad inicial especificada en la propiedad CacheSize tiene que ser recuperada de forma asíncrona.\nCancela la ejecución de una llamada asíncrona pendiente al método Execute\nUtilice el método Cancel para terminar la ejecución de una llamada asíncrona a un método Execute (es decir, el método fue invocado con la opción adAsyncExecute o adAsyncFetch).\nLos objetos Command pueden utilizar parámetros. De esta forma, podemos construir una consulta utilizando la interrogación (?) como comodín. Así cada vez que ejecutemos el comando, V.B. se encargará de sustituir el comodín por los parámetros asociados a dicho command. Además podemos utilizar los parámetros para recoger los valores devueltos por un Procedimiento almacenado en la base de datos. Para entender mejor este tipo de consultas primero veremos qué es el objeto parameter.\nEjemplo de la utilización de Command\nVeamos un ejemplo de cómo usar el Objeto Command. Pero previamente vamos a ver un código del que hemos partido para hacer ver al alumno que ADO permite hacer las cosas de muchas maneras. Este código mete los datos de un documento en una base de datos Oracle, leyendo previamente el número más alto del documento para poner al nuevo documento un número igual al último + 1.:\nDim ConexBDPrensa As ADODB.Connection\nDim RsBDPrensa1 As ADODB.Recordset\nDim StrIntroducir As String, NumeroDocumento as long\nRem Se abre un objeto Connection para crear sobre él el recordset\nSet ConexBDPrensa = New ADODB.Connection\nConexBDPrensa.ConnectionString = "Provider=MSDAORA.1;” & _\n“User ID=INTRANET;Password=INTRANET;Data Source=intranet;” & _\n“Persist Security Info=False"\nRem Se abre un recordset para leer el número, se lee y se vuelve a cerrar\nRsBDPrensa1.Open "Int_Documentos Order By CL_DOC", ConexBDPrensa, adOpenDynamic, adLockOptimistic\nNumeroDocumento = RsBDPrensa1!CL_DOC\nNumeroDocumento = NumeroDocumento + 1\n(* Este es el punto donde cambia el código que verá más adelante)\nRem Se introduce en una variable tipo String una instrucción para añadir un nuevo registro\nRem Esa instrucción se va a ejecutar desde el objeto Connection mediante su método Execute\nStrIntroducir = "Insert Into INT_DOCUMENTOS " & _\n"(CL_DOC,NOM_DOC,TITULO_DOC,AUTOR_DOC,CL_TEMA_DOC,CL_DPT_DOC,” & _\n“CL_TIPO_DOC,FICH_DOC,FECHA_EMISION_DOC,ULTIMA_HORA_DOC,” & _\nVISIBLE_DOC) Values (" & NumeroDocumento & ",'" & TbTitulo & "','" & TbTitulo & _\n"','" & TbTitulo.Tag & "',19,2,1,'" & HRefPrensa & "/" & TbNombFichTIF & "','" & Date & "',0,1)"\nRem Observe que los valores tipo string introducidos (TbXXX) van entre comilla simple\nRem Se ejecuta esa instrucción desde el objeto Connection ConexBDPrensa\nRem Se cierra el Objeto Connection\nRem Aquí termina la operación de crear un nuevo registro\nMsgBox "Documento enviado"\nEste es el código real de una aplicación que introduce los datos el resumen de prensa diario en una base de datos. Se introduce un nuevo registro en la tabla INT_DOCUMENTOS. El resumen de prensa es un fichero .Tiff de nombre TbNombFichTIF que se mete en una carpeta del servidor mediante FTP, y para su loccalización y presentación en una página Web es necesario introducir su nombre y Path y otros datos en una base de datos. Los campos que se introducen y los valores de cada uno son:\nCL_DOC, NumeroDocumento (Long calculado)\nNOM_DOC TbTitulo (String contenido en TbTitulo.Text)\nTITULO_DOC TbTitulo (String contenido en TbTitulo.Text – se repite-)\nAUTOR_DOC TbTitulo.Tag (String contenido en TbTitulo.Tag)\nCL_TEMA_DOC 19 (Integer, dato fijo)\nCL_DPT_DOC 2 (Integer, dato fijo)\nCL_TIPO_DOC 1 (Integer, dato fijo)\nFICH_DOC HRefPrensa & "/" & TbNombFichTIF Un string que indica el nombre del fichero (TbNombFichTIF.Text) y su carpeta (Variable HrefPrensa)\nFECHA_EMISION_DOC Date (Fecha actual)\nULTIMA_HORA_DOC 0 (Byte, dato fijo)\nVISIBLE_DOC 1 (Byte, dato fijo)\nEsta forma de introducir los datos, método que los lingüistas especializados en la jerga informática llaman “a capón”, es la que nunca falla. Exige un poco de código, con muchas probabilidades de equivocarse, pero muchas veces se prefiere esta forma de meter datos a utilizar el método AddNew. Tiene la gran ventaja de que la acepta cualquier base de datos, independientemente de donde esté el cursor. Habrá observado que utilizamos el método Execute del objeto Connection. Y así funciona perfectamente. Vamos a hacer lo mismo, pero introduciendo la cadena de caracteres un objeto Command, (Que pertenece al mismo objeto Connection sobre el que ahora hemos ejecutado el Execute) y vamos a ejecutar el Execute de ese Command. ¿Se da cuenta que estamos haciendo lo mismo? El nuevo código creado a partir del anterior es el siguiente:\n(* Este es el mismo punto de antes. Aquí comienza el cambio del código)\nDim MiComando As ADODB.Command\nSet MiComando = New ADODB.Command\nMiComando.CommandText = "Insert Into INT_DOCUMENTOS " _\n& "(CL_DOC,NOM_DOC,TITULO_DOC,AUTOR_DOC,CL_TEMA_DOC,CL_DPT_DOC,CL_TIPO_DOC,FICH_DOC,FECHA_EMISION_DOC,ULTIMA_HORA_DOC,VISIBLE_DOC) " _\n& NumeroDocumento & ",'" & TbTitulo & "','" & TbTitulo & "','" & TbTitulo.Tag & "',19,2,1,'" & HRefPrensa & "/" & TbNombFichTIF & "','" & Date & "',0,1)"\nADO le permite hacer las cosas de maneras muy distintas, pero siempre debe aportar la misma información. En este caso ha visto que el objeto Command no hace falta para nada. ¿Entonces, para que existe? La respuesta es sencilla: facilita la comprensión del código. Pero que el objeto Command no le perjudique precisamente eso, la comprensión del código. No se preocupe de no ser estrictamente académico. Este humilde autor nunca usa Command excepto para explicarlo. ADO nos permite eso.\nVamos a ver ahora cómo haríamos esto mismo con el método AddNew.\nDeberemos crear un recordset. Lo primero, lo declaramos:\nDim RsBDPrensa as ADODB.Recodset\nLuego lo creamos:\nSet RsBDPrensa = New ADODB.Recordset\nLo abrimos. Pero primero tomamos la precaución de poner la propiedad CursorLocation del Objeto Connection a adUseClient (Lado cliente) y de esta forma los cursores creados para los recordsets abiertos sobre ese objeto connection estarán del lado cliente. Si el cursor está de lado servidor es posible que no nos deje usar el método AddNew. (Vea Nota 1)\nConexBDPrensa.CursorLocation = adUseClient\nAbrimos el Recordset:\nRsBDPrensa.Open "Int_Documentos", ConexBDPrensa, adOpenDynamic, adLockOptimistic\nEjecutamos el método AddNew\nMetemos los datos\nRsBDPrensa!CL_DOC = NumeroDocumento\nRsBDPrensa!NOM_DOC = TbTitulo\nRsBDPrensa!TITULO_DOC = TbTitulo\nRsBDPrensa!AUTOR_DOC = TbTitulo.Tag\nRsBDPrensa!CL_TEMA_DOC = 19\nRsBDPrensa!FECHA_EMISION_DOC = Date\nRsBDPrensa!CL_DPT_DOC = 2\nRsBDPrensa!CL_TIPO_DOC = 1\nRsBDPrensa!FICH_DOC = HRefPrensa & "/" & TbNombFichTIF\nRsBDPrensa!VISIBLE_DOC = 1\nRsBDPrensa!ULTIMA_HORA_DOC = 0\nRematamos con el método Update\nCerramos el recordset.\nCerramos la conexión\nNota 1. – Muchos programadores se rinden cuando ven que no les funciona los métodos AddNew / Update para introducir nuevos datos. Cierto es que cada base de datos se comporta de forma distinta respecto a este método. Pero antes de rendirse y usar el código “a capón” intente ver como tienen la propiedad CursorLocation, el tipo de recordset abierto y el tipo de bloque elegido (Recuerde que por defecto es de solo lectura). Eso sí, el método “a capón” funciona siempre (Excepto que sea solo lectura), independientemente del bloqueo y del tipo de cursor\nEl “Control Data” de ADO - (Adodc ADO Data Control)\nEste capítulo parece que quedaba un poco corto. No por el número de páginas, sino porque tanto en DAO como en RDO nos explayamos con el control Data, y en ADO parece que solamente lo hemos visto de pasada para explicar cómo se compone la cadena de conexión. Veámoslo un poco más en profundidad.\nEl control Data para ADO es el “Microsoft ADO data control 6.0 (OLEDB)” que se encuentra en Proyecto | Componentes. La apariencia es similar a la del Data de DAO\nHagamos un repaso de sus propiedades. Veremos solamente aquellas que son específicas de ADO:\nEstablece la forma de proceder cuando llega a la fila anterior a la primera. Toma uno de estos valores:\n0 – adDoMoveFirst Vuelve a la primera fila\n1 – adDoStayBOF Permanece en la fila BOF\nEs idéntica a la misma propiedad del objeto Command. Acepta los valores:\nEsta propiedad ya le hemos visto más atrás. Es la cadena de conexión con la base de datos.\nEs la misma que para el objeto Recordset. Acepta los valores:\n1 – adOpenKeyset\n2 - adOpenDynamic\n3 – adOpenStatic\nEstablece la forma de proceder cuando llega a la fila EOF. Acepta los valores:\n0 – adDoMoveLast Vuelve a la última fila\n1 – adStayEOF Permanece en la fila EOF\n2 – adDoAddNew Añade una nueva fila\nTipo de Bloque. Igual a la misma propiedad del Objeto Recordset\nEs similar a la del Objeto Recordset. Establece el número de filas que obtiene en su recordset asociado.\nEstablece la contraseña para crear la cadena de conexión durante la creación del objeto Recordset asociado. Esta contraseña es la contraseña del usuario en la base de datos.\nEsta propiedad es solamente de escritura. Si se pretende leer da error.\nMétodos del control Adodc\nActualiza la información de los controles enlazados a datos. No existe el método UpdateRecords.\nVuelve a construir el recordset. Es idéntico al del control Data de DAO.\nVistas ya las propiedades y métodos del control Adodc, vamos a ver un poco como funciona y cuales son sus diferencias con el control data de DAO\nEl Adodc puede enlazar una base de datos a los típicos controles enlazados (Label, TextBox) usando la tecnología ADO. Los demás controles enlazados no tienen un comportamiento igual con el Adodc, Control Data o RDODataControl. En la siguiente lista puede ver que controles trabajan con uno u otro control Data.\nControl ADO RDO DAO Referencia\nDBGrid NO SI SI Microsoft Data Bound Grid Control 5.0 SP3\nDataGrid SI NO NO Microsoft DataGrid Control 6.0 (OLEDB)\nDataList SI SI SI Microsoft Data List Controls 6.0 (OLEDB)\nDataCombo SI SI SI Microsoft Data List Controls 6.0 (OLEDB)\nDBList SI SI SI Microsoft Data Bound List Controls 6.0\nDBCombo SI SI SI Microsoft Data Bound List Controls 6.0\nMSFlexGrid NO SI SI Microsoft FlexGrid Control 6.0\nMSHFlexGrid SI NO NO Microsoft Hierarchical FlexGrid Control 6.0 (OLEDB)\nPor lo demás el funcionamiento del Adodc es similar al Control data y al RDODataControl.\nCon este capítulo creo que ya tienen conocimientos suficientes para empezar a trabajar con ADO, y por la tanto, ya tiene permiso para aprender a programar con esta tecnología. Le recomiendo paciencia, y sobre todo no tener miedo a esta tecnología. Y como se dijo al principio, úsela siempre que tenga que usar una base de datos instalada en un servidor y conectada al usuario a través de una red de área local. En el próximo capítulo verá como se enlazan un cliente con el servidor SQL Server.\nDe cualquier forma no olvide la tecnología DAO para sus pequeñas aplicaciones, con la base de datos en el mismo ordenador que la aplicación. Personalmente creo que es mucho más rápida y más sencilla.