Se debe añadir lo siguiente al final de la sección "Aplicaciones mixtas de varias hebras":
A continuación se muestra una sección nueva para este capítulo:
Hay dos áreas principales de soporte para las aplicaciones Unicode de DB2 CLI:
Las secciones siguientes proporcionan más información sobre ambas áreas. Para que una aplicación se considere una aplicación Unicode, la aplicación debe establecer el atributo de conexión SQL_ATTR_ANSI_APP en SQL_AA_FALSE, antes de efectuar una conexión. Esto asegurará que la CLI utilice Unicode como el método preferido de comunicaciones entre ella misma y la base de datos.
Las funciones de API ODBC tienen sufijos para indicar el formato de los argumentos de serie: las que aceptan unicode terminan en W; las que aceptan ANSI no tienen sufijo.
SQLBrowseConnect SQLForeignKeys SQLPrimaryKeys SQLColAttribute SQLGetConnectAttr SQLProcedureColumns SQLColAttributes SQLGetConnectOption SQLProcedures SQLColumnPrivileges SQLGetCursorName SQLSetConnectAttr SQLColumns SQLGetDescField SQLSetConnectOption SQLConnect SQLGetDescRec SQLSetCursorName SQLDataSources SQLGetDiagField SQLSetDescField SQLDescribeCol SQLGetDiagRec SQLSetStmtAttr SQLDriverConnect SQLGetInfo SQLSpecialColumns SQLGetStmtAttr SQLStatistics SQLError SQLNativeSQL SQLTablePrivileges SQLExecDirect SQLPrepare SQLTables
Las funciones Unicode cuyos argumentos tienen siempre la longitud de las series interpretan estos argumentos como la cuenta de caracteres. Las funciones que devuelven información de longitud para datos de servidor también describen el tamaño y la precisión de la pantalla en términos de caracteres. Cuando la longitud (tamaño de transferencia de los datos) puede hacer referencia a datos de tipo serie o de tipo no serie, la longitud se interpreta como una cuenta de bytes. Por ejemplo, SQLGetInfoW siempre adoptará la longitud como número de bytes, pero SQLExecDirectW utilizará número de caracteres. La CLI devolverá datos de los conjuntos de resultados en Unicode o ANSI, en función de la vinculación de la aplicación. Si una aplicación se vincula a SQL_C_CHAR, el controlador convertirá datos SQL_WCHAR en SQL_CHAR. Un gestor de controladores ODBC, si se utiliza, correlaciona SQL_C_WCHAR con SQL_C_CHAR para controladores ANSI pero no realiza ninguna correlación para controladores Unicode.
Se han añadido tipos de datos definidos adicionales ODBC y CLI para adaptar las bases de datos Unicode. Estos tipos complementan el conjunto de tipos C y SQL que ya existen. El nuevo tipo C, SQL_C_WCHAR, indica que el almacenamiento intermedio C contiene datos UCS-2 en formato endian nativo. Los nuevos tipos SQL, SQL_WCHAR, SQL_WVARCHAR y SQL_WLONGVARCHAR, indican que un marcador de parámetro o columna determinado contiene datos Unicode. Para bases de datos DB2 Unicode, las columnas gráficas se describirán utilizando los tipos nuevos.
Tabla 11. Conversiones de datos soportadas
Tipo de datos SQL |
S Q L _ C _ C H A R |
S Q L _ C _ W C H A R |
S Q L _ C _ L O N G |
S Q L _ C _ S H O R T |
S Q L _ C _ T I N Y I N T |
S Q L _ C _ F L O A T |
S Q L _ C _ D O U B L E |
S Q L _ C _ T Y P E _ D A T E |
S Q L _ C _ T Y P E _ T I M E |
S Q L _ C _ T Y P E _ T I M E S T A M P |
S Q L _ C _ B I N A R Y |
S Q L _ C _ B I T |
S Q L _ C _ D B C H A R |
S Q L _ C _ C L O B _ L O C A T O R |
S Q L _ C _ B L O B _ L O C A T O R |
S Q L _ C _ D B C L O B _ L O C A T O R |
S Q L _ C _ B I G I N T |
S Q L _ C _ N U M E R I C |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
BLOB |
X |
X |
|
|
|
|
|
|
|
|
D |
|
|
|
X | |||
CHAR |
D |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X | |
CLOB |
D |
X |
|
|
|
|
|
|
|
|
X |
|
|
X |
| |||
DATE |
X |
X |
|
|
|
|
|
D |
|
X |
|
|
|
|
| |||
DBCLOB |
|
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
X | ||
DECIMAL |
D |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X |
|
|
|
X |
X | |
DOUBLE |
X |
X |
X |
X |
X |
X |
D |
|
|
|
|
X |
|
|
|
X |
X | |
FLOAT |
X |
X |
X |
X |
X |
X |
D |
|
|
|
|
X |
|
|
|
X |
X | |
GRAPHIC (No Unicode) |
X |
X |
|
|
|
|
|
|
|
|
|
|
D |
|
| |||
GRAPHIC (Unicode) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
D |
|
|
|
X |
|
INTEGER |
X |
X |
D |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
X |
X | |
LONG VARCHAR |
D |
X |
|
|
|
|
|
|
|
|
X |
|
|
|
| |||
LONG VARGRAPHIC (No Unicode) |
X |
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
| |||
LONG VARGRAPHIC (Unicode) |
X |
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
|
|
|
NUMERIC |
D |
X |
X |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
X | ||
REAL |
X |
X |
X |
X |
X |
D |
X |
|
|
|
|
X |
|
|
|
X | ||
SMALLINT |
X |
X |
X |
D |
X |
X |
X |
|
|
|
|
X |
|
|
|
X |
X | |
BIGINT |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X |
|
|
|
D |
X | |
TIME |
X |
X |
|
|
|
|
|
|
D |
X |
|
|
|
|
| |||
TIMESTAMP |
X |
X |
|
|
|
|
|
X |
X |
D |
|
|
|
|
| |||
VARCHAR |
D |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X | |
VARGRAPHIC (No Unicode) |
X |
X |
|
|
|
|
|
|
|
|
|
|
D |
|
| |||
VARGRAPHIC (Unicode) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
D |
|
|
|
X |
|
Antes de que se diera soporte a las aplicaciones Unicode, podía conseguirse que las aplicaciones que se habían escrito para que funcionaran con datos de tipo carácter de un solo byte funcionaran con datos gráficos de doble byte por medio de una serie de palabras clave de archivo cli ini, como por ejemplo GRAPHIC=1,2 ó 3, Patch2=7. Estas soluciones temporales presentaban los datos gráficos como datos de tipo carácter y, asimismo afectaban a la longitud comunicada de los datos.
Dichas palabras clave ya no son necesarias para las aplicaciones Unicode y no deberían utilizarse debido al riesgo de los efectos colaterales potenciales. Si no se sabe si una determinada aplicación es una aplicación Unicode, le recomendamos que pruebe sin ninguna de las palabras clave que afectan al manejo de datos gráficos.
En bases de datos no Unicode, los datos de las columnas LONG VARGRAPHIC y LONG VARCHAR no pueden compararse. Los datos de las columnas GRAPHIC/VARGRAPHIC y CHAR/VARCHAR sólo puede compararse, o asignarse los unos a los otros, utilizando funciones cast explícitas, ya que no existe soporte de conversión de páginas de códigos implícita. Esto incluye a los literales GRAPHIC/VARGRAPHIC y CHAR/VARCHAR en los que un literal GRAPHIC/VARGRAPHIC se diferencia de un literal CHAR/VARCHAR por medio de un prefijo G.
Para bases de datos Unicode, no se necesita la difusión entre literales GRAPHIC/VARGRAPHIC y CHAR/VARCHAR. Tampoco se necesita un prefijo G delante de un literal GRAPHIC/VARGRAPHIC. Se producirán conversiones implícitas, siempre que como mínimo uno de los argumentos sea un literal. Esto permite que los literales con o sin el prefijo G se utilicen dentro de las sentencias que utilizan SQLPrepareW() o SQLExecDirect(). Los literales para LONG VARGRAPHIC deben tener el prefijo G.
Para obtener más información, consulte el apartado "Difusión entre tipos de datos" del "Capítulo 3. Elementos de lenguaje" del manual Consulta de SQL.
Se han añadido las tres palabras clave siguientes para evitar exceso de carga cuando las aplicaciones Unicode se conecten a una base de datos.
Una vez habilitado el soporte de Unicode, y si una aplicación Unicode la llama, la CLI intentará conectarse a la base de datos utilizando la mejor página de códigos de cliente posible, para asegurarse de que no se produzca una pérdida de datos innecesaria debido a la conversión de página de códigos. Es posible que esto prolongue el tiempo de conexión debido al intercambio de páginas de códigos, o que ocasione en el cliente conversiones de páginas de códigos que no se producían antes de añadir el soporte.
Si esta palabra clave se establece en True (Verdadero) (1), todos los datos Unicode se convertirán a la página de códigos local de la aplicación antes de que se envíen los datos al servidor. Es posible que esto provoque una pérdida de datos que no puedan representarse en la página de códigos local.
Las aplicaciones no Unicode siempre se conectan a la base de datos utilizando la página de códigos local de la aplicación o el valor de entorno DB2Codepage. Por omisión, la CLI se asegurará de que las aplicaciones Unicode se conecten a bases de datos Unicode utilizando las páginas de códigos UTF-8 y UCS-2. El valor por omisión para conectarse a bases de datos no Unicode es utilizar la página de códigos de las bases de datos si el servidor de bases de datos ejecuta DB2 para Windows, DB2 para Unix o DB2 para OS/2. Esto asegura que no se produzca ninguna pérdida de datos innecesaria por la conversión de página de códigos.
Esta palabra clave permite al usuario especificar la página de códigos de la base de datos cuando se conecta a una base de datos que no es Unicode, a fin de evitar que se produzca una actividad general extra en la conexión.
La especificación de un valor de 1 hace que SQLDriverConnect() devuelva el valor correcto en la serie de conexión de salida, para que el valor pueda utilizarse en llamadas SQLDriverConnect() futuras.
Esta palabra clave equivale a ConnectCodepage=1208 y se añade únicamente por comodidad. Establezca esta palabra clave para evitar que se produzca actividad general extra al conectarse a DB2 para OS/390 Versión 7 o superior. No es necesario establecer esta palabra clave para bases de datos de DB2 para Windows, DB2 para Unix o DB2 para OS/2, ya que no requieren procesos adicionales.
La línea siguiente corrige el valor por omisión de la palabra clave de configuración DISABLEMULTITHREAD en el subapartado "Instalación y configuración":
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 12. 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.
Se deben otorgar los privilegios siguientes a los usuarios que desean crear, depurar y ejecutar procedimientos SQL almacenados:
Se deben otorgar los privilegios siguientes a los usuarios que desean crear, depurar y ejecutar procedimientos Java almacenados:
Para crear la tabla DB2DBG.ROUTINE_DEBUG, emita el mandato siguiente:
db2 -tf sqllib/misc/db2debug.ddl
Para obtener más información sobre cómo depurar procedimientos Java almacenados, consulte el manual Application Development Guide.
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.