Impacto de los tipos de cursores ADO en un controlador ODBC en ASP

Artículos y recursos relacionados

• KB-LJW-DB-104 : Gestión de datos de tipo "DATE" con MySQL y MariaDB
• KB-LJW-DB-105 : Conexión a bases de datos MariaDB mediante ADO + ODBC

Arquitectura ADO / OLE DB / ODBC en ASP Classic

La arquitectura de acceso a los datos en ASP es la siguiente:

Función de cada capa

•  1. Aplicación ASP
  El código fuente de los scripts ASP describe la lógica funcional de su aplicación.
•  2. ADO
  La API ActiveX Data Objects  es la interfaz de programación del lado ASP que enlaza el código fuente ASP con el Provider OLE DB.
•  3. Provider OLE DB
  El Provider es una capa de adaptación entre ADO y la capa subyacente de acceso a los datos, ya sea esta un Driver ODBC o una interfaz nativa. Estandariza los intercambios entre ADO y esta capa de acceso.
•  4. Driver ODBC
  El controlador ODBC es el componente que realmente se comunica con la base de datos y devuelve los datos al Provider OLE DB. Está diseñado específicamente para el formato/tipo de base de datos de destino y, por lo general, es proporcionado por el diseñador del motor de base de datos.
•  5. Base de datos
  Es el sistema / servidor / archivo de base de datos que realmente contiene sus datos. Es consultado por el Driver ODBC cuando la cadena de conexión utiliza Provider=MSDASQL o no especifica ningún proveedor OLE DB. Se consulta a través de un proveedor OLE DB nativo cuando la cadena de conexión especifica explícitamente un Provider= distinto de MSDASQL y no se utiliza ningún parámetro ODBC (Driver= o DSN=). En este último caso, la comunicación se realiza directamente a través de la biblioteca cliente o del protocolo nativo del sistema de gestión de bases de datos, sin pasar por la capa ODBC.

Funcionamiento general

ADO siempre utiliza un OLE DB Provider, que es el componente de software que implementa la interfaz OLE DB y que permite a una aplicación que utiliza ADO acceder a una fuente de datos.

ADO nunca se comunica directamente con una base de datos ni con ODBC: siempre se apoya en un OLE DB Provider, que desempeña el papel de intermediario técnico entre ADO y el sistema subyacente de acceso a los datos.

Según la naturaleza de la cadena de conexión, el proveedor OLE DB utilizado varía. Cuando la cadena de conexión es de tipo ODBC (presencia de Driver=, Dsn=, o Provider=MSDASQL), el OLE DB Provider utilizado implícitamente es MSDASQL ("OLE DB Provider for ODBC"). En este caso, MSDASQL traduce las llamadas OLE DB emitidas por ADO en llamadas ODBC, comprensibles por el controlador ODBC de destino (MySQL, MariaDB, MS SQL Server, MS Access, MS Excel, etc.).

Por el contrario, cuando la cadena de conexión no hace ninguna referencia a ODBC (ausencia de Driver= o Dsn=), ADO utiliza entonces un OLE DB Provider nativo, diseñado específicamente para el motor de base de datos correspondiente (por ejemplo SQLOLEDB, MSOLEDBSQL, etc.), sin pasar por ODBC ni por MSDASQL.

MSDASQL ("OLE DB Provider for ODBC") solo se utiliza implícitamente si la cadena de conexión es de tipo ODBC (es decir, presencia de Dsn=, o Provider=MSDASQL). En ausencia de Provider= y de parámetros ODBC, ADO no inyecta automáticamente Provider=MSDASQL.

En resumen, el OLE DB Provider puede especificarse explícitamente mediante Provider= en la cadena de conexión. En su defecto, ADO deduce el provider que debe utilizar a partir del formato de la cadena de conexión: cuando esta es de tipo ODBC (presencia de Driver= o Dsn=), el provider utilizado implícitamente es MSDASQL.

Capa ADO

ADO (ActiveX Data Objects) es una biblioteca de acceso a datos de Microsoft utilizada por ASP Classic para manipular bases de datos. Es una capa de abstracción ligera sobre OLE DB que permite a las aplicaciones (en particular ASP Classic y VBScript) conectarse a fuentes de datos heterogéneas, ejecutar consultas y manipular resultados mediante una API uniforme compuesta por objetos como Connection, Command y Recordset.

ADO es por tanto la capa de software que crea los objetos Connection o Recordset, aplica las propiedades CursorType, llama a los métodos .Open(), .Execute(), .MoveNext(), .MoveLast(), y gestiona/devuelve la propiedad RecordCount.

ADO no es un driver; no sabe hablar directamente con el servidor MySQL, MariaDB, Microsoft SQL Server o MS Access. Cuando un script ASP consulta una base de datos, ADO transmite la consulta al Provider OLE DB que ha indicado en su cadena de conexión, pudiendo este último dialogar con el driver ODBC si ha especificado uno mediante Driver=. Este driver es el componente del sistema encargado de dialogar realmente con el servidor de bases de datos.

