Se debe añadir lo siguiente al final de la sección "Aplicaciones mixtas de varias hebras":
Debe añadirse la información siguiente a la sección "Cursores desplazables":
El cliente UDB para las plataformas Unix, Windows y OS/2 da soporte a cursores desplazables en el extremo del servidor cuando se ejecutan frente bases de datos de OS/390 Versión 7. Para acceder a un cursor desplazable de OS/390 en un entorno de tres niveles, el cliente y la pasarela deben estar ejecutando DB2 UDB Versión 7.1, FixPak 3 o posterior.
Hay dos interfaces de habilitación de aplicaciones que pueden acceder a los cursores desplazables: ODBC y JDBC. La interfaz JDBC sólo puede acceder a cursores desplazables estáticos, mientras que la interfaz ODBC puede acceder a cursores desplazables en el extremo del servidor estáticos y controlados por conjuntos de claves.
La tabla siguiente lista los atributos por omisión para cursores de OS/390
Versión 7 en ODBC.
Tabla 23. Atributos por omisión para cursores de OS/390 en ODBC
Tipo de cursor | Sensibilidad del cursor | Cursor actualizable | Simultaneidad del cursor | Cursor desplazable |
---|---|---|---|---|
sólo reenvíoa | no especificada | no actualizable | simultaneidad de sólo lectura | no desplazable |
estático | no sensible | no actualizable | simultaneidad de sólo lectura | desplazable |
controlado por conjunto de claves | sensible | actualizable | simultaneidad de valores | desplazable |
|
Se da soporte a todas las orientaciones de captación de ODBC mediante las interfaces SQLFetchScroll o SQLExtendedFetch.
Un cursor controlado por conjunto de claves es un cursor actualizable. El controlador de CLI añade la cláusula FOR UPDATE a la consulta, excepto cuando se emite la consulta como consulta SELECT ... FOR READ ONLY o si la cláusula FOR UPDATE ya existe. El cursor controlado por conjunto de claves implementado en DB2 para OS/390 es un cursor de simultaneidad de valores. Un cursor de simultaneidad de valores ocasiona el bloqueo optimista, en el que no se mantienen los bloqueos hasta que se intenta llevar a cabo una actualización o supresión. Cuando se intenta realizar una actualización o supresión, el servidor de bases de datos compara los valores anteriores que la aplicación ha recuperado con los valores actuales de la tabla subyacente. Si los valores coinciden, la actualización o supresión es satisfactoria. Si los valores no coinciden, la operación es anómala. Si se produce una anomalía, la aplicación deberá consultar de nuevo los valores y volver a emitir la actualización o supresión si todavía es aplicable.
Una aplicación puede actualizar un cursor controlado por conjunto de claves de dos formas:
Puesto que el soporte a cursores desplazables es nuevo, algunas
aplicaciones ODBC que funcionaban con releases anteriores de UDB para OS/390 o
UDB para Unix, Windows, y OS/2 pueden encontrar cambios de comportamiento de
rendimiento. Esto sucede debido a que antes de que se diese soporte a
los cursores desplazables, las aplicaciones que solicitaban un cursor
desplazable recibían un cursor de sólo reenvío. Para restaurar el
comportamiento anterior de una aplicación de antes del soporte a cursores
desplazables, establezca la siguientes palabras clave de configuración en el
archivo db2cli.ini:
Valor de palabra clave de configuración | Descripción |
---|---|
PATCH2=6 | Devuelve un mensaje que indica que no se da soporte a los cursores desplazables (tanto controlados por conjunto de claves como estáticos). CLI degrada automáticamente cualquier petición de cursor desplazable a cursor de sólo reenvío. |
DisableKeysetCursor=1 | Inhabilita los cursores desplazables controlados por conjunto de claves del extremo del servidor y del extremo del cliente. Esto puede utilizarse para forzar al controlador CLI a dar a la aplicación un cursor estático cuando se solicita un cursor controlado por conjunto de claves. |
UseServerKeysetCursor=0 | Inhabilita el cursor controlado por conjunto de claves del extremo del servidor para aplicaciones que utilizan la biblioteca de cursores controlados por conjunto de claves del extremo del cliente para simular un cursor controlado por conjunto de claves. Utilice esta opción únicamente cuando aparezcan problemas con el cursor controlado por conjunto de claves del extremo del servidor, puesto que el cursor del extremo del cliente asume una gran cantidad de actividad general y, normalmente, tendrá un rendimiento menor que un cursor del extremo del servidor. |
Falta la nota siguiente en el manual:
Cualquier sentencia SQL que se pueda preparar dinámicamente, que no sea una consulta, se puede ejecutar como una sentencia dentro de una sentencia compuesta. Nota: Dentro de Atomic Compound SQL, tampoco están permitidas las sentencias SQL savepoint, release savepoint ni rollback to savepoint. Y, a la inversa, no está permitido Atomic Compound SQL en savepoint.
A continuación se proporciona una limitación no documentada para los procedimientos almacenados de CLI:
Si está realizando llamadas a varios procedimientos almacenados de CLI la aplicación debe cerrar los cursores abiertos desde un procedimiento almacenado antes de llamar al siguiente procedimiento almacenado. Más específicamente, debe cerrarse el primer conjunto de cursores abiertos antes de que el siguiente procedimiento almacenado intente abrir un cursor.
Lo siguiente complementa la información del manual:
El controlador de CLI/ODBC normalmente vinculará automáticamente los paquetes de CLI la primera vez que una aplicación CLI/ODBC ejecute SQL en la base de datos, siempre que el usuario tenga el privilegio o autorización adecuados. La vinculación automática de los paquetes de CLI no puede realizarse desde el interior de un procedimiento almacenado y, por lo tanto, no se realizará si lo primero que hace una aplicación es llamar a un procedimiento almacenado de CLI. Antes de ejecutar una aplicación de CLI que llame a un procedimiento almacenado de CLI en una base de datos de DB2 nueva, debe vincular los paquetes de CLI una vez con este mandato:
db2 bind <BNDPATH>/@db2cli.lst blocking all
db2bind "%DB2PATH%\bnd\@db2cli.lst" blocking
El enfoque recomendado consiste en vincular siempre estos paquetes cuando se crea la base datos para evitar la vinculación automática en tiempo de ejecución. La vinculación automática puede fallar si el usuario no tiene el privilegio o si otra aplicación intenta realizar la vinculación automática al mismo tiempo.