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:
A continuación se muestra una lista de las funciones API ODBC que dan soporte tanto a las versiones de Unicode (W) como a las de ANSI (A) (el nombre de función tendrá una W para Unicode):
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 SQLDrivers SQLGetStmtAttr SQLStatistics SQLError SQLNativeSQL SQLTablePrivileges SQLExecDirect SQLPrepare SQLTables
Las funciones Unicode que siempre devuelven o adoptan argumentos de longitud de serie se pasan como número de caracteres. Para las funciones que devuelven información de longitud para los datos de servidor, el tamaño y la precisión de la visualización se describen en números de caracteres. Cuando una longitud (tamaño de transferencia de los datos) puede hacer referencia a una serie o a datos que no sean una serie, la longitud se describe en longitudes de octeto. Por ejemplo, SQLGetInfoW siempre adoptará la longitud como número de bytes, pero SQLExecDirectW utilizará número de caracteres. CLI devolverá 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. El gestor de controladores correlaciona SQL_C_WCHAR con SQL_C_CHAR para controladores ANSI pero no efectúa correlación alguna para controladores Unicode.
Hay dos tipos de datos definidos CLI o ODBC nuevos, SQL_C_WCHAR y SQL_WCHAR. SQL_C_WCHAR indica que el almacenamiento intermedio C contiene datos UCS-2. SQL_WCHAR indica que una columna o marcador de parámetros en concreto contiene datos Unicode. Para los DB2 Unicode Servers, las columnas gráficas se describirán como SQL_WCHAR. Se permitirá la conversión entre SQL_C_WCHAR y SQL_CHAR, SQL_VARCHAR, SQL_LONGVARCHAR y SQL_CLOB, así como entre los tipos de datos gráficos.
Tabla 32. 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 _ 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 etc. Estas soluciones temporales presentaban 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, de hecho, no deberían utilizarse ya que podrían dar lugar a efectos colaterales graves. 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, a 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. A condición de que uno de los argumentos sea un literal, se producirán conversiones implícitas. Lo cual 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, por favor 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, si una aplicación Unicode lo llama, CLI intentará conectarse a la base de datos utilizando la mejor página de códigos posible, de modo 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 cause en el cliente conversiones de páginas de códigos que antes de añadir el soporte no se producían.
Si esta palabra clave se establece en True (Verdadero), todos los datos Unicode se convertirán a la página de códigos local de la aplicación antes de que los datos se envíen al servidor. Es posible que esto provoque una pérdida de los 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, CLI se asegurará de que las aplicaciones Unicode se conecten a bases de datos Unicode utilizando páginas de códigos UTF-8 y UCS-2. También se asegurará de que se conecten a bases de datos que no sean Unicode utilizando la página de códigos de cada base de datos. Esto garantiza que no se produzcan pérdidas de datos innecesarias debido a la conversión de páginas 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 para evitar que se produzca una actividad general extra en la conexión.
Especifique un valor de 1 para que SQLDriverConnect() devuelva el valor correcto en la serie de conexión de salida, de modo que el valor pueda utilizarse en futuras llamadas de SQLDriverConnect().
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.
A continuación se muestra una sección nueva que se ha añadido a este apéndice:
Una aplicación Unicode de ODBC envía y recupera datos de tipo carácter fundamentalmente en UCS-2. Efectúa esta acción llamando a las versiones de Unicode de las funciones ODBC (sufijo 'W') e indicando los tipos de datos de Unicode. La aplicación no especifica una página de códigos local de modo explícito. La aplicación puede seguir llamando a las funciones ANSI y pasando las series de página de códigos local.
Por ejemplo, la aplicación puede llamar a SQLConnectW() y pasar el DSN, ID de usuario y contraseña como argumentos de Unicode. A continuación, puede llamar a SQLExecDirectW(), pasar una serie de sentencia SQL de Unicode SQL y, después vincular una combinación de almacenamientos intermedios de página local ANSI (SQL_C_CHAR) y de almacenamientos intermedios Unicode (SQL_C_WCHAR). Los tipos de datos de base de datos pueden ser la página de códigos local o UCS-2 y UTF-8.
Si una aplicación CLI llama a SQLConnectW o llama a SQLSetConnectAttr con SQL_ATTR_ANSI_APP establecido en SQL_AA_FALSE, se considera que la aplicación es una aplicación Unicode. Esto significa que todos los datos CHAR se envían y reciben desde la base de datos en formato UTF-8. A continuación, la aplicación puede captar datos CHAR en almacenamientos intermedios SQL_C_CHAR de la página de códigos local (con una posible pérdida de datos), o en almacenamientos intermedios SQL_C_WCHAR en UCS-2 sin pérdida de datos.
Si la aplicación no efectúa ninguna de las dos llamadas anteriores, los datos CHAR se convierten a la página de códigos local de las aplicaciones del servidor. Lo cual significa que los datos CHAR que se captan en SQL_C_WCHAR pueden experimentar una pérdida de datos.
Si la variable de instancia de DB2CODEPAGE se establece (utilizando db2set) en la página de códigos 1208 (UTF-8), la aplicación recibirá todos los datos CHAR en UTF-8 ya que ésta es ahora la página de códigos local. La aplicación debe asegurarse también de que todos los datos de entrada CHAR estén asimismo en UTF-8. ODBC asume asimismo que todos los datos SQL_C_WCHAR están en formato endian nativo. CLI efectuará la alternancia de bytes que se necesite para SQL_C_WCHAR.
Este release de DB2 Universal Database contiene la API de SQLConnectW(). Un controlador Unicode debe exportar SQLConnectW para que el gestor de controladores lo reconozca como controlador Unicode. Es importante tener en cuenta que numerosas aplicaciones de ODBC (por ejemplo Microsoft Access y Visual Basic) llaman a SQLConnectW(). En los releases anteriores de DB2 Universal Database, DB2 CLI no daba soporte a esta API y, por tanto el gestor de controladores de ODBC no lo reconocía como controlador Unicode. Esto hacía que el gestor de controladores de ODBC convirtiera todos los datos de Unicode a la página de códigos local de la aplicación. Con el soporte añadido de la función SQLConnectW(), estas aplicaciones se convertirán ahora en aplicaciones Unicode y DB2 CLI asumirá todas las conversiones de datos necesarias.
DB2 CLI acepta en este momento las API de Unicode (con un sufijo de "W") y las API de ANSI habituales. ODBC define un conjunto de funciones con un sufijo de "A", pero el gestor de controladores no pasa funciones de ANSI con el sufijo "A" al controlador. En vez de eso, convierte dichas funciones en llamadas de función de ANSI sin el sufijo y después las pasa al controlador.
Una aplicación de ODBC que llama a la API de SQLConnectW() se considera que es una aplicación Unicode. Puesto que el gestor de controladores de ODBC siempre llamará a la API de SQLConnectW() sin tener en cuenta la versión de la aplicación llamada, ODBC introducirá el atributo de conexión SQL_ATTR_ANSI_APP para notificar al controlador si la aplicación debería considerarse una aplicación ANSI o UNICODE. Si SQL_ATTR_ANSI_APP no se establece en SQL_AA_FALSE, DB2 CLI convierte todos los datos de Unicode a la página de códigos local antes de enviarlos al servidor.