Capa OLE DB

OLE DB es la capa de adaptación entre ADO y la capa de acceso a los datos, pudiendo esta última ser un Driver ODBC o un Provider nativo. El papel de OLE DB es estandarizar los intercambios entre ADO y esta capa de acceso a los datos. OLE DB Provider for ODBC (MSDASQL) es un provider proporcionado por Microsoft que sirve de puente entre ADO y los drivers ODBC cuando la cadena de conexión apunta a un Driver ODBC mediante la presencia de Driver=.

Su uso es explícito mediante la instrucción Provider= en su cadena de conexión, o implícitamente Provider=MSDASQL por defecto si no se especifica Y su cadena de conexión hace referencia a un Driver ODBC especificado mediante el parámetro Driver=. En otras palabras, si Provider= está ausente de su cadena de conexión pero se requiere un driver ODBC mediante la presencia de Driver=, ADO utiliza entonces implícitamente MSDASQL en segundo plano para comunicarse con el Driver ODBC. Este mecanismo permite una retrocompatibilidad con las cadenas de conexión ODBC.

Tenga siempre presente que ADO no habla directamente con ODBC: cuando un script ASP utiliza una cadena de conexión con Driver=, ADO pasa por MSDASQL, que traduce las llamadas OLE DB de ADO en llamadas ODBC comprensibles por el driver (MySQL, MariaDB, etc.).

Capa ODBC

El Driver ODBC es el componente de bajo nivel que dialoga realmente con la base de datos. Por ello, cuando ADO se utiliza a través de un proveedor OLE DB para ODBC (MSDASQL), este transmite sus solicitudes (consultas, cursores, bloqueos) al driver ODBC, que es el encargado de aplicarlas o adaptarlas según sus capacidades

Cada Driver ODBC está diseñado por un proveedor distinto y se adapta a las capacidades y funcionalidades previstas por el motor de base de datos de destino. Esto explica los comportamientos a veces diferentes que pueden observarse con un código fuente idéntico, pero con un motor de base de datos diferente, o un Driver ODBC diferente, o incluso una versión diferente de una serie de Drivers ODBC, a pesar de llamadas ADO estrictamente idénticas aguas arriba.

Los tipos de cursores ADO

En ADO, los tipos de cursores (0=Forward-Only, 3=Static, 1=Keyset, 2=Dynamic) definen de qué manera se recorre un Recordset y se mantiene en la memoria del lado ASP, o en la memoria del servidor de bases de datos. Por tanto, estos tipos de cursores tienen un impacto directo en el rendimiento, el consumo de memoria y las funcionalidades disponibles para su Recordset.

La elección del cursor condiciona así la capacidad de desplazarse por el Recordset, de contar las filas, de ver los cambios concurrentes y de soportar la carga del lado del servidor o del cliente. El dominio de los cursores ADO es, por tanto, indispensable.

Los tipos de cursores ADO son los siguientes:

•  0 = adOpenForwardOnly (por defecto) :
  El cursor Forward-Only es el más rápido y el más ligero, pero solo permite una lectura secuencial.
•  1 = adOpenKeyset :
  El cursor Keyset permite ver las modificaciones de los demás registros existentes, con la excepción de las nuevas filas.
•  2 = adOpenDynamic :
  El cursor Dynamic refleja todas las modificaciones en tiempo real. Esto lo convierte en el cursor más costoso.
•  3 = adOpenStatic :
  El cursor Static carga una instantánea fija de los datos que permite una navegación libre dentro del recordset, pero a costa de un uso elevado de memoria.

Documentación oficial de Microsoft:

•  Funcionamiento de los cursores ADO 
•  Descripción de los tipos de cursores ADO 
•  Microsoft Cursor Engine 

Impactos del tipo de cursor ADO

Más allá de las consideraciones de rendimiento o de uso de memoria, el criterio principal al elegir un cursor es la manera en que piensa recorrerlo. Debe elegir entre las dos opciones siguientes:

•  "¿Voy a leer este recordset de una sola vez hacia adelante?" (cursor no scrollable),
•  O BIEN
•  "¿Necesito poder contar los registros, ordenar, filtrar, volver hacia atrás?" (cursor scrollable).

El tipo de cursor ADO que utiliza al acceder a un Recordset determina en gran medida las posibilidades que se ofrecen a su código para recorrer y manipular los datos. El tipo de cursor 0=adOpenForwardOnly es el que se utiliza por defecto cuando usa el método rs.Open() sin especificar la propiedad rs.CursorType, o bien cuando usa el método dbConn.Execute().

Cómo aprovechar los cursores ADO en ASP ?

PHP no se ve afectado por ADO + ODBC

Si su sitio incluye páginas PHP que acceden a bases de datos MySQL o MariaDB, sepa que casi nunca utilizan ODBC por defecto, salvo que usted lo haya programado explícitamente así en determinadas situaciones específicas. Sus páginas PHP se conectan generalmente a sus bases de datos mediante uno de los siguientes métodos:

•  mysqli
•  pdo_mysql
•  mysqlnd (driver nativo)
•  PDO con driver MySQL nativo

Por lo tanto, las conexiones a PHP generalmente se realizan sin utilizar la capa ADO a través de un componente COM, por ejemplo:

<?php
$user = 'testUser';
$pass = 'testPassword';
$pdoConn = new PDO('mysql:host=localhost;dbname=TestDB', $user, $pass, [
    PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
]);

$sqlStmt = $pdoConn->prepare('SELECT * FROM users WHERE field_1 = :field_1');
$sqlStmt->execute(['field_1' => $_GET['field_1']]);
$result = $sqlStmt->fetch();
?>

PHP puede utilizar ADO a través de COM (únicamente en Windows) en contextos heredados/legacy Windows/ADO o para necesidades muy específicas. Estas conexiones se llaman de la siguiente manera:

<?php
$conn = new COM("ADODB.Connection");
$conn->Open("Provider=MSOLEDBSQL;Server=localhost;Database=TestDB;Trusted_Connection=Yes;");
?>

ASP.NET no se ve afectado por ADO + ODBC

Si su sitio incluye páginas ejecutadas por la plataforma ASP.NET para acceder a bases de datos MySQL o MariaDB, sepa que no utilizan ADO, sino ADO.NET. Sus páginas .NET se conectan generalmente a sus bases de datos mediante uno de los siguientes métodos:

•  ADO.NET nativo (SqlConnection, SqlCommand, SqlDataReader, DataSet)
•  Entity Framework (EF / EF Core)
•  Dapper
•  NHibernate

CursorType permite un código ASP fiable y previsible

Cuando accede a datos a través de ADO y un Driver ODBC (o un Provider OLE DB nativo), desea asegurarse de que su código ASP funcione correctamente sin generar un error de servidor (HTTP 500). Algunas prácticas permisivas se han utilizado históricamente en el desarrollo ASP Classic, pudiendo a veces conducir a errores de ejecución o provocar comportamientos diferentes según el Provider OLE DB o el Driver ODBC utilizado (o incluso su versión instalada en el servidor de alojamiento).

ADO es una interfaz estática, fiable y previsible, incluida en Windows + IIS. Por tanto, sus sitios ASP pueden contar con ella.

En cambio, los Providers OLE DB y los Drivers ODBC, por su parte, evolucionan periódicamente. Aquellos que utiliza o ha utilizado en el pasado para acceder a los datos a través de ADO pueden tener comportamientos diferentes según los motores de bases de datos o las versiones del Provider/Driver. Esto puede conducir a situaciones en las que el mismo código fuente provoca errores en algunos servidores o con algunos Drivers, y no con otros.

Con el fin de hacer que su código ASP Classic sea fiable y resistente al paso del tiempo cuando accede a datos a través de ADO, y ello sea cual sea el Driver ODBC utilizado, su código debería idealmente desarrollarse respetando las siguientes buenas prácticas. Estas consisten en especificar explícitamente los tipos de cursor en su código ASP, con el fin de obtener resultados y funcionalidades previsibles en su Recordset.

Compatibilidad de las funcionalidades ADO por Cursor

Esta tabla presenta los principales métodos y propiedades ADO autorizados y desaconsejados según cada tipo de cursor ADO (CursorType).

Todos los tipos de cursor, incluido el CursorType 0=adOpenForwardOnly, le permiten utilizar los siguientes métodos y propiedades:

• BOF
• EOF
• MoveNext
• Fields
• Fields.Item
• Fields.Item("fieldname").Value
• GetRows
• GetString
• State
• ActiveConnection
• Source
• CursorType (retourne 0)
• CursorLocation
• LockType
• CacheSize
• MarshalOptions

Consejos para un código ASP Classic fiable con ADO + ODBC

Utilizar un CursorType=0 (adOpenForwardOnly) para las lecturas simples de un Recordset

Su Recordset se abre en modo "0=Forward-Only" cuando:

•  o bien cuando utiliza el método dbConn.Execute()
•  o bien cuando utiliza el método rs.Open() sin haber especificado previamente el tipo de cursor en la propiedad rs.CursorType. ADO utiliza entonces el tipo de cursor por defecto, es decir 0=adOpenForwardOnly. En este caso, el Recordset solo permite una lectura secuencial.

Ejemplos de apertura en modo "0=Forward-Only" (resaltados en amarillo) :

<%
'Abrir la conexión
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.Open dbConnString

'Abrir el Recordset en modo "Forward-Only" mediante .Open()
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open strSQL, dbConn

''O bien: abrir el Recordset en modo "Forward-Only" mediante .Execute()
'Set rs = dbConn.Execute(strSQL)
%>

Los únicos métodos y propiedades disponibles en su Recordset abierto en modo 0=Forward-Only son:

• BOF
• EOF
• MoveNext
• Fields
• Fields.Item
• Fields.Item("fieldname").Value
• GetRows
• GetString
• State
• ActiveConnection
• Source
• CursorType (retourne 0)
• CursorLocation
• LockType
• CacheSize
• MarshalOptions

No confíe en .RecordCount, que siempre devolverá -1. Busque en su código todos los usos de la propiedad .RecordCount y asegúrese de que el Recordset se haya abierto con rs.Open() + un rs.CursorType diferente de 0, y de que no se haya abierto con dbConn.Execute().

La única prueba robusta e independiente del tipo de cursor que le permite asegurarse de la presencia de registros en su Recordset es la siguiente:

<%
'Si el Recordset contiene registros
if ((NOT rs.BOF) AND (NOT rs.EOF)) then
   do while NOT rs.EOF
      'Devolver el valor del campo "field_1"
      Response.Write rs("field_1")
      'Pasar al registro siguiente
      rs.MoveNext
   loop
end if
%>

Las operaciones de desplazamiento de tipo rs.MovePrevious() o rs.MoveLast() pueden a veces funcionar cuando su Recordset está abierto en modo 0=Forward-Only. Esto ocurre si no ha especificado el rs.CursorType, pero ha indicado rs.CursorLocation=3 (adUseClient). En este caso, ADO puede decidir poner el recordset en caché del lado del cliente, lo que transforma implícitamente el cursor y lo hace scrollable/desplazable.

No obstante, este comportamiento no está garantizado, y sigue siendo incoherente con la propia definición de un cursor 0=Forward-Only. Por tanto, no debe basar la lógica de su código en este caso particular: especificar explícitamente un rs.CursorType distinto de 0=adOpenForwardOnly sigue siendo el método más seguro.

Si necesita utilizar la propiedad .RecordCount, o bien si necesita filtrar o desplazarse dentro del Recordset (ej. .Filter, .PageSize, .MovePrevious), entonces debe obligatoriamente utilizar el método rs.Open() especificando el .CursorType. Obtendrá entonces un Recordset scrollable/desplazable.

Especificar el CursorType antes de cada llamada a rs.Open

Cuando utilice el método rs.Open(), debe obligatoriamente especificar previamente el tipo de cursor en la propiedad rs.CursorType. Proceda de la siguiente manera:

<%
Set rs = Server.CreateObject("ADODB.Recordset")
'Especificar el tipo de cursor
rs.CursorLocation = 3 'adUseClient (preferiblemente, ya que los cursores del lado del servidor dependen del Driver ODBC)
rs.CursorType     = 3 'adOpenStatic (o bien 1 o 2 según sus necesidades)
rs.LockType       = 1 'adLockReadOnly (el más rápido si no hay escritura)

'Abrir el Recordset de manera desplazable
rs.Open strSQL, dbConn
%>

A excepción de rs.CursorType = 0 'adOpenForwardOnly, todos los demás tipos de cursor le permiten beneficiarse de un Recordset scrollable/desplazable — siendo rs.CursorType = 3 'adOpenStatic preferible. Entonces puede utilizar los siguientes métodos y propiedades:

• RecordCount
• MoveFirst
• MoveLast
• MovePrevious
• AbsolutePage
• PageSize
• PageCount
• Sort
• Filter

Ahora dispone de acceso a la propiedad .RecordCount, y puede entonces comprobar el número de registros contenidos en el Recordset:

<%
'El recordset ha sido almacenado en caché en memoria del lado cliente
'gracias a que rs.CursorType es diferente de 0.
'La propiedad .Recordcount es por lo tanto calculable y refleja el número real de filas recuperadas
if (rs.RecordCount <> 0) then
   'Hacer algo
end if
%>

Si únicamente necesita leer los resultados uno tras otro de manera secuencial, puede omitir esta propiedad CursorType: ADO utilizará entonces el tipo de cursor por defecto, es decir 0=adOpenForwardOnly. También puede en ese caso hacer una simple llamada a dbConn.Execute().

Especificar el CursorType=3 (adOpenStatic) para cualquier desplazamiento u ordenación en un Recordset

Cuando abra un Recordset con vistas a ordenarlo, filtrarlo o desplazarse hacia delante y hacia atrás, utilice únicamente el CursorType = 3 'adOpenStatic.

Aunque en la práctica todos los cursores distintos de rs.CursorType = 0 'adOpenForwardOnly le permiten estas operaciones, ello solo se debe a que ha indicado a ADO un cursor del lado del cliente con rs.CursorLocation = 3 'adUseClient. ADO pone entonces los datos en caché a través del Microsoft Cursor Engine . Este comportamiento depende en realidad de las 3 capas siguientes:

•  La versión de ADO,
•  El Provider OLE DB (ej. MSDASQL),
•  El Driver ODBC.

Con el fin de protegerse contra cualquier efecto indeseable en su código, y hacerlo resistente al paso del tiempo, solo el CursorType = 3 'adOpenStatic le permite hacer un uso fiable y previsible de los siguientes métodos y propiedades:

• RecordCount
• MoveFirst
• MoveLast
• MovePrevious
• AbsolutePage
• PageSize
• PageCount
• Sort
• Filter

El CursorType = 3 'adOpenStatic posee las siguientes características:

•  Crea una instantánea completa del conjunto de resultados,
•  ADO conoce todas las filas desde la apertura,
•  La paginación es determinista y previsible.

Por tanto, el CursorType = 3 'adOpenStatic es el único tipo de cursor que:

•  Fija el conjunto de resultados,
•  Garantiza un RecordCount estable,
•  Garantiza la paginación ADO,
•  Permite un desplazamiento arbitrario hacia delante o hacia atrás dentro del Recordset,
•  Se comporta de manera idéntica con los Drivers MySQL ODBC 3.51 y 5.3 así como MariaDB 3.1 y 3.2.

Los CursorType = 1 'adOpenKeyset o 2 = adOpenDynamic pueden funcionar, pero tenga en cuenta los siguientes puntos:

•  El contenido del Recordset puede evolucionar durante su ciclo de vida,
•  El número total de filas no está fijado,
•  ADO puede mostrarse incapaz de garantizar un PageCount estable,
•  El uso de otro Driver ODBC (u otra versión) puede modificar el comportamiento de su código.

Especificar CursorLocation=3 (adUseClient) para cualquier uso de rs.Sort y rs.Filter

Las operaciones de ordenación y filtrado de un Recordset solo funcionan correctamente con un cursor del lado del cliente rs.CursorLocation = 3 'adUseClient. Los cursores del lado del motor de base de datos no admiten estas operaciones.

Gestión de los cursores ADO con el Driver Microsoft SQL Server

El Driver ODBC Microsoft SQL Server proporciona una compatibilidad real y óptima del cursor Forward-Only del lado del servidor. Cuando especifica otro tipo de cursor mediante la propiedad rs.CursorType, este se respeta.

Existen diferentes opciones para establecer la conexión a sus bases MSSQL (enlace externo ).

Gestión de los cursores ADO con el Driver Microsoft Access

El Driver ODBC Microsoft Access emula con frecuencia en memoria (bufferización) el cursor Forward-Only. El rendimiento es correcto en conjuntos de datos de tamaño modesto. Cuando especifica otro tipo de cursor mediante la propiedad rs.CursorType, este se respeta.

Consulte nuestro artículo para descubrir las diferentes opciones disponibles para establecer la conexión a sus bases Microsoft Access.

Gestión de los cursores ADO con el Driver MySQL

El Driver ODBC MySQL 3.51 / 5.3 carga con frecuencia la totalidad del conjunto de datos en memoria (bufferización) para emular el cursor Forward-Only, ya que el controlador ODBC MySQL históricamente no dispone de un verdadero cursor del lado del servidor. El uso de memoria y el rendimiento pueden degradarse con conjuntos de datos importantes.

Cursor predeterminado del Driver MySQL ODBC 3.51

La norma ODBC exige que cada Driver ODBC utilice por defecto un cursor Forward-Only (SQL_CURSOR_FORWARD_ONLY) si el tipo de cursor no se proporciona en las OPTION al establecer la conexión a la base de datos mediante ADO.Connection, o al abrir el ADODB.Recordset mediante la propiedad rs.CursorType.

El Driver {MySQL ODBC 3.51 Driver} (MySQL Connector/ODBC 3.51) implementa la interfaz ODBC 3.5x, y por tanto admite las funcionalidades ODBC v3, pero no estrictamente ODBC 3.8.

En la práctica, el tipo de cursor 0=adOpenForwardOnly es utilizado por defecto por ADO antes del establecimiento de la conexión ODBC cuando utiliza el método rs.Open() sin especificar la propiedad rs.CursorType, o bien cuando utiliza el método dbConn.Execute(). En efecto, ADO interviene aguas arriba del Driver ODBC, cuyo valor predeterminado solo se utilizaría si la capa superior (es decir, ADO) no especificara nada. ADO nunca cede el control al Driver ODBC, y especifica por defecto un cursor Forward-Only si no ha configurado explícitamente la propiedad rs.CursorType.

Por ello, el cursor predeterminado del Driver ODBC nunca se utiliza con ADO, que tiene prioridad. Si su código ASP Classic siempre ha funcionado correctamente con el Driver {MySQL ODBC 3.51 Driver} utilizado a través de ADO, es casi seguro que funcionará de manera idéntica con otras versiones de Drivers ODBC MySQL o MariaDB, puesto que ADO respetará sus elecciones mediante rs.CursorType, o utilizará por defecto el cursor 0=adOpenForwardOnly como siempre lo ha hecho.

ADO especifica, por supuesto, al Driver ODBC los demás tipos de cursor si usted especifica uno explícitamente en la propiedad rs.CursorType. Tenga presente que el Driver ODBC puede en algunos casos utilizar y devolver otro tipo de cursor: la norma ADO lo permite. Por tanto, es prudente asegurarse de que su código fuente ASP Classic respeta las siguientes buenas prácticas.

Cursor predeterminado del Driver MySQL ODBC 5.3

El Driver {MySQL ODBC 5.3 Unicode Driver} (MySQL Connector/ODBC 5.3) implementa la interfaz ODBC 3.8 de manera estricta, incluidas sus variantes Unicode y ANSI. Esto significa que utiliza por defecto un cursor Forward-Only (SQL_CURSOR_FORWARD_ONLY) si el tipo de cursor no se proporciona en las OPTION al establecer la conexión a la base de datos mediante ADO.Connection, o al abrir el ADODB.Recordset mediante la propiedad rs.CursorType.

En la práctica, el tipo de cursor 0=adOpenForwardOnly es utilizado por defecto por ADO antes del establecimiento de la conexión ODBC cuando utiliza el método rs.Open() sin especificar la propiedad rs.CursorType, o bien cuando utiliza el método dbConn.Execute(). En efecto, ADO interviene aguas arriba del Driver ODBC, cuyo valor predeterminado solo se utilizaría si la capa superior (es decir, ADO) no especificara nada. ADO nunca cede el control al Driver ODBC, y especifica por defecto un cursor Forward-Only si no ha configurado explícitamente la propiedad rs.CursorType.

Por ello, el cursor predeterminado del Driver ODBC nunca se utiliza con ADO, que tiene prioridad. Si su código ASP Classic siempre ha funcionado correctamente con el Driver {MySQL ODBC 5.3 Unicode Driver} utilizado a través de ADO, es casi seguro que funcionará de manera idéntica con otras versiones de Drivers ODBC MySQL o MariaDB, puesto que ADO respetará sus elecciones mediante rs.CursorType, o utilizará por defecto el cursor 0=adOpenForwardOnly como siempre lo ha hecho.

ADO especifica, por supuesto, al Driver ODBC los demás tipos de cursor si usted especifica uno explícitamente en la propiedad rs.CursorType. Tenga presente que el Driver ODBC puede en algunos casos utilizar y devolver otro tipo de cursor: la norma ADO lo permite. Por tanto, es prudente asegurarse de que su código fuente ASP Classic respeta las siguientes buenas prácticas.

Utilizar el modo Forward-Only (streaming) del lado del servidor (motor MySQL)

Cuando no especifica el tipo de cursor, o indica explícitamente el cursor Forward-Only, es posible pedir al Driver ODBC MySQL utilizado a través de ADO que no cargue en memoria el conjunto completo de registros del lado del cliente, sino que recorra realmente el conjunto de registros fila por fila del lado del motor de base de datos. Se trata de un modo "streaming" real.

Los datos no se cargan de una sola vez del lado ASP, sino fila por fila en cada llamada a rs.MoveNext(). La consulta SQL no se vuelve a ejecutar en cada llamada a rs.MoveNext(), sino que se ejecuta una sola vez: el Driver ODBC recupera las filas progresivamente desde el servidor, según un mecanismo equivalente al modelo mysql_use_result(). Cada llamada a rs.MoveNext() constituye un “fetch” (una lectura) que lee la continuación del flujo. La ventaja es una disminución del uso de memoria del lado del cliente (motor ASP), ya que el Driver no almacena en caché la totalidad del Recordset.

Tenga en cuenta que el uso de esta técnica presenta un inconveniente: mientras consume este flujo, la conexión queda “bloqueada”. Por tanto, debe terminar de leer y luego liberar el resultado antes de ejecutar cualquier otra cosa en la misma conexión, lo que puede movilizar los recursos del lado del servidor durante más tiempo.

Tenga en cuenta que el uso de esta técnica es compatible pero inútil cuando se utiliza el método ADO rs.GetRows(). En efecto, el método ADO rs.GetRows() copia todas las filas restantes (opción adGetRowsRest) en un array en memoria, lo que hace perder de facto la ventaja del bajo uso de memoria de este método de "streaming". En efecto, el método rs.GetRows() hace que toda la carga de memoria recaiga del lado ASP, en forma de array (Array 2D).

Implementación

Para implementar esta técnica, debe activar un cursor Forward-Only y desactivar la caché del lado del Driver MySQL.

Añada el valor de los siguientes Flags al parámetro OPTION de su cadena de conexión:

• 1048576 (NO_CACHE)
• 2097152 (FORWARD_CURSOR)

Si establece su conexión mediante un DSN, puede que deba añadir Provider=MSDASQL; DSN=MonDSN; a su cadena de conexión. No obstante, añadir explícitamente Provider=MSDASQL; a su cadena de conexión es inútil en el caso de una conexión DSN-Less establecida desde su código ASP.

Gestión de los cursores ADO con el Driver MariaDB

El Driver ODBC MariaDB 3.1 / 3.2 carga con frecuencia la totalidad del conjunto de datos en memoria (bufferización) para emular el cursor Forward-Only, ya que el controlador ODBC MariaDB históricamente no dispone de un verdadero cursor del lado del servidor. El uso de memoria y el rendimiento pueden degradarse con conjuntos de datos importantes.

Cursor predeterminado del Driver MariaDB ODBC 3.1

La norma ODBC exige que cada Driver ODBC utilice por defecto un cursor Forward-Only (SQL_CURSOR_FORWARD_ONLY) si el tipo de cursor no se proporciona en las OPTION al establecer la conexión a la base de datos mediante ADO.Connection, o al abrir el ADODB.Recordset mediante la propiedad rs.CursorType.

El Driver {MariaDB ODBC 3.1 Driver} implementa la interfaz ODBC 3 y, por tanto, admite sus funcionalidades, pero no estrictamente ODBC 3.8.

En particular, el Driver {MariaDB ODBC 3.1 Driver} utiliza por defecto un cursor estático (SQL_CURSOR_STATIC), lo que difiere de la norma ODBC 3.8.

En la práctica, el tipo de cursor 0=adOpenForwardOnly es utilizado por defecto por ADO antes del establecimiento de la conexión ODBC cuando utiliza el método rs.Open() sin especificar la propiedad rs.CursorType, o bien cuando utiliza el método dbConn.Execute(). En efecto, ADO interviene aguas arriba del Driver ODBC, cuyo valor predeterminado solo se utilizaría si la capa superior (es decir, ADO) no especificara nada. ADO nunca cede el control al Driver ODBC, y especifica por defecto un cursor Forward-Only si no ha configurado explícitamente la propiedad rs.CursorType.

Por ello, el cursor predeterminado del Driver ODBC nunca se utiliza con ADO, que tiene prioridad. Si su código ASP Classic siempre ha funcionado correctamente con el Driver {MariaDB ODBC 3.1 Driver} utilizado a través de ADO, es casi seguro que funcionará de manera idéntica con otras versiones de Drivers ODBC MySQL o MariaDB, puesto que ADO respetará sus elecciones mediante rs.CursorType, o utilizará por defecto el cursor 0=adOpenForwardOnly como siempre lo ha hecho.

ADO especifica, por supuesto, al Driver ODBC los demás tipos de cursor si usted especifica uno explícitamente en la propiedad rs.CursorType. Tenga presente que el Driver ODBC puede en algunos casos utilizar y devolver otro tipo de cursor: la norma ADO lo permite. Por tanto, es prudente asegurarse de que su código fuente ASP Classic respeta las siguientes buenas prácticas.

Cursor predeterminado del Driver MariaDB ODBC 3.2

El Driver {MariaDB ODBC 3.2 Driver} implementa la interfaz ODBC 3.8 de manera estricta. Esto significa que utiliza por defecto un cursor Forward-Only (SQL_CURSOR_FORWARD_ONLY) si el tipo de cursor no se proporciona en las OPTION al establecer la conexión a la base de datos mediante ADO.Connection, o al abrir el ADODB.Recordset mediante la propiedad rs.CursorType.

Esta alineación con la norma ODBC 3.8 difiere del comportamiento que se observaba anteriormente con el Driver {MariaDB ODBC 3.1 Driver}, que utilizaba por defecto un cursor estático (SQL_CURSOR_STATIC). Esta alineación del Driver MariaDB 3.2 con la norma ODBC 3.8 tiene como consecuencia accesos a las bases más rápidos y fiables que con la versión anterior 3.1 del Driver ODBC.

Este cambio está documentado en las notas de versión  del Driver ODBC 3.2 de MariaDB, en estos términos:

ODBC-290 = Cursor type now defaults to SQL_CURSOR_FORWARD_ONLY as it is required by specs. 3.1.x series has default cursor type SQL_CURSOR_STATIC.

En la práctica, el tipo de cursor 0=adOpenForwardOnly es utilizado por defecto por ADO antes del establecimiento de la conexión ODBC cuando utiliza el método rs.Open() sin especificar la propiedad rs.CursorType, o bien cuando utiliza el método dbConn.Execute(). En efecto, ADO interviene aguas arriba del Driver ODBC, cuyo valor predeterminado solo se utilizaría si la capa superior (es decir, ADO) no especificara nada. ADO nunca cede el control al Driver ODBC, y especifica por defecto un cursor Forward-Only si no ha configurado explícitamente la propiedad rs.CursorType.

Por ello, el cursor predeterminado del Driver ODBC nunca se utiliza con ADO, que tiene prioridad. Si su código ASP Classic siempre ha funcionado correctamente con el Driver {MySQL ODBC 5.3 Unicode Driver} utilizado a través de ADO, es casi seguro que funcionará de manera idéntica con otras versiones de Drivers ODBC MySQL o MariaDB, puesto que ADO respetará sus elecciones mediante rs.CursorType, o utilizará por defecto el cursor 0=adOpenForwardOnly como siempre lo ha hecho.

ADO especifica, por supuesto, al Driver ODBC los demás tipos de cursor si usted especifica uno explícitamente en la propiedad rs.CursorType. Tenga presente que el Driver ODBC puede en algunos casos utilizar y devolver otro tipo de cursor: la norma ADO lo permite. Por tanto, es prudente asegurarse de que su código fuente ASP Classic respeta las siguientes buenas prácticas.

Utilizar el modo Forward-Only (streaming) del lado del servidor (motor MariaDB)

Cuando no especifica el tipo de cursor, o indica explícitamente el cursor Forward-Only, es posible pedir al Driver ODBC MariaDB utilizado a través de ADO que no cargue en memoria el conjunto completo de registros del lado del cliente, sino que recorra realmente el conjunto de registros fila por fila del lado del motor de base de datos. Se trata de un modo "streaming" real.

Esta funcionalidad está disponible desde la versión 3.1.17 del Driver ODBC MariaDB, como se indica en la documentación de MariaDB .

Los datos no se cargan de una sola vez del lado ASP, sino fila por fila en cada llamada a rs.MoveNext(). La consulta SQL no se vuelve a ejecutar en cada llamada a rs.MoveNext(), sino que se ejecuta una sola vez: el Driver ODBC recupera las filas progresivamente desde el servidor, según un mecanismo equivalente al modelo mysql_use_result(). Cada llamada a rs.MoveNext() constituye un “fetch” (una lectura) que lee la continuación del flujo. La ventaja es una disminución del uso de memoria del lado del cliente (motor ASP), ya que el Driver no almacena en caché la totalidad del Recordset.

Tenga en cuenta que el uso de esta técnica es compatible pero inútil cuando se utiliza el método ADO rs.GetRows(). En efecto, el método ADO rs.GetRows() copia todas las filas restantes (opción adGetRowsRest) en un array en memoria, lo que hace perder de facto la ventaja del bajo uso de memoria de este método de "streaming". En efecto, el método rs.GetRows() hace que toda la carga de memoria recaiga del lado ASP, en forma de array (Array 2D).

Comportamiento con MariaDB ODBC 3.1

El uso de esta técnica con el Driver MariaDB ODBC 3.1 presenta un inconveniente: mientras consume este flujo, la conexión queda “bloqueada”. Por tanto, debe terminar de leer y luego liberar el resultado antes de ejecutar cualquier otra cosa en la misma conexión, lo que puede movilizar los recursos del lado del servidor durante más tiempo.

Comportamiento con MariaDB ODBC 3.2

El uso de esta técnica con el Driver MariaDB ODBC 3.2 mejora significativamente el inconveniente que estaba presente anteriormente en el Driver MariaDB ODBC 3.1. En efecto, como se indica en las notas de versión , el Driver 3.2.1 (y posteriores) mejora la resiliencia del protocolo durante el tratamiento continuo de los resultados. Mientras que en la versión 3.1, el uso del tratamiento continuo de los resultados bloqueaba la conexión y devolvía un error ante cualquier nueva consulta, el Driver 3.2.1 pone ahora en caché el resto de los resultados que están siendo procesados, y ejecuta sin esperar cualquier nueva consulta sin error. Esta mejora aporta una conexión ininterrumpida y refuerza la fiabilidad del Driver.

Implementación

Para implementar esta técnica, debe activar un cursor Forward-Only y desactivar la caché del lado del Driver MariaDB.

Añada el valor de los siguientes Flags al parámetro OPTION de su cadena de conexión:

• 1048576 (NO_CACHE)
• 2097152 (FORWARD_CURSOR)

O bien añada estos parámetros a su cadena de conexión:

• FORWARDONLY=1;
• NO_CACHE=1;

Si establece su conexión mediante un DSN, puede que deba añadir Provider=MSDASQL; DSN=MonDSN; a su cadena de conexión. No obstante, añadir explícitamente Provider=MSDASQL; a su cadena de conexión es inútil en el caso de una conexión DSN-Less establecida desde su código ASP.

Alojamiento ASP Classic

Alojamiento ASP Classic y migración a Windows Server 2025 / 2022 / 2019

Mantenimiento y desarrollo ASP Classic

Mantenimiento, soporte y desarrollo de sitios y aplicaciones ASP Classic

Auditoría y configuración de IIS

Auditoría y mejora de la configuración de Microsoft® IIS