Guia de Desarrollo de Aplicaciones

IBM
DB2 Universal Database
Gua de desarrollo de aplicaciones:

Programacin de aplicaciones de cliente
Versin 8
SC10-3723-00
IBM
Gua de desarrollo de aplicaciones:

Programacin de aplicaciones de cliente
Versin 8
SC10-3723-00
Antes de utilizar esta informacin y el producto al que da soporte, asegrese de leer la informacin general incluida
en el apartado Avisos.
Este manual es la traduccin del original ingls IBM DB2 Universal Database Application Development Guide:
Programming Client Applications Version 8 (SC09-4826-00).
Este documento contiene informacin sobre productos patentados de IBM. Se proporciona segn un acuerdo de
licencia y est protegido por la ley de la propiedad intelectual. La presente publicacin no incluye garantas del
producto y las declaraciones que contiene no deben interpretarse como tales.
Puede realizar pedidos de publicaciones en lnea o a travs del representante de IBM de su localidad.
v Para realizar pedidos de publicaciones en lnea, vaya a IBM Publications Center en
www.ibm.com/shop/publications/order
v Para encontrar el representante de IBM correspondiente a su localidad, vaya a IBM Directory of Worldwide
Contacts en www.ibm.com/planetwide
Para realizar pedidos de publicaciones en mrketing y ventas de DB2 de los EE.UU. o de Canad, llame al nmero
1-800-IBM-4YOU (426-4968).
Cuando enva informacin a IBM, otorga a IBM un derecho no exclusivo para utilizar o distribuir dicha informacin
en la forma en que IBM considere adecuada, sin contraer por ello ninguna obligacin con el remitente.
Copyright International Business Machines Corporation 1993-2002. Reservados todos los derechos.
Contenido
Acerca de este manual . . . . . . . . xv
Parte 1. Introduccin . . . . . . . 1
Captulo 1. Visin general de las interfaces
de programacin soportadas . . . . . . 3
DB2 Developers Edition . . . . . . . . 3
Productos de DB2 Developers Edition . . 3
Instrucciones para instalar productos DB2
Developers Edition . . . . . . . . . 5
Herramientas de DB2 Universal Database para
desarrollar aplicaciones . . . . . . . . 5
Interfaces de programacin soportadas . . . 6
Interfaces de programacin que reciben
soporte de DB2 . . . . . . . . . . 6
Interfaces de programacin de aplicaciones
de DB2 . . . . . . . . . . . . . 8
SQL incorporado . . . . . . . . . . 9
Interfaz de nivel de llamada de DB2 . . . 11
CLI de DB2 frente a SQL dinmico
incorporado . . . . . . . . . . . 13
Java Database Connectivity (JDBC) . . . 15
SQL incorporado para Java (SQLj) . . . 17
Objetos de datos ActiveX y Objetos de
datos remotos . . . . . . . . . . 17
DBI Perl . . . . . . . . . . . . 18
Herramientas de usuario final de ODBC 18
Aplicaciones Web . . . . . . . . . . 19
Herramientas para crear aplicaciones Web 19
WebSphere Studio . . . . . . . . . 19
XML Extender . . . . . . . . . . 20
Habilitacin de MQSeries . . . . . . 21
Net.Data . . . . . . . . . . . . 21
Funciones de programacin . . . . . . . 22
Funciones de programacin de DB2 . . . 22
Procedimientos almacenados de DB2. . . 23
Mtodos y funciones definidas por el
usuario de DB2 . . . . . . . . . . 24
Centro de desarrollo . . . . . . . . 25
Tipos definidos por el usuario (UDT) y
objetos grandes (LOB). . . . . . . . 26
Rutinas de automatizacin de OLE . . . 28
Funciones de tabla de OLE DB. . . . . 29
Activadores de DB2 . . . . . . . . 29
Captulo 2. Codificacin de una aplicacin
DB2 . . . . . . . . . . . . . . 31
Requisitos previos para programacin . . . 32
Visin general de la codificacin de
aplicaciones DB2 . . . . . . . . . . 33
Programacin de una aplicacin autnoma 33
Creacin de una seccin de declaracin de
una aplicacin autnoma. . . . . . . 34
Declaracin de variables que interactan
con el gestor de bases de datos. . . . . 34
Declaracin de variables que representan
objetos de SQL . . . . . . . . . . 35
Declaracin de variables del lenguaje
principal con el Generador de
declaraciones db2dclgn . . . . . . . 38
Relacin de variables del lenguaje
principal con una sentencia de SQL . . . 39
Declaracin de la SQLCA para el manejo
de errores . . . . . . . . . . . . 40
Manejo de errores utilizando la sentencia
WHENEVER. . . . . . . . . . . 41
Adicin de sentencias no ejecutables a una
aplicacin . . . . . . . . . . . . 43
Conexin de una aplicacin con una base
de datos . . . . . . . . . . . . 43
Codificacin de transacciones . . . . . 44
Finalizacin de una transaccin con la
sentencia COMMIT . . . . . . . . 45
sentencia ROLLBACK. . . . . . . . 46
Finalizacin de un programa de aplicacin 48
Finalizacin implcita de una transaccin
en una aplicacin autnoma . . . . . 48
Infraestructura de seudocdigo de
aplicacin . . . . . . . . . . . . 49
Recursos para crear prototipos de
sentencias de SQL . . . . . . . . . 50
API administrativas en SQL incorporado o
en programas de CLI de DB2 . . . . . 52
Definicin de FIPS 127-2 e ISO/ANS
SQL92 . . . . . . . . . . . . . 52
Control de valores de datos y relaciones . . 52
Control de valores de datos . . . . . . 52
Control de valores de datos mediante tipos
de datos . . . . . . . . . . . . 53
Copyright IBM Corp. 1993-2002 iii
Control de valores de datos mediante
restricciones exclusivas . . . . . . . 53
restricciones de comprobacin de tabla . . 54
restricciones de integridad referencial . . 54
vistas con la opcin Check . . . . . . 55
lgica de aplicacin y tipos de variables de
programa . . . . . . . . . . . . 55
Control de relaciones de datos . . . . . 56
Control de relaciones de datos mediante
activadores . . . . . . . . . . . 57
activadores anteriores . . . . . . . . 57
activadores posteriores . . . . . . . 58
lgica de aplicacin . . . . . . . . 58
Lgica de aplicacin en el servidor . . . 59
Consideraciones sobre autorizacin para SQL
y API . . . . . . . . . . . . . . 60
Consideraciones sobre autorizacin para
SQL incorporado . . . . . . . . . 60
SQL dinmico . . . . . . . . . . 61
SQL esttico . . . . . . . . . . . 63
API . . . . . . . . . . . . . . 63
Prueba de la aplicacin . . . . . . . . 64
Configuracin del entorno de prueba para
una aplicacin . . . . . . . . . . 64
Depuracin y optimizacin de una
aplicacin . . . . . . . . . . . . 68
Macro automtica de proyectos de IBM DB2
Universal Database para Microsoft Visual
C++. . . . . . . . . . . . . . . 69
La macro automtica de proyectos de IBM
DB2 Universal Database para Microsoft
Visual C++ . . . . . . . . . . . 69
Terminologa de la macro automtica de
proyectos de IBM DB2 Universal Database
para Microsoft Visual C++ . . . . . . 72
Activacin de la macro automtica de
herramientas de IBM DB2 Universal
Database para Microsoft Visual C++ . . . 74
Parte 2. SQL incorporado . . . . 75
Captulo 3. Visin general sobre SQL
incorporado. . . . . . . . . . . . 77
Incorporacin de sentencias de SQL en un
lenguaje principal . . . . . . . . . . 77
Creacin y preparacin del archivo fuente . . 79
Paquetes, vinculacin y SQL incorporado . . 82
Creacin de paquetes para SQL
incorporado . . . . . . . . . . . 82
Precompilacin de archivos fuente que
contienen SQL incorporado . . . . . . 84
Requisitos del archivo fuente para
aplicaciones de SQL incorporado . . . . 86
Compilacin y enlace de archivos fuente
que contienen SQL incorporado . . . . 88
Creacin de paquetes mediante el mandato
BIND . . . . . . . . . . . . . 89
Creacin de versiones de paquetes . . . 90
Efecto de registros especiales en SQL
dinmico vinculado . . . . . . . . 91
Resolucin de nombres de tabla no
calificados. . . . . . . . . . . . 92
Consideraciones adicionales cuando se
vincula. . . . . . . . . . . . . 93
Ventajas de la vinculacin diferida . . . 94
Contenido del archivo de vinculacin . . 95
Relaciones entre aplicacin, archivo de
vinculacin y paquete. . . . . . . . 95
Indicaciones horarias generadas por el
precompilador . . . . . . . . . . 96
Revinculacin de paquetes . . . . . . 98
Captulo 4. Cmo escribir programas de
SQL esttico . . . . . . . . . . . 101
Caractersticas de SQL esttico y razones
para utilizarlo . . . . . . . . . . . 101
Ventajas del SQL esttico . . . . . . . 102
Programa de SQL esttico de ejemplo . . . 103
Recuperacin de datos en programas de SQL
esttico . . . . . . . . . . . . . 105
Variables del lenguaje principal en
programas de SQL esttico. . . . . . . 106
Variables del lenguaje principal en SQL
esttico . . . . . . . . . . . . 106
iv Programacin de aplicaciones cliente
principal en programas de SQL esttico . 108
Cmo hacer referencia a variables del
lenguaje principal en programas de SQL
esttico . . . . . . . . . . . . 110
Variables de indicador en programas de SQL
esttico . . . . . . . . . . . . . 110
Inclusin de variables de indicador en
programas de SQL esttico. . . . . . 110
Tipos de datos para variables de
indicador en programas de SQL esttico . 113
Ejemplo de variable de indicador en un
programa de SQL esttico . . . . . . 116
Seleccin de varias filas mediante un cursor 118
Seleccin de varias filas utilizando un
cursor. . . . . . . . . . . . . 118
Declaracin y utilizacin de cursores en
Consideraciones sobre tipos de cursor y
unidad de trabajo . . . . . . . . . 120
Ejemplo de un cursor en un programa de
SQL esttico . . . . . . . . . . 122
Manipulacin de datos recuperados. . . . 124
Actualizacin y supresin de datos
recuperados en programas de SQL
esttico . . . . . . . . . . . . 124
Tipos de cursor . . . . . . . . . 125
Ejemplo de captacin en un programa de
SQL esttico . . . . . . . . . . 126
Desplazamiento por datos recuperados y
manipulacin de los mismos . . . . . . 127
Desplazamiento por datos recuperados
previamente . . . . . . . . . . 127
Cmo conservar una copia de los datos 128
Recuperacin de datos por segunda vez 129
Diferencias en el orden de filas entre la
primera y la segunda tabla de resultados . 130
Colocacin de un cursor al final de una
tabla . . . . . . . . . . . . . 131
Actualizacin de datos recuperados
previamente . . . . . . . . . . 131
Ejemplo de insercin, actualizacin y
supresin en un programa de SQL
esttico . . . . . . . . . . . . 132
Informacin de diagnstico . . . . . . 134
Cdigos de retorno . . . . . . . . 134
Informacin de error en los campos
SQLCODE, SQLSTATE y SQLWARN . . 134
Truncamiento de smbolos en la
estructura SQLCA . . . . . . . . 135
Consideraciones sobre el manejador de
excepciones, seales e interrupciones . . 136
Consideraciones sobre rutinas de lista de
salida . . . . . . . . . . . . . 137
Recuperacin de mensajes de error en
una aplicacin . . . . . . . . . . 137
Captulo 5. Cmo escribir programas de
SQL dinmico . . . . . . . . . . 139
Caractersticas y razones para utilizar SQL
dinmico. . . . . . . . . . . . . 139
Razones para utilizar SQL dinmico . . 139
Sentencias de soporte de SQL dinmico 140
SQL dinmico frente a SQL esttico . . . 141
Cursores en programas de SQL dinmico 144
programas de SQL dinmico . . . . . 144
SQL dinmico . . . . . . . . . . 145
Efectos de DYNAMICRULES en SQL
dinmico. . . . . . . . . . . . . 147
El SQLDA en programas de SQL dinmico 150
Variables del lenguaje principal en el
SQLDA en programas de SQL dinmico . 150
Declaracin de la estructura SQLDA en
un programa de SQL dinmico . . . . 151
Preparacin de una sentencia de SQL
dinmico utilizando la estructura SQLDA
mnima . . . . . . . . . . . . 153
Asignacin de un SQLDA con suficientes
entradas SQLVAR para un programa de
SQL dinmico . . . . . . . . . . 155
Descripcin de una sentencia SELECT en
Adquisicin de almacenamiento para
albergar una fila . . . . . . . . . 157
Proceso del cursor en un programa de
SQL dinmico . . . . . . . . . . 158
Asignacin de una estructura SQLDA
para un programa de SQL dinmico . . 158
Transferencia de datos en un programa de
SQL dinmico mediante una estructura
SQLDA . . . . . . . . . . . . 162
Proceso de sentencias interactivas de SQL
en programas de SQL dinmico . . . . 163
Determinacin del tipo se sentencia en
Proceso de sentencias SELECT de lista de
variables en programas de SQL dinmico . 164
Contenido v
Cmo guardar peticiones de SQL
procedentes de usuarios finales . . . . . 165
Marcadores de parmetros en programas de
SQL dinmico . . . . . . . . . . . 166
Cmo proporcionar entrada de variables
a SQL dinmico mediante marcadores de
parmetros . . . . . . . . . . . 166
Ejemplo de marcadores de parmetros en
Comparacin entre Interfaz de nivel de
llamada (CLI) de DB2 y SQL dinmico. . . 169
Interfaz de nivel de llamada de DB2 (CLI)
frente a SQL dinmico incorporado . . . 169
Ventajas de CLI de DB2 sobre SQL
incorporado. . . . . . . . . . . 171
Cundo utilizar CLI de DB2 o SQL
incorporado. . . . . . . . . . . 173
Captulo 6. Programacin en C y C++ . . 175
Consideraciones sobre programacin en
C/C++ . . . . . . . . . . . . . 176
Secuencias tri-grafo para C y C++ . . . . 176
Archivos de entrada y de salida para C y
C++ . . . . . . . . . . . . . . 176
Archivos include . . . . . . . . . . 177
Archivos include para C y C++ . . . . 177
Archivos include en C y C++ . . . . . 180
Sentencias de SQL incorporado en C y C++ 182
Variables del lenguaje principal en C y C++ 183
Variables del lenguaje principal en C y
C++ . . . . . . . . . . . . . 183
Nombres de variables del lenguaje
principal en C y C++ . . . . . . . 185
Declaraciones de variables del lenguaje
principal en C y C++ . . . . . . . 186
Sintaxis de las variables numricas del
lenguaje principal en C y C++ . . . . 187
Sintaxis de las variables del lenguaje
principal de tipo carcter fijas y
terminadas en nulo en C y C++ . . . . 189
principal de tipo carcter de longitud
variable en C o C++ . . . . . . . . 190
Variables de indicador en C y C++ . . . 191
Variables grficas del lenguaje principal
en C y C++ . . . . . . . . . . . 191
Sintaxis de la declaracin grfica de
formatos grficos de un solo grfico y
terminados en nulo en C y C++ . . . . 192
Sintaxis para la declaracin grfica del
formato estructurado VARGRAPHIC en C
o C++. . . . . . . . . . . . . 194
principal de objeto grande (LOB) en C o
C++ . . . . . . . . . . . . . 195
principal de localizador de objeto grande
(LOB) en C o C++ . . . . . . . . 198
Sintaxis de declaraciones de variables del
lenguaje principal de referencia de
archivos en C o C++ . . . . . . . . 199
Inicializacin de variables del lenguaje
principal en C y C++ . . . . . . . 200
Expansin de macros en C. . . . . . 200
Soporte de estructuras del lenguaje
principal en C y C++ . . . . . . . 201
Tablas de indicadores en C y C++ . . . 203
Series terminadas en nulo en C y C++ 205
Variables del lenguaje principal utilizadas
como tipos de datos de puntero en C y
C++ . . . . . . . . . . . . . 207
Miembros de datos de clase utilizados
como variables del lenguaje principal en
C y C++ . . . . . . . . . . . . 208
Operadores de calificacin y de miembro
en C y C++ . . . . . . . . . . . 209
Codificacin de caracteres de varios bytes
en C y C++ . . . . . . . . . . . 210
Tipos de datos wchar_t y sqldbchar en C
y C++. . . . . . . . . . . . . 211
Opcin del precompilador WCHARTYPE
en C y C++ . . . . . . . . . . . 211
Consideraciones sobre EUC en japons o
chino tradicional y UCS-2 en C y C++ . . 215
Seccin declare de SQL con variables del
lenguaje principal para C y C++ . . . . 216
Consideraciones sobre tipos de datos para C
y C++. . . . . . . . . . . . . . 218
Tipos de datos SQL soportados en C y
C++ . . . . . . . . . . . . . 218
FOR BIT DATA en C y C++ . . . . . 222
Tipos de datos de C y C++ para
procedimientos, funciones y mtodos . . 223
Variables SQLSTATE y SQLCODE en C y
C++ . . . . . . . . . . . . . . 224
Captulo 7. Acceso a bases de datos de
varias hebras en aplicaciones C y C++. . 227
vi Programacin de aplicaciones cliente
Objetivo del acceso a base de datos de varias
hebras . . . . . . . . . . . . . 227
Recomendaciones para utilizar varias hebras 229
Consideraciones sobre pgina de cdigos y
cdigo de pas/regin para aplicaciones
UNIX de varias hebras . . . . . . . . 229
Resolucin de problemas de aplicaciones de
varias hebras . . . . . . . . . . . 230
Problemas potenciales con varias hebras 230
Cmo evitar puntos muertos para varios
contextos. . . . . . . . . . . . 231
Captulo 8. Programacin en COBOL . . 233
Consideraciones sobre la programacin en
COBOL . . . . . . . . . . . . . 233
Restricciones de lenguaje en COBOL . . . 234
Acceso a bases de datos de varias hebras en
COBOL . . . . . . . . . . . . . 234
Archivos de entrada y salida para COBOL 234
Archivos include para COBOL . . . . . 234
Sentencias de SQL incorporado en COBOL 237
Variables del lenguaje principal en COBOL 240
COBOL . . . . . . . . . . . . 240
principal en COBOL . . . . . . . . 241
lenguaje principal en COBOL . . . . . 242
principal de tipo carcter de longitud fija
en COBOL . . . . . . . . . . . 243
Sintaxis de las variables grficas del
lenguaje principal de longitud fija en
COBOL . . . . . . . . . . . . 245
Variables de indicador en COBOL . . . 246
principal LOB en COBOL . . . . . . 246
principal de localizador de LOB en
COBOL . . . . . . . . . . . . 248
principal de referencia de archivos en
COBOL . . . . . . . . . . . . 248
Soporte de estructura del lenguaje
Tablas de indicadores en COBOL . . . 251
REDEFINES en elementos de datos de
grupos COBOL . . . . . . . . . 252
lenguaje principal para COBOL . . . . 253
Consideraciones sobre tipos de datos para
COBOL . . . . . . . . . . . . . 254
Tipos de datos de SQL soportados en
COBOL . . . . . . . . . . . . 254
Tipos de datos BINARY/COMP-4 de
COBOL . . . . . . . . . . . . 257
FOR BIT DATA en COBOL . . . . . 257
Variables SQLSTATE y SQLCODE en
COBOL . . . . . . . . . . . . . 257
chino tradicional y UCS-2 para COBOL . . 258
COBOL orientado a objetos . . . . . . 259
Captulo 9. Programacin en FORTRAN 261
FORTRAN . . . . . . . . . . . . 261
Restricciones del lenguaje en FORTRAN . . 262
Llamada por referencia en FORTRAN . . 262
Lneas de depuracin y de comentario en
FORTRAN . . . . . . . . . . . 262
Consideraciones sobre la precompilacin
en FORTRAN . . . . . . . . . . 262
Acceso a bases de datos de varias hebras
en FORTRAN . . . . . . . . . . 262
Archivos de entrada y salida para
FORTRAN . . . . . . . . . . . . 262
Archivos include para FORTRAN . . . 263
Archivos include en aplicaciones
FORTRAN . . . . . . . . . . . 266
Sentencias de SQL incorporado en
FORTRAN . . . . . . . . . . . . 267
FORTRAN . . . . . . . . . . . . 268
FORTRAN . . . . . . . . . . . 269
principal en FORTRAN . . . . . . . 269
lenguaje principal en FORTRAN . . . . 271
Sintaxis de las variables de tipo carcter
del lenguaje principal en FORTRAN . . 271
Variables de indicador en FORTRAN . . 273
principal de objeto grande (LOB) en
FORTRAN . . . . . . . . . . . 273
Contenido vii
(LOB) en FORTRAN . . . . . . . . 274
FORTRAN . . . . . . . . . . . 275
lenguaje principal para FORTRAN . . . 276
Tipos de datos SQL soportados en
FORTRAN . . . . . . . . . . . . 276
Consideraciones sobre juegos de caracteres
de varios bytes en FORTRAN. . . . . . 278
chino tradicional y UCS-2 para FORTRAN . 278
FORTRAN . . . . . . . . . . . . 279
Parte 3. Java . . . . . . . . . 281
Captulo 10. Programacin en Java . . . 283
Java . . . . . . . . . . . . . . 284
JDBC y SQLj . . . . . . . . . . . 284
Comparacin entre SQLj y JDBC. . . . 284
Interoperatividad entre JDBC y SQLj . . 284
Sesiones compartidas entre JDBC y SQLj 285
Ventajas de Java sobre otros lenguajes . . . 285
Seguridad de SQL en Java . . . . . . . 286
Gestin de recursos de conexin en Java . . 286
Archivos fuente y de salida para Java . . . 287
Bibliotecas de clases Java . . . . . . . 288
Dnde colocar clases Java . . . . . . . 288
Actualizacin de clases Java para tiempo de
ejecucin. . . . . . . . . . . . . 289
Paquetes de Java . . . . . . . . . . 290
Variables del lenguaje principal en Java . . 290
Tipos de datos SQL soportados en Java . . 291
Componentes de habilitacin de Java . . . 292
Soporte de aplicaciones y applets . . . . 292
Soporte de aplicaciones en Java con el
controlador de tipo 2. . . . . . . . 292
Soporte de aplicaciones y applets en Java
con el controlador de tipo 4 . . . . . 293
Soporte de applets en Java mediante el
Programacin en JDBC . . . . . . . . 294
Codificacin de aplicaciones y applets
JDBC . . . . . . . . . . . . . 294
Especificacin JDBC . . . . . . . . 295
Ejemplo de un programa JDBC . . . . 296
Distribucin de aplicaciones JDBC
mediante el controlador de tipo 2 . . . 297
Distribucin y ejecucin de applets JDBC
del controlador de tipo 4 . . . . . . 297
Excepciones ocasionadas por una falta de
correspondencia de archivos db2java.zip
cuando se utiliza el controlador JDBC de
tipo 3 . . . . . . . . . . . . . 298
JDBC 2.1 . . . . . . . . . . . . 299
Restricciones de la API central de JDBC
2.1 por parte del controlador JDBC de
DB2 de tipo 2 . . . . . . . . . . 299
Restricciones de la API central JDBC 2.1
impuestas por el controlador JDBC de
DB2 de tipo 4 . . . . . . . . . . 300
Soporte de la API de paquete opcional de
JDBC 2.1 por parte del controlador de
JDBC de DB2 de tipo 2 . . . . . . . 300
Soporte de la API Paquete opcional de
JDBC 2.1 por parte del controlador JDBC
de DB2 de tipo 4 . . . . . . . . . 302
Programacin en SQLj . . . . . . . . 302
Programacin en SQLj . . . . . . . 302
Soporte de DB2 para SQLj . . . . . . 303
Restricciones de DB2 en SQLj . . . . . 304
Sentencias de SQL incorporado en Java 306
Declaraciones y comportamiento del
iterador en SQLj . . . . . . . . . 307
Ejemplo de iteradores en un programa
SQLj . . . . . . . . . . . . . 308
Llamadas a rutinas en SQLj . . . . . 309
Ejemplo de compilacin y ejecucin de un
programa SQLj. . . . . . . . . . 310
Opciones del conversor SQLj . . . . . 312
Resolucin de problemas de aplicaciones
Java . . . . . . . . . . . . . . 313
Recursos de rastreo en Java . . . . . 313
Recurso de rastreo de CLI/ODBC/JDBC 313
Archivos de rastreo de CLI y JDBC . . . 324
Valores de SQLSTATE y SQLCODE en
Java . . . . . . . . . . . . . 335
Captulo 11. Aplicaciones Java que
utilizan WebSphere Application Servers . 337
Servicios Web . . . . . . . . . . . 337
Arquitectura de servicios Web . . . . . 339
Acceso a datos . . . . . . . . . . . 341
Acceso a datos de DB2 a travs de
servicios Web . . . . . . . . . . 341
viii Programacin de aplicaciones cliente
Acceso a datos de DB2 mediante
consultas basadas en XML . . . . . . 342
consultas basadas en SQL . . . . . . 342
Archivo de extensin de definicin de
acceso a documentos. . . . . . . . 343
Java 2 Platform Enterprise Edition . . . . 343
Visin general de Java 2 Platform
Enterprise Edition (J2EE) . . . . . . 343
Java 2 Platform Enterprise Edition . . . 344
Contenedores de Java 2 Platform
Enterprise Edition. . . . . . . . . 345
Servidor Java 2 Platform Enterprise
Edition . . . . . . . . . . . . 346
Requisitos de bases de datos de Java 2
Java Naming and Directory Interface
(JNDI) . . . . . . . . . . . . 346
Gestin de transacciones Java . . . . . 347
Enterprise Java Beans . . . . . . . 348
WebSphere . . . . . . . . . . . . 351
Conexin con datos de la empresa . . . 351
Fuentes de datos y agrupacin de
conexiones WebSphere . . . . . . . 351
Parmetros para ajustar las agrupaciones
de conexiones de WebSphere . . . . . 352
Ventajas de la agrupacin de conexiones
de WebSphere . . . . . . . . . . 357
Colocacin de sentencias en antememoria
en WebSphere . . . . . . . . . . 358
Parte 4. Otras interfaces de
programacin . . . . . . . . . 361
Captulo 12. Programacin en Perl . . . 363
Perl . . . . . . . . . . . . . . 363
Restricciones de Perl . . . . . . . . . 363
Perl . . . . . . . . . . . . . . 364
Conexiones de bases de datos en Perl . . . 364
Captacin de resultados en Perl . . . . . 364
Marcadores de parmetros en Perl . . . . 365
Variables SQLSTATE y SQLCODE en Perl 366
Ejemplo de programa Perl . . . . . . . 366
Captulo 13. Programacin en REXX. . . 369
REXX . . . . . . . . . . . . . . 369
Restricciones del lenguaje en REXX . . . . 370
Restricciones del lenguaje en REXX . . . 370
Registro de SQLEXEC, SQLDBS y
SQLDB2 en REXX. . . . . . . . . 370
en REXX. . . . . . . . . . . . 372
chino tradicional para REXX . . . . . 372
SQL incorporado en aplicaciones REXX . . 372
Variables del lenguaje principal en REXX 374
principal en REXX . . . . . . . . 375
Referencias a variables del lenguaje
Variables de indicador en REXX . . . . 375
Variables de REXX predefinidas . . . . 376
Variables del lenguaje principal de LOB
en REXX. . . . . . . . . . . . 378
Sintaxis de las declaraciones de
localizador de LOB en REXX . . . . . 378
Sintaxis de las declaraciones de referencia
de archivos LOB en REXX . . . . . . 379
Borrado de variables del lenguaje
principal de LOB en REXX. . . . . . 380
Cursores en REXX . . . . . . . . 381
Tipos de datos SQL soportados en REXX . . 381
Requisitos de ejecucin para REXX . . . . 383
Creacin y ejecucin de aplicaciones
REXX . . . . . . . . . . . . . 383
Archivos de vinculacin de REXX . . . 384
Sintaxis de las API para REXX . . . . . 385
Llamada a procedimientos almacenados
desde REXX . . . . . . . . . . . 387
Procedimientos almacenados en REXX 387
Llamadas a procedimientos almacenados
en REXX. . . . . . . . . . . . 387
Consideraciones del cliente para llamar a
procedimientos almacenados en REXX . . 389
Consideraciones del servidor para llamar
a procedimientos almacenados en REXX . 389
Recuperacin de valores de precisin y
escala (SCALE) de campos decimales del
SQLDA . . . . . . . . . . . . 390
Captulo 14. Cmo escribir aplicaciones
mediante IBM OLE DB Provider para
servidores DB2 . . . . . . . . . . 391
Objetivo de IBM OLE DB Provider para DB2 391
Contenido ix
Tipos de aplicaciones soportados por IBM
OLE DB Provider para DB2 . . . . . . 393
Servicios OLE DB. . . . . . . . . . 393
Modelo de hebras soportado por IBM
OLE DB Provider . . . . . . . . . 393
Manipulacin de objetos grandes con IBM
OLE DB Provider . . . . . . . . . 393
Conjuntos de filas de esquema soportados
por IBM OLE DB Provider . . . . . . 393
Habilitacin automtica de servicios OLE
DB por parte de IBM OLE DB Provider . 396
Servicios de datos. . . . . . . . . . 396
Modalidades de cursor soportadas en
IBM OLE DB Provider . . . . . . . 396
Correlaciones de tipos de datos entre DB2
y OLE DB . . . . . . . . . . . 396
Conversin de datos para establecer datos
de tipos OLE DB en tipos DB2 . . . . 398
de tipos DB2 en tipos OLE DB . . . . 400
Restricciones de IBM OLE DB Provider . . 402
Soporte de IBM OLE DB Provider de
interfaces y componentes de OLE DB . . . 403
Soporte de IBM OLE DB de propiedades de
OLE DB . . . . . . . . . . . . . 406
Conexiones a fuentes de datos mediante IBM
OLE DB Provider . . . . . . . . . . 409
Aplicaciones ADO . . . . . . . . . 410
Palabras clave de series de conexin de
ADO . . . . . . . . . . . . . 410
Conexiones con fuentes de datos con
aplicaciones ADO Visual Basic . . . . 410
Cursores desplazables actualizables en
aplicaciones ADO . . . . . . . . . 411
Limitaciones de las aplicaciones ADO . . 411
propiedades y mtodos ADO . . . . . 411
Aplicaciones C y C++ . . . . . . . . 416
Compilacin y enlace de aplicaciones
C/C++ e IBM OLE DB Provider . . . . 416
Conexiones con fuentes de datos en
aplicaciones C/C++ mediante IBM OLE
DB Provider . . . . . . . . . . 416
aplicaciones ATL e IBM OLE DB Provider 417
Transacciones distribuidas MTS y COM+ 417
Soporte de transacciones distribuidas
MTS y COM+ e IBM OLE DB Provider . 417
Habilitacin del soporte de MTS en DB2
Universal Database para aplicaciones
C/C++ . . . . . . . . . . . . 418
Parte 5. Conceptos generales
sobre aplicaciones DB2. . . . . 419
Captulo 15. Soporte de idiomas
nacionales. . . . . . . . . . . . 421
Visin general del orden de clasificacin . . 421
rdenes de clasificacin . . . . . . 422
Comparaciones de caracteres basadas en
rdenes de clasificacin . . . . . . . 424
Comparaciones que no dependen de
maysculas y minsculas mediante la
funcin TRANSLATE . . . . . . . 424
Diferencias entre los rdenes de
clasificacin de EBCDIC y ASCII . . . . 426
Orden de clasificacin especificado
cuando se crea la base de datos . . . . 427
rdenes de clasificacin de ejemplo. . . 429
Pginas de cdigos y entornos locales . . . 430
Derivacin de valores de pgina de
cdigos . . . . . . . . . . . . 430
Derivacin de entornos locales en
programas de aplicacin . . . . . . 430
Cmo DB2 deriva entornos locales . . . 431
Consideraciones sobre aplicaciones . . . . 431
Consideraciones sobre el soporte de
idiomas nacionales y sobre el desarrollo
de aplicaciones. . . . . . . . . . 432
Soporte de idiomas nacionales y
sentencias de SQL . . . . . . . . 433
Procedimientos almacenados y UDF
remotos . . . . . . . . . . . . 435
Consideraciones sobre nombres de
paquetes en entornos de pginas de
cdigos combinadas . . . . . . . . 435
Pgina de cdigos activa para
precompilacin y vinculacin . . . . . 436
Pgina de cdigos activa para la ejecucin
de aplicaciones. . . . . . . . . . 436
Conversin de caracteres entre distintas
pginas de cdigos . . . . . . . . 436
Cundo se produce la conversin de
pgina de cdigos . . . . . . . . 437
Sustitucin de caracteres durante
conversiones de pginas de cdigos. . . 438
x Programacin de aplicaciones cliente
Conversiones de pginas de cdigos
soportadas . . . . . . . . . . . 438
Factor de expansin de conversin de
pgina de cdigos . . . . . . . . 440
Juegos de caracteres DBCS . . . . . . . 441
Juegos de caracteres de Extended UNIX
Code (EUC). . . . . . . . . . . . 442
Programas CLI, ODBC, JDBC y SQLj en un
entorno DBCS . . . . . . . . . . . 443
Consideraciones sobre los juegos de cdigos
EUC y UCS-2 de japons y chino tradicional . 444
Consideraciones sobre los juegos de
cdigos EUC y UCS-2 de japons y chino
tradicional . . . . . . . . . . . 444
Consideraciones sobre las bases de datos
y los clientes de doble byte con EUC
mixtos . . . . . . . . . . . . 446
Consideraciones sobre la conversin de
caracteres para usuarios de chino
tradicional . . . . . . . . . . . 447
Datos grficos en aplicaciones EUC en
japons o chino tradicional. . . . . . 447
Desarrollo de aplicaciones en situaciones
de pginas de cdigos distintas . . . . 449
Validacin de parmetros basada en
cliente en un entorno de juegos de
cdigos mixtos. . . . . . . . . . 453
Sentencia DESCRIBE en entornos de
juegos de cdigos mixtos . . . . . . 454
Datos de longitud fija y de longitud
variable en entornos de juegos de cdigos
mixtos . . . . . . . . . . . . 456
Desbordamiento de longitud de serie de
conversin de pgina de cdigos en
entornos de juegos de cdigos mixtos . . 457
Aplicaciones conectadas a bases de datos
Unicode . . . . . . . . . . . . 459
Captulo 16. Gestin de transacciones 461
Unidad de trabajo remota . . . . . . . 461
Consideraciones sobre la actualizacin
mltiple . . . . . . . . . . . . . 461
Actualizacin mltiple . . . . . . . 461
Cundo utilizar la actualizacin mltiple 462
Sentencias de SQL en aplicaciones de
actualizacin mltiple . . . . . . . 463
Precompilacin de aplicaciones de
Consideraciones sobre parmetros de
configuracin correspondientes a
aplicaciones de actualizacin mltiple . . 467
Acceso a servidores de sistema principal,
AS/400 o iSeries . . . . . . . . . . 469
Transacciones simultneas . . . . . . . 469
Transacciones simultneas . . . . . . 469
Problemas potenciales con transacciones
simultneas . . . . . . . . . . . 470
Cmo evitar puntos muertos para
transacciones simultneas . . . . . . 471
Consideraciones sobre la programacin de
interfaces XA de X/Open . . . . . . . 472
Enlace de aplicaciones y la interfaz XA de
X/Open . . . . . . . . . . . . . 476
Captulo 17. Consideraciones sobre
programacin para entornos de bases de
datos particionadas . . . . . . . . 477
Cursores FOR READ ONLY en un entorno
de bases de datos particionadas . . . . . 477
DDS dirigida y elusin local . . . . . . 477
DDS dirigida y elusin local en entornos
de bases de datos particionadas . . . . 477
DDS dirigida en entornos de bases de
Elusin local en entornos de bases de
Inserciones colocadas en almacenamiento
intermedio . . . . . . . . . . . . 479
Inserciones en almacenamiento
intermedio en entornos de bases de datos
particionadas . . . . . . . . . . 480
Consideraciones sobre la utilizacin de
inserciones en almacenamiento
intermedio . . . . . . . . . . . 483
Restricciones en la utilizacin de
intermedio . . . . . . . . . . . 486
Ejemplo de extraccin un gran volumen de
datos en una base de datos particionada . . 487
Creacin de un entorno simulado de bases
de datos particionadas . . . . . . . . 493
Resolucin de problemas . . . . . . . 493
Consideraciones sobre el manejo de
errores en entornos de bases de datos
particionadas . . . . . . . . . . 493
Errores graves en entornos de bases de
Varias estructuras SQLCA fusionadas . . 495
Contenido xi
Particin que devuelve el error . . . . 496
Aplicaciones en bucle o suspendidas . . 496
Captulo 18. Tcnicas comunes de
aplicacin de DB2 . . . . . . . . . 499
Columnas generadas . . . . . . . . . 499
Columnas de identidad . . . . . . . . 500
Valores secuenciales y objetos de secuencia 501
Generacin de valores secuenciales . . . 502
Gestin del comportamiento de
secuencias . . . . . . . . . . . 504
Rendimiento de la aplicacin y objetos de
secuencia . . . . . . . . . . . 505
Comparacin entre objetos de secuencia y
columnas de identidad . . . . . . . 506
Tablas temporales declaradas y rendimiento
de la aplicacin . . . . . . . . . . 506
Puntos de rescate y transacciones . . . . 509
Gestin de transacciones con puntos de
rescate . . . . . . . . . . . . 509
Comparacin entre puntos de rescate de
la aplicacin y bloques de SQL compuesto 511
Sentencias de SQL para crear y controlar
puntos de rescate . . . . . . . . . 513
Restricciones sobre el uso de puntos de
rescate . . . . . . . . . . . . 514
Puntos de rescate y Lenguaje de
definicin de datos (DDL) . . . . . . 514
Puntos de rescate e inserciones en
almacenamiento intermedio . . . . . 515
Puntos de rescate y bloqueo de cursor 516
Puntos de rescate y gestores de
transacciones que cumplen con XA . . . 517
Transmisin de grandes volmenes de datos
a travs de una red . . . . . . . . . 517
Parte 6. Apndices . . . . . . . 519
Apndice A. Sentencias de SQL
soportadas . . . . . . . . . . . 521
Apndice B. Programacin en un entorno
de sistema principal o iSeries . . . . . 527
Aplicaciones en entornos de sistema
principal o iSeries. . . . . . . . . . 527
Lenguaje de definicin de datos en entornos
de sistema principal e iSeries . . . . . . 529
Lenguaje de manipulacin de datos en
entornos de sistema principal e iSeries . . . 529
Lenguaje de control de datos en entornos de
sistema principal e iSeries . . . . . . . 530
Gestin de conexiones de bases de datos con
DB2 Connect . . . . . . . . . . . 531
Proceso de peticiones de interrupcin . . . 532
Atributos de paquete, PREP y BIND . . . 532
Diferencias de atributos de paquete entre
sistemas de bases de datos relacionales de
IBM . . . . . . . . . . . . . 532
Opcin CNULREQD BIND para series C
terminadas en nulo . . . . . . . . 533
Variables SQLCODE y SQLSTATE
autnomas . . . . . . . . . . . 533
Niveles de aislamiento soportados por
DB2 Connect . . . . . . . . . . 534
rdenes de clasificacin definidos por el
usuario . . . . . . . . . . . . . 535
Diferencias en la integridad referencial entre
IBM . . . . . . . . . . . . . . 535
Bloqueo y portabilidad de aplicaciones. . . 536
Diferencias en SQLCODE y SQLSTATE entre
IBM . . . . . . . . . . . . . . 536
Diferencias en el catlogo del sistema entre
IBM . . . . . . . . . . . . . . 537
Desbordamientos por conversin numrica
en asignaciones de recuperacin . . . . . 537
Procedimientos almacenados en entornos de
sistema principal o iSeries . . . . . . . 537
Soporte de DB2 Connect de SQL compuesto 539
Actualizacin mltiple con DB2 Connect . . 539
Sentencias de SQL de servidor de sistema
principal e iSeries soportadas por DB2
Connect . . . . . . . . . . . . . 541
principal e iSeries rechazadas por DB2
Connect . . . . . . . . . . . . . 541
Apndice C. Simulacin de clasificacin
binaria EBCDIC . . . . . . . . . . 543
ndice . . . . . . . . . . . . . 549
Informacin tcnica sobre DB2 Universal
Database . . . . . . . . . . . . 573
Visin general de la informacin tcnica de
DB2 Universal Database . . . . . . . 573
FixPaks para la documentacin de DB2 573
xii Programacin de aplicaciones cliente
Categoras de la informacin tcnica de
DB2 . . . . . . . . . . . . . 573
Impresin de manuales de DB2 desde
archivos PDF . . . . . . . . . . . 581
Solicitud de manuales de DB2 impresos . . 582
Acceso a la ayuda en lnea . . . . . . . 583
Bsqueda de temas mediante el acceso al
Centro de informacin de DB2 desde un
navegador . . . . . . . . . . . . 585
Bsqueda de informacin de productos
mediante el acceso al Centro de informacin
de DB2 desde las herramientas de
administracin . . . . . . . . . . . 587
Cmo ver documentacin tcnica en lnea
directamente desde el CD de documentacin
HTML de DB2 . . . . . . . . . . . 589
Actualizacin de la documentacin HTML
instalada en la mquina. . . . . . . . 590
Copia de archivos desde el CD de
documentacin HTML de DB2 en un
servidor Web . . . . . . . . . . . 591
Resolucin de problemas de bsqueda de
documentacin de DB2 con Netscape 4.x . . 592
Bsqueda en la documentacin de DB2 . . 593
Informacin en lnea de resolucin de
problemas de DB2 . . . . . . . . . 594
Accesibilidad . . . . . . . . . . . 595
Entrada de teclado y navegacin. . . . 595
Pantalla accesible . . . . . . . . . 596
Seales de alerta alternativas . . . . . 596
Compatibilidad con tecnologas de
asistencia . . . . . . . . . . . 596
Documentacin accesible . . . . . . 596
Guas de aprendizaje de DB2 . . . . . . 596
Acceso al Centro de informacin de DB2
desde un navegador . . . . . . . . . 597
Avisos . . . . . . . . . . . . . 599
Marcas registradas . . . . . . . . . 602
Cmo ponerse en contacto con IBM . . 605
Informacin sobre productos . . . . . . 605
Contenido xiii
xiv Programacin de aplicaciones cliente
Acerca de este manual
El manual Gua de desarrollo de aplicaciones es un libro de tres volmenes que
describe lo que tiene que saber sobre codificacin, depuracin, creacin y
ejecucin de aplicaciones DB2:
v El manual Gua de desarrollo de aplicaciones: Programacin de aplicaciones de
cliente contiene lo que tiene que saber para codificar aplicaciones DB2
autnomas que se ejecutan en clientes DB2. Incluye informacin sobre:
Interfaces de programacin que reciben soporte de DB2. Se proporcionan
descripciones de alto nivel para DB2 Developers Edition, interfaces de
programacin soportadas, recursos para crear aplicaciones Web y
funciones de programacin proporcionadas por DB2, como rutinas y
activadores.
La estructura general que debe seguir una aplicacin DB2. Se
proporcionan recomendaciones sobre cmo mantener valores de datos y
relaciones en la base de datos, se describen consideraciones sobre
autorizacin y se proporciona informacin sobre cmo probar y depurar
la aplicacin.
SQL incorporado, tanto dinmico como esttico. Se describen
consideraciones generales sobre SQL incorporado, as como temas
especficos que se aplican al uso de SQL esttico y dinmico en
aplicaciones DB2.
Lenguajes interpretados y de sistema principal, como C/C++, COBOL,
Perl y REXX, y cmo utilizar SQL incorporado en aplicaciones escritas en
estos lenguajes.
Java (tanto JDBC como SQLj) y consideraciones sobre la creacin de
aplicaciones Java que utilizan WebSphere Application Servers.
IBM OLE DB Provider para servidores DB2. Se proporciona informacin
general sobre el soporte de IBM OLE DB Provider para servicios OLE
DB, componentes y propiedades. Tambin se proporciona informacin
especfica sobre aplicaciones Visual Basic y Visual C++ que utilizan la
interfaz OLE DB para Objetos de datos ActiveX (ADO).
Temas relacionados con el soporte de idiomas nacionales. Se describen
temas generales, como secuencias de clasificacin, obtencin de pginas
de cdigos y entornos locales y conversiones de caracteres. Tambin se
describen temas ms especficos, como pginas de cdigos DBCS, juegos
de caracteres EUC y temas que se aplican a entornos EUC y UCS-2 de
japons y chino tradicional.
Copyright IBM Corp. 1993-2002 xv
Gestin de transacciones. Se describen temas relacionados con
aplicaciones que realizan actualizaciones mltiples y con aplicaciones
que realizan transacciones simultneas.
Aplicaciones en entornos de bases de datos particionadas. Se describen
DSS dirigida, elusin local, inserciones colocadas en almacenamiento
intermedio y resolucin de aplicaciones en entornos de bases de datos
particionadas.
Tcnicas de aplicaciones utilizadas normalmente. Se proporciona
informacin sobre cmo utilizar columnas generadas y de identidad y
tablas temporales declaradas y sobre cmo utilizar puntos de rescate
para gestionar transacciones.
Las sentencias de SQL que se pueden utilizar en aplicaciones de SQL
incorporado.
Aplicaciones que acceden a entornos de sistema principal e iSeries. Se
describen temas relacionados con aplicaciones de SQL incorporado que
acceden a entornos de sistema principal e iSeries.
La simulacin del orden binario EBCDIC.
v El manual Gua de desarrollo de aplicaciones: Programacin de aplicaciones de
servidor contiene lo que tiene que saber sobre programacin en el servidor,
que incluye rutinas, objetos grandes, tipos definidos por el usuario y
activadores. Incluye informacin sobre:
Rutinas (procedimientos almacenados, funciones definidas por el usuario
y mtodos), que incluyen:
- Rendimiento de rutinas, seguridad, consideraciones sobre la gestin de
bibliotecas y restricciones.
- Cmo registrar y escribir rutinas, incluidas las sentencias CREATE y
depuracin.
- Modalidades de parmetros de procedimientos y manejo de
parmetros.
- Conjuntos de resultados de procedimientos.
- Funciones de UDF que incluyen borradores y funciones escalares y de
tabla.
- Procedimientos de SQL que incluyen depuracin y manejo de
condiciones.
- Estilos de parmetros, autorizaciones y vinculacin de rutinas
externas.
- Consideraciones especficas de cada lenguaje para C, Java y rutinas de
automatizacin OLE.
- Invocacin de rutinas
- Seleccin de funciones y cmo pasar tipos diferenciados y LOB a
funciones.
xvi Programacin de aplicaciones cliente
- Pginas de cdigos y rutinas.
Objetos grandes, que incluyen uso de LOB y localizadores, variables de
referencia y datos CLOB.
Tipos diferenciados definidos por el usuario, que incluyen tipificacin
estricta, definicin y eliminacin de UDT, creacin de tablas con tipos
estructurados, utilizacin de tipos diferenciados y tablas tipificadas para
aplicaciones especficas, manipulacin de tipos diferenciados y difusin
entre los mismos y realizacin de comparaciones y asignaciones con
tipos diferenciados, que incluyen operaciones UNION sobre columnas
tipificadas de forma diferenciada.
Tipos estructurados definidos por el usuario, que incluyen
almacenamiento de instancias y creacin de instancias, jerarquas de
tipos estructurados, definicin del comportamiento de los tipos
estructurados, distribucin dinmica de mtodos, funciones de
comparacin, difusin y constructor y mtodos mutador y observador
correspondientes a tipos estructurados.
Tablas tipificadas, que incluyen creacin, eliminacin, sustitucin y
almacenamiento de objetos, definicin de identificadores de objetos
generados por el sistema y restricciones en las columnas de identificador.
Tipos de referencia, que incluyen relaciones entre objetos de tablas
tipificadas, relaciones semnticas con referencias e integridad referencial
frente a referencias de mbito.
Tablas y vistas tipificadas, que incluyen tipos estructurados como tipos
de columnas, funciones de transformacin y grupos de transformacin,
correlaciones de programas de lenguaje principal y variables del lenguaje
principal de tipos estructurados.
Activadores, que incluyen los activadores INSERT, UPDATE y DELETE,
interacciones con restricciones referenciales, lneas generales de creacin,
granularidad, hora de activacin, tablas y variables de transicin,
acciones desencadenadas, varios activadores y sinergia entre activadores,
restricciones y rutinas.
v El manual Gua de desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
contiene lo que tiene que saber para crear y ejecutar aplicaciones DB2 en los
sistemas operativos a los que da soporte DB2:
AIX
HP-UX
Linux
Solaris
Windows
Incluye informacin sobre:
Acerca de este manual xvii
Cmo configurar el entorno de desarrollo de aplicaciones; incluye
instrucciones especficas para procedimientos Java y SQL, cmo
configurar la base de datos de ejemplo y cmo migrar las aplicaciones
desde versiones anteriores de DB2.
Servidores y software soportados por DB2 para crear aplicaciones,
incluidos compiladores e intrpretes.
Los archivos de los programas de ejemplo de DB2, makefiles, archivos de
creacin y archivos del programa de utilidad de comprobacin de
errores.
Cmo crear y ejecutar applets, aplicaciones y rutinas Java.
Cmo crear y ejecutar procedimientos de SQL.
Cmo crear y ejecutar rutinas y aplicaciones C/C++.
Cmo crear y ejecutar rutinas y aplicaciones COBOL de IBM y Micro
Focus.
Cmo crear y ejecutar aplicaciones REXX en AIX y Windows.
Cmo crear y ejecutar con Objetos de datos ActiveX (ADO) mediante
Visual Basic y Visual C++ en Windows.
Cmo crear y ejecutar aplicaciones con objetos de datos remotos
mediante Visual C++ en Windows.
xviii Programacin de aplicaciones cliente
Parte 1. Introduccin
Copyright IBM Corp. 1993-2002 1
2 Programacin de aplicaciones cliente
Captulo 1. Visin general de las interfaces de
programacin soportadas
DB2 Developers Edition . . . . . . . . 3
Productos de DB2 Developers Edition . . 3
Instrucciones para instalar productos DB2
Developers Edition . . . . . . . . . 5
Herramientas de DB2 Universal Database para
desarrollar aplicaciones . . . . . . . . 5
Interfaces de programacin soportadas . . . 6
Interfaces de programacin que reciben
soporte de DB2 . . . . . . . . . . 6
Interfaces de programacin de aplicaciones
de DB2 . . . . . . . . . . . . . 8
SQL incorporado . . . . . . . . . . 9
Interfaz de nivel de llamada de DB2 . . . 11
CLI de DB2 frente a SQL dinmico
incorporado . . . . . . . . . . . 13
Java Database Connectivity (JDBC) . . . 15
SQL incorporado para Java (SQLj) . . . 17
Objetos de datos ActiveX y Objetos de
datos remotos . . . . . . . . . . 17
DBI Perl . . . . . . . . . . . . 18
Herramientas de usuario final de ODBC 18
Aplicaciones Web . . . . . . . . . . 19
Herramientas para crear aplicaciones Web 19
WebSphere Studio . . . . . . . . . 19
XML Extender . . . . . . . . . . 20
Habilitacin de MQSeries . . . . . . 21
Net.Data . . . . . . . . . . . . 21
Funciones de programacin . . . . . . . 22
Funciones de programacin de DB2 . . . 22
Procedimientos almacenados de DB2. . . 23
Mtodos y funciones definidas por el
usuario de DB2 . . . . . . . . . . 24
Centro de desarrollo . . . . . . . . 25
Tipos definidos por el usuario (UDT) y
objetos grandes (LOB). . . . . . . . 26
Rutinas de automatizacin de OLE . . . 28
Funciones de tabla de OLE DB. . . . . 29
Activadores de DB2 . . . . . . . . 29
DB2 Developers Edition
Las siguientes secciones describen DB2 Developers Edition y dnde encontrar
informacin sobre cmo instalar productos en el mismo.
Productos de DB2 Developers Edition
DB2 Universal Database proporciona dos paquetes de productos para el
desarrollo de aplicaciones: DB2 Personal Developers Edition y DB2 Universal
Developers Edition. Personal Developers Edition proporciona los productos
DB2 Universal Database y DB2 Connect Personal Edition que se ejecutan en
Linux y en sistemas operativos Windows. DB2 Universal Developers Edition
proporciona productos DB2 en estas plataformas, as como en AIX, en HP-UX
y en entorno operativo Solaris. Pngase en contacto con el representante de
IBM para ver una lista completa de plataformas soportadas.
Con el software que viene con estos productos puede desarrollar y probar
aplicaciones que se ejecutan en un sistema operativo y que acceden a bases de
datos en el mismo o en otro sistema operativo. Por ejemplo, puede crear una
aplicacin que se ejecute en el sistema operativo Windows NT pero que
acceda a una base de datos en una plataforma UNIX como AIX. Consulte el
Acuerdo de licencia para ver los trminos y condiciones de uso de los
productos Developers Edition.
Personal Developers Edition contiene varios CD-ROM con todo el cdigo
que necesita para desarrollar y probar sus aplicaciones. En cada caja,
encontrar:
v Los CD-ROM del producto DB2 Universal Database para Linux y sistemas
operativos Windows. Cada CD-ROM contiene el servidor DB2,
Administration Client, Application Development Client y Run-Time Client
para un sistema operativo soportado. Estos CD-ROM se proporcionan slo
para que pruebe sus aplicaciones. Si tiene que instalar y utilizar una base
de datos, debe obtener una licencia vlida adquiriendo el producto
Universal Database.
v DB2 Connect Personal Edition
v Un CD-ROM de publicaciones de DB2 que contiene manuales de DB2 en
formato PDF
v DB2 Extenders (slo Windows)
v DB2 XML Extender (slo Windows)
v VisualAge para Java, Entry Edition
Universal Developers Edition contiene CD-ROM para todos los sistemas
operativos que reciben soporte de DB2, e incluyen lo siguiente:
v DB2 Universal Database Personal Edition, Workgroup Server Edition y
Enterprise Server Edition
v DB2 Connect Personal Edition y DB2 Connect Enterprise Edition
v Clientes de administracin para todas las plataformas. Estos clientes
contienen herramientas para administrar bases de datos, como el Centro de
control y el Analizador de sucesos. Estos clientes tambin le permiten
ejecutar aplicaciones en cualquier sistema.
v Clientes de desarrollo de aplicaciones para todas las plataformas. Estos
clientes tienen herramientas de desarrollo de aplicaciones, programas de
ejemplo y archivos de cabecera. Cada cliente DB2 AD incluye todo lo que
necesita para desarrollar sus aplicaciones.
v Clientes de tiempo de ejecucin para todas las plataformas. Una aplicacin
se puede ejecutar desde un cliente de tiempo de ejecucin en cualquier
sistema. El cliente de tiempo de ejecucin no tiene algunas de las funciones
del cliente de administracin, como el Centro de control de DB2 y el
Analizador de sucesos, de modo que ocupa menos espacio.
v DB2 Extenders
v DB2 XML Extender
v VisualAge para Java, Professional Edition (Windows)
v Websphere Studio
v Websphere Application Server, Standard Edition
v Recurso de gestin de consultas (probar y comprar)
Adems, para ambas Developers Editions, obtiene copias de otro software
que puede encontrar til para desarrollar aplicaciones. Este software puede
variar de tanto en tanto y viene acompaado de acuerdos de licencia para
uso.
Instrucciones para instalar productos DB2 Developers Edition
Para obtener instrucciones sobre cmo instalar un producto disponible con
DB2 Developers Edition, consulte el manual Gua rpida de iniciacin
adecuado, disponible en el CD de PDF, o consulte el propio CD del producto
para ver instrucciones de instalacin.
Herramientas de DB2 Universal Database para desarrollar aplicaciones
Puede utilizar distintas herramientas para desarrollar aplicaciones. DB2
Universal Database suministra las siguientes herramientas para ayudarle a
escribir y probar las sentencias de SQL en las aplicaciones y para ayudarle a
supervisar su rendimiento.
Nota: no todas las herramientas estn disponibles en todas las plataformas.
Centro de control
Una interfaz grfica que muestra objetos de bases de datos (como bases de
datos, tablas y paquetes) y sus mutuas relaciones. Utilice el Centro de control
para realizar tareas administrativas como configurar el sistema, gestionar
directorios, hacer copia de seguridad y recuperar el sistema, planificar trabajos
y gestionar soportes.
DB2 tambin proporciona los siguientes recursos:
Centro de mandatos
Se utiliza para entrar mandatos de DB2 y sentencias de SQL en una
ventana interactiva y para ver el resultado de la ejecucin en una
ventana de resultados. Puede desplazarse por los resultados y guardar
la salida en un archivo.
Centro de scripts
Se utiliza para crear scripts, que puede almacenar e invocar
posteriormente. Estos scripts pueden contener mandatos de DB2,
sentencias de SQL o mandatos del sistema operativo. Puede planificar
scripts para que se ejecuten de forma desatendida. Puede ejecutar
estos trabajos una vez o puede definirlos de modo que se ejecuten
segn una planificacin repetitiva. Una planificacin repetitiva resulta
especialmente til para tareas como copias de seguridad.
Diario Se utiliza para ver los siguientes tipos de informacin: toda la
informacin disponible sobre trabajos cuya ejecucin est pendiente,
Captulo 1. Visin general de las interfaces de programacin soportadas 5
que se estn ejecutando o que se han terminado de ejecutar, el registro
histrico de recuperacin, el registro de alertas y el registro de
mensajes. Tambin puede utilizar el Diario para revisar los resultados
de trabajos que se ejecutan de forma desatendida.
Centro de alertas
Se utiliza para supervisar el sistema en busca de avisos anteriores o
de problemas potenciales o para automatizar acciones para corregir
problemas.
Valor de herramientas
Se utiliza para cambiar los valores correspondientes al Centro de
control, Centro de alertas y Duplicacin.
Supervisor de sucesos
Recopila informacin sobre el rendimiento de actividades de bases de
datos durante un periodo de tiempo. Su informacin recopilada
proporciona un buen resumen de la actividad correspondiente a un
determinado suceso de base de datos: por ejemplo, una conexin de
base de datos o una sentencia de SQL.
Visual Explain
Visual Explain, una opcin instalable correspondiente al Centro de control, es
una interfaz grfica que le permite analizar y ajustar sentencias de SQL,
incluida la consulta de planes de acceso elegidos por el optimizador para
sentencias de SQL.
Interfaces de programacin soportadas
Las secciones siguientes contienen una visin general de las interfaces de
programacin soportadas.
Interfaces de programacin que reciben soporte de DB2
Puede utilizar varias interfaces de programacin diferentes para gestionar
bases de datos DB2 o para acceder a las mismas. Puede:
v Utilizar las API de DB2 para realizar funciones administrativas como copia
de seguridad y restauracin de bases de datos.
v Incorporar sentencias de SQL esttico y dinmico en sus aplicaciones.
v Codificar llamadas a funciones de Interfaz de nivel de llamada de DB2 (CLI
de DB2) en sus aplicaciones para invocar sentencias de SQL dinmico.
v Desarrollar aplicaciones y applets Java que llaman a la interfaz de
programacin de aplicaciones Java Database Connectivity (API JDBC).
v Desarrollar aplicaciones Microsoft Visual Basic y Visual C++ que cumplen
con las especificaciones de Objeto de acceso a datos (DAO) y Objeto de
datos remotos (RDO) y aplicaciones Objeto de datos ActiveX (ADO) que
utilizan el puente Object Linking and Embedding Database (OLE DB).
v Desarrollar aplicaciones mediante herramientas de IBM o de otros
proveedores como Net.Data, Excel, Perl y herramientas de usuario final de
Open Database Connectivity (ODBC) como Lotus Approach y su lenguaje
de programacin, LotusScript.
El modo en que la aplicacin acceda a bases de datos DB2 depender del tipo
de aplicacin que desee desarrollar. Por ejemplo, si desea una aplicacin de
entrada de datos, es posible que elija incorporar sentencias de SQL esttico en
la aplicacin. Si desea una aplicacin que realice consultas en la World Wide
Web, es posible que elija Net.Data, Perl o Java.
Aparte del modo en que la aplicacin accede a los datos, tambin debe tener
en cuenta lo siguiente:
v Control de valores de datos utilizando:
Tipos de datos (integrados o definidos por el usuario)
Restricciones de comprobacin de tablas
Restricciones de integridad referencial
Vistas utilizando la opcin CHECK
Lgica de aplicacin y tipos de variable
v Control de las relaciones entre valores de datos utilizando:
Restricciones de integridad referencial
Activadores
Lgica de aplicacin
v Ejecucin de programas en el servidor utilizando:
Procedimientos almacenados
Funciones definidas por el usuario
Activadores
Observar que esta lista menciona algunas funciones ms de una vez, como
los activadores. Esto refleja la flexibilidad de estas funciones para ajustarse a
ms de un criterio de diseo.
La principal y ms fundamental decisin es si debe o no mover la lgica para
aplicar las normas relacionadas con la aplicacin sobre los datos a la base de
datos.
La principal ventaja de transferir lgica centrada en los datos de la aplicacin
a la base de datos es que la aplicacin pasa a ser ms independiente de los
datos. La lgica asociada a los datos se centraliza en un lugar, la base de
datos. Esto significa que puede cambiar datos o lgica de datos una vez de
forma que ello afecte a todas las aplicaciones inmediatamente.
Esta ltima ventaja es muy potente, pero tambin debe tener en cuenta que
cualquier lgica de datos que se coloque en la base de datos afecta a todos los
usuarios de los datos por igual. Debe tener en cuenta si las normas y
restricciones que desea imponer en los datos se aplican a todos los usuarios
de los datos o nicamente a los usuarios de la aplicacin.
Los requisitos de la aplicacin tambin pueden afectar a si se deben aplicar
las normas en la base de datos o en la aplicacin. Por ejemplo, es posible que
tenga que procesar errores de validacin sobre entrada de datos en un orden
especfico. En general, debera realizar estos tipos de validacin de datos en el
cdigo de la aplicacin.
Tambin debera tener en cuenta el entorno de clculo en que se utiliza la
aplicacin. Debe tener en cuenta la diferencia entre llevar a cabo lgica en las
mquinas cliente frente a ejecutar la lgica en las mquinas servidor de base
de datos, generalmente ms potentes, utilizando procedimientos almacenados,
UDF o una combinacin de ambos.
En algunos casos, la respuesta correcta consiste en incluir el cumplimiento
tanto en la aplicacin (quizs debido a los requisitos especficos de la
aplicacin) y en la base de datos (quizs debido a otros usuarios interactivos
fuera de la aplicacin).
Conceptos relacionados:
v Interfaz de nivel de llamada de DB2 (CLI) frente a SQL dinmico
incorporado en la pgina 169
v SQL incorporado en la pgina 9
v Interfaz de nivel de llamada de DB2 en la pgina 11
v Interfaces de programacin de aplicaciones de DB2 en la pgina 8
v Objetos de datos ActiveX y Objetos de datos remotos en la pgina 17
v DBI Perl en la pgina 18
v Herramientas de usuario final de ODBC en la pgina 18
v Herramientas para crear aplicaciones Web en la pgina 19
v Java Database Connectivity (JDBC) en la pgina 15
Interfaces de programacin de aplicaciones de DB2
Puede que sus aplicaciones tengan que realizar algunas tareas de
administracin de bases de datos, como crear, activar, hacer copia de
seguridad o restaurar una base de datos. DB2 proporciona numerosas API
para que pueda realizar estar tareas desde sus aplicaciones, incluidas
aplicaciones de SQL incorporado y CLI de DB2. Esto le permite programar en
sus aplicaciones las mismas funciones administrativas que puede realizar
mediante las herramientas de administracin del servidor de DB2 disponibles
en el Centro de control.
Adems, es posible que tenga que llevar a cabo tareas especficas que slo se
pueden realizar mediante las API de DB2. Por ejemplo, puede que desee
recuperar el texto de un mensaje de error para que la aplicacin lo pueda
mostrar al usuario final. Para recuperar el mensaje, debe utilizar la API
Obtener mensaje de error.
v Consideraciones sobre autorizacin para API en la pgina 63
v API administrativas en SQL incorporado o en programas de CLI de DB2
en la pgina 52
SQL incorporado
Structured Query Language (SQL) es el lenguaje de interfaz de bases de datos
que se utiliza para acceder a bases de datos DB2 y para manipular datos de
las mismas. Puede incorporar sentencias de SQL en sus aplicaciones, lo que
les permitir realizar cualquier tarea soportada por SQL, como recuperar o
almacenar datos. Mediante DB2, puede codificar sus aplicaciones de SQL
incorporado en los lenguajes de programacin C/C++, COBOL, FORTRAN,
Java (SQLj) y REXX.
Nota: los lenguajes de programacin REXX y Fortran no se han mejorado
desde la Versin 5 de DB2 Universal Database.
Una aplicacin en la que incorpora sentencias de SQL se denomina programa
de sistema principal. El lenguaje de programacin que utilice para crear un
programa de sistema principal se denomina lenguaje principal. El programa y
el lenguaje se definen de este modo porque pueden alojar o acomodar
sentencias de SQL.
Para sentencias de SQL esttico, sabe antes del momento de la compilacin el
tipo de sentencia de SQL y los nombres de tablas y columnas. Lo nico que
no sabe son los valores de datos especficos que la sentencia va a buscar o a
actualizar. Puede representar estos valores en variables del lenguaje principal.
Debe precompilar, vincular y luego compilar las sentencias de SQL esttico
antes de ejecutar la aplicacin. SQL esttico se ejecuta mejor en bases de datos
cuyas estadsticas no cambian mucho. De lo contrario, las sentencias quedarn
rpidamente obsoletas.
Por el contrario, las sentencias de SQL dinmico son aquellas que la aplicacin
crea y ejecuta en el tiempo de ejecucin. Una aplicacin interactiva que
solicita al usuario final partes clave de una sentencia de SQL, como los
nombres de las tablas y las columnas que hay que buscar, es un buen ejemplo
de SQL dinmico. La aplicacin crea la sentencia de SQL mientras se est
ejecutando y luego somete la sentencia para que se procese.
Puede escribir aplicaciones que tengan sentencias de SQL esttico, sentencias
de SQL dinmico o una combinacin de ambas.
Generalmente, las sentencias de SQL esttico resultan ideales para aplicaciones
de alto rendimiento con transacciones predefinidas. Un sistema de reservas
constituye un buen ejemplo de este tipo de aplicacin.
Generalmente, las sentencias de SQL dinmico resultan ideales para
aplicaciones que se ejecutan contra una base de datos que cambia con rapidez
y en la que las transacciones se tienen que especificar en el tiempo de
ejecucin. Una interfaz de consulta interactiva es un buen ejemplo de este tipo
de aplicacin.
Cuando incorpore sentencias de SQL en su aplicacin, debe precompilar y
vincular la aplicacin a una base de datos siguiendo los pasos siguientes:
1. Cree archivos fuente que contengan programas con sentencias de SQL
incorporado.
2. Conecte con una base de datos y luego precompile cada archivo fuente.
El precompilador convierte las sentencias de SQL de cada archivo fuente
en llamadas a API en tiempo de ejecucin de DB2 al gestor de bases de
datos. El precompilador tambin genera un paquete de acceso en la base
de datos y, opcionalmente, un archivo de vinculacin, si especifica que
desea que se cree uno.
El paquete de acceso contiene planes de acceso seleccionados por el
optimizador de DB2 para las sentencias de SQL esttico de la aplicacin.
Los planes de acceso contienen la informacin que necesita el gestor de
bases de datos para ejecutar las sentencias de SQL esttico de la forma
ms eficiente, segn determine el optimizador. Para sentencias de SQL
dinmico, el optimizador crea planes de acceso cuando el usuario ejecuta
la aplicacin.
El archivo de vinculacin contiene las sentencias de SQL y otros datos
necesarios para crear un paquete de acceso. Puede utilizar el archivo de
vinculacin para revincular la aplicacin ms adelante sin tener que
precompilarla primero. La revinculacin crea planes de acceso optimizados
para las condiciones actuales de la base de datos. Tiene que revincular la
aplicacin si va a acceder a una base de datos distinta de aquella contra la
cual se precompil. Debe revincular la aplicacin si las estadsticas de la
base de datos han cambiado desde la ltima vinculacin.
3. Compile los archivos fuente modificados (y otros archivos sin sentencias
de SQL) mediante el compilador del lenguaje principal.
4. Enlace los archivos de objetos con las bibliotecas de DB2 y del lenguaje
principal para generar un programa ejecutable.
5. Vincule el archivo de vinculacin para crear el paquete de acceso si esto
no se ha hecho en el momento de la precompilacin o si se va a acceder a
una base de datos distinta.
6. Ejecute la aplicacin. La aplicacin accede a la base de datos utilizando el
plan del paquete.
v SQL incorporado en aplicaciones REXX en la pgina 372
v Sentencias de SQL incorporado en C y C++ en la pgina 182
v Sentencias de SQL incorporado en COBOL en la pgina 237
v Sentencias de SQL incorporado en FORTRAN en la pgina 267
v Sentencias de SQL incorporado en Java en la pgina 306
v SQL incorporado para Java (SQLj) en la pgina 17
Tareas relacionadas:
v Incorporacin de sentencias de SQL en un lenguaje principal en la pgina
77
Interfaz de nivel de llamada de DB2
DB2 CLI es una interfaz de programacin que las aplicaciones C y C++
pueden utilizar para acceder a bases de datos DB2. CLI de DB2 se basa en la
especificacin Open Database Connectivity (ODBC) de Microsoft y en el
estndar CLI de ISO. Puesto que CLI de DB2 se basa en estndares de la
industria, los programadores de aplicaciones que estn familiarizados con
estas interfaces de bases de datos se pueden beneficiar de una curva de
aprendizaje ms corta.
Cuando utiliza CLI de DB2, la aplicacin pasa sentencias de SQL dinmico
como argumentos de funcin al gestor de bases de datos para que las procese.
Desde este punto de vista, CLI de DB2 constituye una alternativa a SQL
dinmico incorporado.
Tambin se pueden ejecutar sentencias de SQL como SQL esttico en una
aplicacin CLI, ODBC o JDBC. La funcin Static Profiling de
CLI/ODBC/JDBC permite a los usuarios finales de una aplicacin sustituir el
uso de SQL dinmico por SQL esttico en muchos casos. Para obtener ms
informacin, consulte:
http://www.ibm.com/software/data/db2/udb/staticcli
Puede crear una aplicacin ODBC sin utilizar un gestor de controladores
ODBC y simplemente utilizar el controlador ODBC de DB2 en cualquier
plataforma enlazando la aplicacin con libdb2 en UNIX y con db2cli.lib en
sistemas operativos Windows. Los programas de ejemplo de CLI de DB2 lo
demuestran. Se encuentran en sqllib/samples/cli en UNIX y en
sqllib\samples\cli en sistemas operativos Windows.
No necesita precompilar ni vincular las aplicaciones CLI de DB2 porque
utilizan paquetes de acceso comn que se suministran con DB2. Simplemente
tiene que compilar y enlazar la aplicacin.
Sin embargo, antes de que las aplicaciones CLI de DB2 u ODBC puedan
acceder a bases de datos DB2, los archivos de vinculacin CLI de DB2 que
vienen con DB2 AD Client se deben vincular a cada una de las bases de datos
DB2 a la que se vaya a acceder. Esto se produce automticamente con la
ejecucin de la primera sentencia, pero recomendamos que el administrador
de bases de datos vincule los archivos de vinculacin desde un cliente de cada
plataforma que vaya a acceder a una base de datos DB2.
Por ejemplo, supongamos que tiene clientes AIX, Solaris y Windows 98, cada
uno de los cuales accede a dos bases de datos DB2. El administrador debe
vincular los archivos de vinculacin desde un cliente AIX de cada base de
datos a la que se vaya a acceder. A continuacin, el administrador debe
vincular los archivos de vinculacin desde un cliente Solaris de cada base de
datos a la que se vaya a acceder. Finalmente, el administrador debe hacer lo
mismo en un cliente Windows 98.
v API administrativas en SQL incorporado o en programas de CLI de DB2
en la pgina 52
v Ventajas de CLI de DB2 sobre SQL incorporado en la pgina 171
v Cundo utilizar CLI de DB2 o SQL incorporado en la pgina 173
v CLI de DB2 frente a SQL dinmico incorporado en la pgina 13
Consulta relacionada:
v Programas de ejemplo de la CLI de DB2 en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
CLI de DB2 frente a SQL dinmico incorporado
Puede desarrollar aplicaciones dinmicas mediante sentencias de SQL
dinmico incorporado o DB2 CLI. En ambos casos, las sentencias de SQL se
preparan y se procesan en el tiempo de ejecucin. Cada mtodo tiene ventajas
exclusivas.
Las ventajas de CLI de DB2 son las siguientes:
Portabilidad Las aplicaciones CLI de DB2 utilizan un conjunto estndar de
funciones para pasar sentencias de SQL a la base de datos.
Todo lo que tiene que hacer es compilar y enlazar aplicaciones
CLI de DB2 antes de ejecutarlas. Por el contrario, debe
precompilar las aplicaciones de SQL incorporado, compilarlas
y luego vincularlas a la base de datos antes de ejecutarlas.
Este proceso enlaza de forma eficiente la aplicacin a una
determinada base de datos.
No hay vinculacin
No tiene que vincular aplicaciones CLI de DB2 individuales a
cada base de datos a la que acceden. Slo tiene que vincular
los archivos que se suministran con CLI de DB2 una vez para
todas las aplicaciones CLI de DB2. Esto permite reducir
significativamente la cantidad de tiempo empleada en
gestionar las aplicaciones.
Captacin y entrada ampliadas
Las funciones CLI de DB2 le permiten recuperar varias filas
de la base de datos en una matriz con una sola llamada.
Tambin le permiten ejecutar una sentencia de SQL varias
veces utilizando una matriz de variables de entrada.
Interfaz coherente ante el catlogo
Los sistemas de bases de datos contienen tablas de catlogo
que tienen informacin sobre la base de datos y sus usuarios.
El formato de estos catlogos puede variar entre sistemas. CLI
de DB2 proporciona una interfaz coherente para consultar
informacin del catlogo sobre componentes como tablas,
columnas, claves principales y forneas y privilegios de
usuarios. Esto protege la aplicacin ante cambios en el
catlogo entre releases de servidores de bases de datos y ante
diferencias entre servidores de bases de datos. No tiene que
escribir consultas del catlogo que sean especficas de un
determinado servidor o versin de producto.
Conversin de datos ampliada
CLI de DB2 convierte automticamente datos entre los tipos
de datos SQL y C. Por ejemplo, al captar cualquier tipo de
datos SQL en un tipo de datos char de C se convierten en una
representacin de serie de caracteres. Esto hace que CLI de
DB2 resulte ideal para aplicaciones de consulta interactiva.
No hay reas de datos globales
CLI de DB2 elimina la necesidad de disponer de reas de
datos globales controladas por la aplicacin y normalmente
complejas, como SQLDA y SQLCA, que suelen estar asociadas
con aplicaciones de SQL incorporado. En su lugar, CLI de DB2
asigna y control automticamente las estructuras de datos
necesarias y proporciona un descriptor de contexto para que
la aplicacin haga referencia a las mismas.
Recuperar conjuntos de resultados de procedimientos almacenados
Las aplicaciones CLI de DB2 pueden recuperar varias filas y
conjuntos de resultados generados a partir de un
procedimiento almacenado que resida en un servidor DB2
Universal Database, un servidor DB2 para MVS/ESA (Versin
5 o posterior) o un servidor OS/400 (Versin 5 o posterior). El
soporte para la recuperacin de varios conjuntos de resultados
en OS/400 necesita que se aplique el PTF (Program
Temporary Fix) SI01761 al servidor. Pngase en contacto con
el administrador del sistema OS/400 para asegurarse de que
se ha aplicado este PTF.
Cursores desplazables
CLI de DB2 da soporte a los cursores desplazables del
servidor que se pueden utilizar junto con una salida de
matriz. Esto resulta til en aplicaciones GUI que muestran
informacin de base de datos en recuadros desplazables en los
que utilizan las teclas Re Pg, Av Pg, Inicio y Fin. Puede
declarar un cursor como desplazable y luego avanzar o
retroceder por el conjunto de resultados una o ms filas.
Tambin puede captar filas especificando un desplazamiento a
partir de la fila actual, el principio o fin de un conjunto de
resultados o una fila especfica que haya marcado
previamente.
Las ventajas de SQL dinmico incorporado son las siguientes:
Seguridad granular
Todos los usuarios de CLI de DB2 comparten los mismos
privilegios. SQL incorporado ofrece la ventaja de una
seguridad ms granular en la que se garantizan privilegios de
ejecucin del paquete a usuarios determinados.
Ms lenguajes soportados
SQL incorporado da soporte a otros lenguajes, adems de C y
C++. Esto puede resultar una ventaja si prefiere codificar las
aplicaciones en otro lenguaje.
Ms coherente con SQL esttico
Generalmente, SQL dinmico es ms coherente con SQL
esttico. Si ya sabe cmo programar SQL esttico, pasar a SQL
dinmico no debe resultar tan difcil como pasar a CLI de
DB2.
v Ventajas de CLI de DB2 sobre SQL incorporado en la pgina 171
v Cundo utilizar CLI de DB2 o SQL incorporado en la pgina 173
Java Database Connectivity (JDBC)
El soporte de Java de DB2 incluye JDBC, una interfaz de SQL dinmico que
no depende del proveedor que proporciona acceso a datos a la aplicacin a
travs de mtodos Java estandarizados. JDBC se parece a CLI de DB2 en que
el usuario no tiene que precompilar ni vincular un programa JDBC. Como
estndar independiente del proveedor, las aplicaciones JDBC ofrecen mayor
portabilidad. Una aplicacin escrita utilizando JDBC slo utiliza SQL
dinmico.
JDBC puede resultar especialmente til para acceder a bases de datos DB2 a
travs de Internet. Mediante el lenguaje de programacin Java puede
desarrollar applets y aplicaciones JDBC que accedan a datos de bases de datos
DB2 remotas y los manipulen mediante una conexin de red. Tambin puede
crear procedimientos almacenados de JDBC que residan en el servidor,
accedan al servidor de base de datos y devuelvan informacin a una
aplicacin cliente remota que llame al procedimiento almacenado.
La API JDBC, que es parecida a la API CLI/ODBC, proporciona un modo
estndar de acceder a bases de datos desde cdigo Java. El cdigo Java pasa
sentencias de SQL como argumentos de mtodo al controlador JDBC de DB2.
El controlador maneja las llamadas a la API JDBC desde el cdigo Java cliente.
La portabilidad de Java le permite ofrecer acceso a DB2 a clientes de distintas
plataformas, con el nico requisito de disponer de un navegador web
habilitado para Java o de un entorno de ejecucin Java.
JDBC de tipo 2
Las aplicaciones Java basadas en el controlador JDBC de tipo 2 confan en el
cliente DB2 para establecer conexin con DB2. Puede iniciar la aplicacin
desde el escritorio o desde la lnea de mandatos, como cualquier otra
aplicacin. El controlador JDBC de DB2 maneja las llamadas a la API JDBC
desde la aplicacin y utiliza la conexin del cliente para comunicar las
peticiones al servidor y para recibir los resultados. No puede crear applets
Java mediante el controlador JDBC de tipo 2.
Nota: se recomienda el controlador JDBC de tipo 2 para WebSphere
Application Servers.
JDBC de tipo 3
Si utiliza el controlador JDBC de tipo 3, slo puede crear applets Java. Los
applets Java no necesitan que el cliente DB2 est instalado en la mquina
cliente. Normalmente, el applet se incorpora en una pgina web HyperText
Markup Language (HTML).
Para ejecutar un applet basado en el controlador JDBC de tipo 3, slo necesita
un navegador web habilitado para Java o un visor de applets en la mquina
cliente. Cuando carga la pgina HTML, el navegador baja el applet Java a la
mquina, el cual baja los archivos de clases Java y el controlador JDBC de
DB2. Cuando el applet llama a la API JDBC para establecer conexin con DB2,
el controlador JDBC establece una conexin de red independiente con la base
de datos DB2 a travs del servidor de applets JDBC que reside en el servidor
Web.
Nota: se desaprueba el uso del controlador JDBC de tipo 3 en la Versin 8.
JDBC de tipo 4
Puede utilizar el controlador JDBC de tipo 4, que es una novedad de la
Versin 8, para crear aplicaciones y applets Java. Para ejecutar una aplicacin
o un applet basado en el controlador de tipo 4 slo necesita el archivo
db2jcc.jar. No se necesita ningn cliente DB2.
Para obtener ms informacin sobre el soporte de JDBC de DB2, visite la
siguiente pgina Web:
http://www.ibm.com/software/data/db2/java
v Comparacin entre SQLj y JDBC en la pgina 284
v Codificacin de aplicaciones y applets JDBC en la pgina 294
SQL incorporado para Java (SQLj)
El soporte de SQL incorporado de Java (SQLj) de DB2 se suministra mediante
DB2 AD Client. Con el soporte de SQLj de DB2, adems del soporte de JDBC
de DB2, puede crear y ejecutar procedimientos almacenados, aplicaciones y
applets SQLj. Estos contienen SQL esttico y utilizan sentencias de SQL
incorporado que se vinculan a una base de datos DB2.
Para obtener ms informacin sobre el soporte de SQLj de DB2, visite la
pgina Web situada en:
http://www.ibm.com/software/data/db2/java
v Comparacin entre SQLj y JDBC en la pgina 284
Objetos de datos ActiveX y Objetos de datos remotos
Puede escribir aplicaciones de bases de datos Microsoft Visual Basic y
Microsoft Visual C++ que cumplan con las especificaciones Objeto de acceso a
datos (DAO) y Objeto de datos remotos (RDO). DB2 tambin da soporte a las
aplicaciones Objeto de datos ActiveX (ADO) que utilizan el puente entre OLE
DB y ODBC de Microsoft.
La especificacin Objetos de datos ActiveX (ADO) le permite escribir una
aplicacin que acceda a datos de un servidor de base de datos y los manipule
a travs de un proveedor de OLE DB. Las principales ventajas de ADO son su
rpido tiempo de desarrollo, su facilidad de uso y el poco espacio que ocupa
en disco.
Los Objetos de datos remotos (RDO) proporcionan un modelo de informacin
para acceder a fuentes de datos remotas a travs de ODBC. RDO ofrece un
conjunto de objetos que facilitan la conexin a una base de datos, la ejecucin
de consultas y procedimientos almacenados, la manipulacin de resultados y
la confirmacin de cambios en el servidor. Esta especificacin est
especialmente diseada para acceder a fuentes de datos relacionales ODBC
remotas y facilita la utilizacin de ODBC sin complejo cdigo de aplicacin.
Para ver ejemplos completos de aplicaciones DB2 que utilizan las
especificaciones ADO y RDO, consulte los siguientes directorios:
v Para ejemplos de Objeto de datos ActiveX de Visual Basic, consulte
sqllib\samples\VB\ADO
v Para ejemplos de Objeto de datos remotos de Visual Basic, consulte
sqllib\samples\VB\RDO
v Para ejemplos de Servidor de transacciones Microsoft Visual Basic, consulte
sqllib\samples\VB\MTS
v Para ejemplos de Objeto de datos ActiveX de Visual C++, consulte
sqllib\samples\VC\ADO
v Creacin de aplicaciones ADO con Visual Basic en el manual Gua de
desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones RDO con Visual Basic en el manual Gua de
v Creacin de aplicaciones ADO con Visual C++ en el manual Gua de
v Programas de ejemplo Visual Basic en el manual Gua de desarrollo de
v Programas de ejemplo Visual C++ en el manual Gua de desarrollo de
DBI Perl
DB2 da soporte a la especificacin Interfaz de bases de datos (DBI) Perl para
el acceso a datos a travs del controlador DBD::DB2. El sitio web de DBI Perl
de DB2 Universal Database se encuentra en:
http://www.ibm.com/software/data/db2/perl/
y contiene el ltimo controlador DBD::DB2 e informacin relacionada.
Perl es un lenguaje interpretado y el Mdulo DBI de Perl utiliza SQL
dinmico. Esto convierte Perl en un lenguaje ideal para crear y revisar con
rapidez prototipos de aplicaciones DB2. El Mdulo DBI de Perl utiliza una
interfaz que es bastante parecida a las interfaces CLI y JDBC. Esto facilita el
transporte de prototipos Perl a CLI y JDBC.
v Consideraciones sobre la programacin en Perl en la pgina 363
Herramientas de usuario final de ODBC
Puede utilizar herramientas de usuario final de ODBC como Lotus Approach,
Microsoft Access y Microsoft Visual Basic para crear aplicaciones. Las
herramientas ODBC ofrecen una alternativa ms sencilla para desarrollar
aplicaciones que utilizar un lenguaje de programacin de alto nivel.
Lotus Approach proporciona dos mtodos de acceder a datos DB2. Puede
utilizar la interfaz grfica para realizar consultas, desarrollar informes y
analizar datos, o bien puede desarrollar aplicaciones utilizando LotusScript,
un lenguaje de programacin con todas sus funciones y orientado a objetos
que viene con una amplia matriz de objetos, sucesos, mtodos y propiedades,
junto con un editor de programas incorporado.
Aplicaciones Web
Las secciones siguientes describen los productos y funciones disponibles para
crear aplicaciones Web.
Herramientas para crear aplicaciones Web
DB2 Universal Database da soporte a todos los estndares clave de Internet, lo
que la convierte en una base de datos ideal para utilizar en la Web. Tiene
velocidad en memoria para facilitar las bsquedas en Internet y la
comparacin compleja de texto combinada con las caractersticas de
escalabilidad y disponibilidad de una base de datos relacional. Puesto que
DB2 Universal Database da soporte a WebSphere, Java y XML Extender,
facilita el despliegue de aplicaciones e-business.
DB2 Universal Developers Edition tiene varias herramientas que
proporcionan soporte de habilitacin de la Web. WebSphere Studio
Application Developer, Versin 4, es un entorno de desarrollo integrado (IDE)
que le permite crear, probar y desplegar aplicaciones Java en un WebSphere
Application Server y en DB2 Universal Database. WebSphere Studio es un
grupo de herramientas que combina todos los aspectos relacionados con el
desarrollo de sitios Web en una interfaz comn. WebSphere Application
Server Advanced Edition (un solo servidor) proporciona un potente entorno
de despliegue para aplicaciones e-business. Sus componentes le permiten crear
y desplegar contenido Web dinmico y personalizado de forma rpida y
sencilla.
v WebSphere Studio en la pgina 19
v XML Extender en la pgina 20
WebSphere Studio
WebSphere Studio es un grupo de herramientas que combinan todos los
aspectos del desarrollo de sitios Web en una interfaz comn. WebSphere
Studio facilita ms que nunca la creacin, ensamblaje, publicacin y
mantenimiento en cooperacin de aplicaciones Web interactivas. Studio consta
de los componentes Workbench, Page Designer y Remote Debugger y
asistentes y viene con copias de prueba de productos de desarrollo de Web
complementarios, como Macromedia Flash, Fireworks, Freehand y Director.
WebSphere Studio le permite realizar todo lo que necesita para crear sitios
Web interactivos que den soporte a funciones empresariales avanzadas.
WebSphere Application Server Standard Edition (que se suministra con DB2
Universal Developers Edition) es un componente de WebSphere Studio.
Combina la portabilidad de las aplicaciones empresariales del servidor con el
rendimiento y capacidad de gestin de tecnologas Java para ofrecer una
amplia plataforma para disear aplicaciones Web basadas en Java. Permite
potentes interacciones con bases de datos empresariales y sistemas de
transacciones. Puede ejecutar el servidor DB2 en la misma mquina que
WebSphere Application Server o en otro servidor Web.
WebSphere Application Server Advanced Edition (que no se suministra con
DB2 Universal Developers Edition) proporciona soporte adicional para
aplicaciones Enterprise JavaBean. DB2 Universal Database se suministra con
WebSphere Application Server Advanced Edition para que se utilice como el
repositorio del servidor administrativo. Incorpora las funciones de servidor
para aplicaciones creadas segn la especificacin EJB de Sun Microsystems,
que proporciona soporte para la integracin de aplicaciones Web en sistemas
empresariales que no son Web.
v Enterprise Java Beans en la pgina 348
v Programas de ejemplo de Java WebSphere en el manual Gua de desarrollo
de aplicaciones: Creacin y ejecucin de aplicaciones
XML Extender
Extensible Markup Language (XML) es la tcnica estndar aceptada para el
intercambio de datos entre aplicaciones. Un documento XML es un
documento codificado que las personas pueden leer. El texto consta de datos
de carcter y cdigos de marcacin. Los cdigos de marcacin los define el
autor del documento. Se utiliza una Definicin de tipo de documento (DTD)
para declarar las definiciones de marcacin y las restricciones. DB2 XML
Extender (que se suministra con DB2 Universal Developers Edition y con
Personal Developers Edition en Windows) proporciona un mecanismo
mediante el cual los programas pueden manipular datos XML mediante
extensiones de SQL.
DB2 XML Extender incorpora tres nuevos tipos de datos: XMLVARCHAR, XMLCLOB
y XMLFILE. El ampliador proporciona UDF para almacenar, extraer y actualizar
documentos XML situados dentro de una sola columna o en varias columnas
y tablas. La bsqueda se puede realizar en el documento XML entero o se
puede basar en componentes estructurales utilizando la va de acceso de
ubicacin, que utiliza un subconjunto de Extensible Stylesheet Language
Transformation (XSLT) y XPath para XML Path Language.
Para facilitar el almacenamiento de documentos XML como un grupo de
columnas, DB2 XML Extender proporciona una herramienta de administracin
para ayudar al diseador con la correlacin entre XML y base de datos
relacional. La Definicin de acceso a documento (DAD) se utiliza para
mantener los datos estructurales y de correlacin correspondientes a los
documentos XML. La DAD se define y se almacena como un documento
XML, el cual facilita la manipulacin y comprensin. Dispone de nuevos
procedimientos almacenados para componer o descomponer el documento.
Para obtener ms informacin sobre DB2 XML Extender, visite:
http://www.ibm.com/software/data/db2/extenders/xmlext/index.html
v Archivo de extensin de definicin de acceso a documentos en la pgina
343
Habilitacin de MQSeries
Con DB2 Universal Database se suministra un grupo de funciones de
MQSeries que permiten a las aplicaciones DB2 interactuar con operaciones
asncronas de gestin de mensajes. Esto significa que el soporte de MQSeries
est disponible para las aplicaciones en cualquier lenguaje de programacin
que reciba soporte de DB2.
En una configuracin bsica, un servidor MQSeries est situado en la
mquina servidor de base de datos junto con DB2 Universal Database. Las
funciones de MQSeries estn disponibles desde un servidor DB2 y
proporcionan acceso a otras aplicaciones MQSeries. Varios clientes DB2
pueden acceder simultneamente a las funciones de MQSeries a travs de la
base de datos. Las operaciones de MQSeries permiten a las aplicaciones DB2
comunicarse de forma sncrona con otras aplicaciones MQSeries. Por ejemplo,
las nuevas funciones proporcionan un mtodo sencillo que permite a una
aplicacin DB2 publicar sucesos de bases de datos en aplicaciones MQSeries
remotas, iniciar un flujo de trabajo a travs del producto opcional MQSeries
Workflow o comunicarse con un paquete de aplicacin existente con el
producto opcional MQSeries Integrator.
Net.Data
Net.Data permite el acceso de Internet e intranet a datos de DB2 a travs de
aplicaciones web. Aprovecha las interfaces (API) del servidor Web,
proporcionando un rendimiento superior que las aplicaciones Common
Gateway Interface (CGI). Net.Data da soporte al proceso del cliente as como
al proceso del servidor con lenguajes como Java, REXX, Perl y C++. Net.Data
proporciona lgica adicional y un potente lenguaje de macros. Tambin
proporciona soporte de XML, lo que le permite generar cdigos XML como
salida de su macro Net.Data en lugar de tener que entrar los cdigos de
forma manual. Tambin puede especificar una hoja de estilo XML (XSL) que
se utilizar para formatear y visualizar la salida generada. Net.Data slo est
disponible si se baja de la Web. Para obtener ms informacin, consulte el
siguiente sitio Web:
http://www-4.ibm.com/software/data/net.data/support/index.html
Nota: el soporte de Net.Data se ha estabilizado en DB2 Versin 7.2 y no est
previsto realizar mejoras para el soporte de Net.Data en el futuro.
v Herramientas para crear aplicaciones Web en la pgina 19
v XML Extender en la pgina 20
Funciones de programacin
Las secciones siguientes describen las funciones de programacin disponibles
con DB2.
Funciones de programacin de DB2
DB2 viene con diversas funciones que se ejecutan en el servidor y que puede
utilizar para complementar o ampliar sus aplicaciones. Si utiliza las funciones
de DB2, no tiene que escribir su propio cdigo para llevar a cabo las mismas
tareas. DB2 tambin le permite almacenar algunas partes de su cdigo en el
servidor en lugar de conservar todo el cdigo en las aplicaciones cliente. Esto
puede aportar ventajas en cuanto a rendimiento y mantenimiento.
Hay funciones para proteger los datos y para definir relaciones entre los
datos. Asimismo, hay funciones relacionales de objetos para crear aplicaciones
flexibles y avanzadas. Puede utilizar algunas funciones de ms de una forma.
Por ejemplo, las restricciones le permite proteger datos y definir relaciones
entre valores de datos. Estas son algunas de las funciones clave de DB2:
v Restricciones
v Tipos definidos por el usuario (UDT) y objetos grandes (LOB)
v Funciones definidas por el usuario (UDF)
v Activadores
v Procedimientos almacenados
Para decidir si se deben utilizar o no funciones de DB2, tenga en cuenta los
puntos siguientes:
Independencia de la aplicacin
Puede hacer que la aplicacin sea independiente de los datos que
procesa. Mediante funciones de DB2 que se ejecutan en la base de
datos puede mantener y cambiar la lgica relacionada con los datos
sin que ello afecte a la aplicacin. Si tiene que realizar un cambio en
dicha lgica, slo tiene que hacerlo en un lugar, el servidor, y no en
cada aplicacin que accede a los datos.
Rendimiento
Puede aumentar el rendimiento de la aplicacin almacenando y
ejecutando partes de la misma en el servidor. Esto enva parte del
proceso a mquinas servidor generalmente ms potentes y permite
reducir el trfico de la red entre la aplicacin cliente y el servidor.
Requisitos de la aplicacin
Es posible que la aplicacin tenga lgica exclusiva que otras
aplicaciones no tengan. Por ejemplo, si la aplicacin procesa errores de
entrada de datos en un orden determinado que no resultara
adecuado para otras aplicaciones, probablemente desear escribir su
propio cdigo para manejar esta situacin.
En algunos casos, puede decidir utilizar funciones de DB2 que se ejecuten en
el servidor porque as las pueden utilizar varias aplicaciones. En otros casos,
desear conservar la lgica en la aplicacin porque slo esta la utiliza.
v Procedimientos almacenados de DB2 en la pgina 23
v Mtodos y funciones definidas por el usuario de DB2 en la pgina 24
v Tipos definidos por el usuario (UDT) y objetos grandes (LOB) en la
pgina 26
v Activadores de DB2 en la pgina 29
Procedimientos almacenados de DB2
Normalmente, las aplicaciones acceden a la base de datos a travs de la red.
Esto puede dar lugar a un bajo rendimiento si se tienen que devolver muchos
datos. Un procedimiento almacenado se ejecuta en el servidor de base de
datos. Una aplicacin cliente puede llamar al procedimiento almacenado, el
cual lleva a cabo el acceso a la base de datos sin devolver datos innecesarios a
travs de la red. El procedimiento almacenado slo tiene que devolver los
resultados que necesita la aplicacin cliente.
Puede obtener varias ventajas de la utilizacin de procedimientos
almacenados:
Reduccin del trfico de la red
Si agrupa sentencias de SQL puede reducir el trfico de la red.
Una aplicacin tpica necesita dos viajes por la red para cada
sentencia de SQL. La agrupacin de sentencias de SQL da
lugar a dos viajes a travs de la red para cada grupo de
sentencias, lo que mejora el rendimiento de las aplicaciones.
Acceso a funciones que slo existen en el servidor
Los procedimientos almacenados pueden acceder a mandatos
que slo se ejecutan en el servidor, como LIST DATABASE
DIRECTORY y LIST NODE DIRECTORY; pueden ofrecer las
ventajas de mayor memoria y espacio de disco de las
mquinas servidor, y pueden acceder a cualquier software
adicional instalado en el servidor.
Cumplimiento de las normas empresariales
Puede utilizar procedimientos almacenados para definir
normas empresariales comunes a varias aplicaciones. Es otra
forma de definir normas empresariales, adems de utilizar
restricciones y activadores.
Cuando una aplicacin llama al procedimiento almacenado,
procesa los datos de forma coherente de acuerdo a las normas
definidas en el procedimiento almacenado. Si tiene que
cambiar las normas, slo tiene que realizar el cambio una vez
en el procedimiento almacenado, no en cada aplicacin que lo
llama.
v Centro de desarrollo en la pgina 25
Mtodos y funciones definidas por el usuario de DB2
Es posible que las funciones integradas que se suministran con SQL no
cumplan con todos los requisitos de sus aplicaciones. Para permitirle ampliar
estas funciones, DB2 da soporte a funciones definidas por el usuario (UDF) y
mtodos. Puede escribir su propio cdigo en Visual Basic, C/C++, Java o SQL
para realizar operaciones dentro de cualquier sentencia de SQL que devuelva
un solo valor escalar o una tabla.
Las UDF y los mtodos le ofrecen una gran flexibilidad. Devuelven un solo
valor escalar como parte de una expresin. Adems, las funciones pueden
devolver tablas enteras a partir de fuentes que no sean de base de datos,
como hojas de clculo.
Las UDF y los mtodos proporcionan un mtodo de estandarizar las
aplicaciones. Al implantar un conjunto comn de rutinas, muchas aplicaciones
pueden procesar datos del mismo modo, asegurando as resultados
coherentes.
Las funciones definidas por el usuario y los mtodos tambin dan soporte a la
programacin orientada a objetos en las aplicaciones. Permiten realizar
abstracciones, lo que le permite definir interfaces comunes que se pueden
utilizar para llevar a cabo operaciones en objetos de datos. Adems, permiten
realizar encapsulaciones, lo que le permite controlar el acceso a los datos
subyacentes de un objeto y protegerlos frente a una manipulacin directa y
posibles daos.
Centro de desarrollo
El Centro de desarrollo de DB2 proporciona un entorno de desarrollo de fcil
utilizacin para crear, instalar y probar procedimientos almacenados. Le
permite concentrarse en la creacin de la lgica del procedimiento almacenado
en vez de hacerlo en los detalles del registro, la creacin y la instalacin de
procedimientos almacenados en un servidor DB2. Adems, con el Centro de
desarrollo puede desarrollar procedimientos almacenados en un sistema
operativo y crearlos en otros sistemas operativos de servidor.
El Centro de desarrollo es una aplicacin grfica que soporta un rpido
desarrollo. Mediante el Centro de desarrollo puede realizar las tareas
siguientes:
v Crear procedimientos almacenados nuevos.
v Crear procedimientos almacenados en servidores DB2 locales y remotos.
v Modificar y volver a crear procedimientos almacenados existentes.
v Probar y depurar la ejecucin de procedimientos almacenados instalados.
Puede activar el Centro de desarrollo como una aplicacin separada del grupo
de programas DB2 Universal Database o lo puede activar desde cualquiera de
las aplicaciones de desarrollo siguientes:
v Microsoft Visual Studio
v Microsoft Visual Basic
v IBM VisualAge para Java
Tambin puede iniciar el Centro de desarrollo desde el Centro de control para
DB2 para OS/390. Puede iniciar el Centro de desarrollo como un proceso
separado desde el men Herramientas del Centro de control, desde la barra
de herramientas o desde la carpeta Procedimientos almacenados. Asimismo,
desde la ventana Proyecto del Centro de desarrollo puede exportar uno o ms
procedimientos almacenados SQL creados para un servidor DB2 para OS/390
a un archivo especfico que se pueda ejecutar en el procesador de lnea de
mandatos (CLP).
El Centro de desarrollo gestiona el trabajo utilizando proyectos. Cada
proyecto del Centro de desarrollo guarda las conexiones con bases de datos
especficas, como por ejemplo servidores DB2 para OS/390. Adems, puede
crear filtros para visualizar subconjuntos de los procedimientos almacenados
en cada una de las bases de datos. Cuando abra un proyecto nuevo o
existente del Centro de desarrollo, puede filtrar los procedimientos
almacenados de forma que los visualice en base a su nombre, esquema,
lenguaje o ID de coleccin (slo para OS/390).
En el proyecto del Centro de desarrollo se guarda informacin de conexin;
por consiguiente, cuando abra un proyecto existente, automticamente se le
solicitar que entre su ID de usuario y contrasea para la base de datos.
Utilizando el asistente para Insertar procedimiento almacenado SQL, puede
crear procedimientos almacenados SQL en un servidor DB2 para OS/390. Para
un procedimiento almacenado SQL creado para un servidor DB2 para OS/390,
puede establecer opciones especficas de compilacin, previnculacin, enlace,
vinculacin, ejecucin, entorno WLM y seguridad externa.
Asimismo, puede obtener de SQL informacin de costes sobre el
procedimiento almacenado SQL, la cual incluye informacin sobre el tiempo
de CPU y otras informaciones de costes para la hebra en la que se ejecuta el
procedimiento almacenado SQL. En concreto, puede obtener informacin de
costes sobre el tiempo de espera de contencin de enclavamiento/bloqueo,
sobre el nmero de obtenciones de pgina, el nmero de E/S de lectura y el
nmero de E/S de grabacin.
Para obtener informacin de costes, el Centro de desarrollo conecta con un
servidor DB2 para OS/390, ejecuta la sentencia de SQL y llama a un
procedimiento almacenado (DSNWSPM) para averiguar cunto tiempo de
CPU ha utilizado el procedimiento almacenado SQL.
v Rutinas de automatizacin de OLE en la pgina 28
Tipos definidos por el usuario (UDT) y objetos grandes (LOB)
Cada elemento de datos de la base de datos se almacena en una columna de
una tabla y cada columna se define con un tipo de datos. El tipo de datos
impone lmites en los tipos de valores que puede colocar en la columna y en
las operaciones que puede realizar en los mismos. Por ejemplo, una columna
de enteros slo puede contener nmeros comprendidos dentro de un rango
fijo. DB2 incluye un conjunto de tipos de datos integrados con caractersticas
y comportamientos definidos: series de caracteres, numricos, valores de fecha
y hora, objetos grandes, valores nulos, series grficas, series binarias y enlaces
de datos.
Sin embargo, es posible que en algunas ocasiones los tipos de datos
integrados no cumplan con los requisitos de las aplicaciones. DB2 proporciona
tipos definidos por el usuario (UDT) que le permiten definir tipos de datos
diferenciados que necesite para las aplicaciones.
Los UDT se basan en los tipos de datos integrados. Cuando define un UDT,
tambin define las operaciones que son vlidas para el UDT. Por ejemplo,
puede definir un tipo de datos MONEY basado en el tipo de datos DECIMAL.
Sin embargo, para el tipo de datos MONEY puede permitir nicamente
operaciones de suma y resta, pero no operaciones de multiplicacin y
divisin.
Los objetos grandes (LOB) le permiten almacenar y manipular objetos de
datos grandes y complejos en la base de datos; objetos como audio, vdeo,
imgenes y documentos grandes.
La combinacin de UDT y LOB le ofrece una potencia adicional. Ya no est
limitado a utilizar los tipos de datos integrados que se suministran con DB2
para perfilar datos empresariales y para capturar la semntica de dichos
datos. Puede utilizar UDT para definir estructuras de datos grandes y
complejas para aplicaciones avanzadas.
Adems de ampliar los tipos de datos integrados, los UDT proporcionan otras
ventajas:
Soporte de programacin orientada a objetos en las aplicaciones
Puede agrupar objetos parecidos en tipos de datos relacionados. Estos
tipos tienen un nombre, una representacin interna y un
comportamiento especfico. Mediante la utilizacin de UDT, puede
indicar a DB2 el nombre del nuevo tipo y el modo en que se debe
representar internamente. Un LOB es una de las posibles
representaciones internas para su nuevo tipo y es la representacin
ms adecuada para estructuras de datos grandes y complejas.
Integridad de los datos a travs de una estricta tipificacin y encapsulacin
La tipificacin estricta garantiza que slo las funciones y operaciones
definidas en el tipo diferenciado se pueden aplicar al tipo. La
encapsulacin asegura que el comportamiento de los UDT est
restringido por las funciones y operadores que se pueden aplicar a los
mismos. En DB2, el comportamiento correspondiente a los UDT se
puede proporcionar en forma de funciones definidas por el usuario
(UDF), que se pueden escribir de modo que se acomoden a una
amplia gama de requisitos del usuario.
Rendimiento a travs de la integracin en el gestor de bases de datos
Puesto que los UDT se representan internamente, igual que los tipos
de datos integrados, comparten el mismo cdigo eficiente que los
tipos de datos integrados para implantar funciones integradas,
operadores de comparacin, ndices y otras funciones. La excepcin a
esto son los UDT que utilizan LOB, los cuales no se pueden utilizar
con operadores de comparacin ni ndices.
v Uso de objetos grandes en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
v Tipos definidos por el usuario en el manual Gua de desarrollo de
aplicaciones: Programacin de aplicaciones de servidor
Rutinas de automatizacin de OLE
La automatizacin de OLE (Object Linking and Embedding) forma parte de la
arquitectura OLE 2.0 de Microsoft Corporation. Con la automatizacin de
OLE, las aplicaciones, independientemente del lenguaje en el que estn
escritas, pueden exponer sus propiedades y mtodos en objetos de
automatizacin de OLE. Otras aplicaciones, como Lotus Notes o Microsoft
Exchange, pueden integrar estos objetos aprovechando estas propiedades y
mtodos a travs de la automatizacin de OLE.
DB2 para sistemas operativos Windows proporciona acceso a objetos de
automatizacin de OLE mediante UDF, mtodos y procedimientos
almacenados. Para acceder a objetos de automatizacin de OLE e invocar sus
mtodos, debe registrar los mtodos de los objetos como rutinas (UDF,
mtodos o procedimientos almacenados) en la base de datos. Las aplicaciones
DB2 pueden utilizar los mtodos invocando las rutinas.
Por ejemplo, puede desarrollar una aplicacin que consulte datos de una hoja
de clculo creada mediante un producto como Microsoft Excel. Para ello, debe
desarrollar una funcin de tabla de automatizacin de OLE que recupere
datos de la hoja de trabajo y los devuelva a DB2. Luego DB2 puede procesar
los datos, realizar un proceso analtico en lnea (OLAP) y devolver el
resultado de la consulta a la aplicacin.
v Centro de desarrollo en la pgina 25
Funciones de tabla de OLE DB
Microsoft OLE DB es un conjunto de interfaces OLE/COM que proporcionan
a las aplicaciones acceso uniforme a datos almacenados en distintas fuentes de
informacin. DB2 Universal Database simplifica la creacin de aplicaciones
OLE DB al permitirle definir funciones de tabla que acceden a una fuente de
datos OLE DB. Puede llevar a cabo operaciones que incluyen GROUP BY,
JOIN y UNION, en fuentes de datos que exponen sus datos a travs de
interfaces OLE DB. Por ejemplo, puede definir una funcin de tabla OLE DB
que devuelva una tabla de una base de datos Microsoft Access o de un listn
Microsoft Exchange y luego crear un informe que combine datos procedentes
de esta funcin de tabla OLE DB con datos de su base de datos DB2.
La utilizacin de funciones de tabla OLE DB reduce el esfuerzo que hay que
dedicar al desarrollo de aplicaciones al proporcionar acceso integrado a
cualquier proveedor de OLE DB. Para funciones de tabla de automatizacin C,
Java y OLE, el desarrollador tiene que implantar la funcin de tabla, mientras
que en el caso de funciones de tabla OLE DB un consumidor genrico
integrado OLE DB acta como interfaz con cualquier proveedor de OLE DB
para recuperar datos. Slo tiene que registrar una funcin de tabla de tipo de
lenguaje OLEDB y hacer referencia al proveedor de OLE DB y al conjunto de
filas relevante como una fuente de datos. No tiene que realizar ninguna
programacin de UDF para aprovechar las funciones de tabla de OLE DB.
v Objetivo de IBM OLE DB Provider para DB2 en la pgina 391
v Habilitacin automtica de servicios OLE DB por parte de IBM OLE DB
Provider en la pgina 396
v Soporte de IBM OLE DB Provider de interfaces y componentes de OLE
DB en la pgina 403
v Soporte de IBM OLE DB de propiedades de OLE DB en la pgina 406
Activadores de DB2
Un activador define un conjunto de acciones ejecutadas por una operacin de
supresin, insercin o actualizacin en una tabla especificada. Cuando se
ejecuta dicha operacin de SQL, se dice que el activador se activa. El
activador se puede activar antes de la operacin de SQL o despus de la
misma. Puede definir un activador mediante la sentencia de SQL CREATE
TRIGGER.
Puede utilizar activadores que se ejecuten antes de una actualizacin o
insercin de varias formas:
v Para comprobar o modificar valores antes de que se actualicen o inserten
realmente en la base de datos. Esto resulta til si tiene que transformar
datos desde el modo que el usuario los ve a otro formato interno de la base
de datos.
v Para ejecutar otras operaciones que no son de base de datos codificadas en
funciones definidas por el usuario.
Paralelamente, puede utilizar activadores que se ejecuten despus de una
actualizacin o insercin de varias formas:
v Para actualizar datos de otras tablas. Esta funcin resulta til para mantener
relaciones entre datos o para conservar informacin de seguimiento de
auditora.
v Para comparar con otros datos de la tabla o de otras tablas. Esta funcin
resulta til para asegurar la integridad de los datos cuando no resulta
adecuado utilizar restricciones de integridad referencial o cuando las
restricciones de comprobacin de tabla limitan la comprobacin nicamente
a la tabla actual.
v Para ejecutar operaciones que no son de base de datos codificadas en
funciones definidas por el usuario. Esta funcin resulta til para emitir
alertas o para actualizar informacin externa a la base de datos.
La utilizacin de activadores presenta varias ventajas:
Desarrollo ms rpido de aplicaciones
Los activadores se almacenan en la base de datos y estn disponibles
para todas las aplicaciones, lo que le releva de la necesidad de
codificar funciones equivalentes para cada aplicacin.
Cumplimiento global de las normas empresariales
Los activadores se definen una vez y los utilizan todas las
aplicaciones que utilizan los datos controlados por los activadores.
Facilidad de mantenimiento
Los cambios slo se tienen que hacer una vez en la base de datos, en
lugar de tener que hacerlos en cada aplicacin que utiliza un
activador.
v Activadores en el desarrollo de aplicaciones en el manual Gua de
desarrollo de aplicaciones: Programacin de aplicaciones de servidor
v Directrices para la creacin de activadores en el manual Gua de desarrollo
de aplicaciones: Programacin de aplicaciones de servidor
Captulo 2. Codificacin de una aplicacin DB2
Requisitos previos para programacin . . . 32
Visin general de la codificacin de
aplicaciones DB2 . . . . . . . . . . 33
Programacin de una aplicacin autnoma 33
Creacin de una seccin de declaracin de
una aplicacin autnoma. . . . . . . 34
Declaracin de variables que interactan
con el gestor de bases de datos. . . . . 34
Declaracin de variables que representan
objetos de SQL . . . . . . . . . . 35
principal con el Generador de
declaraciones db2dclgn . . . . . . . 38
Relacin de variables del lenguaje
principal con una sentencia de SQL . . . 39
Declaracin de la SQLCA para el manejo
de errores . . . . . . . . . . . . 40
Manejo de errores utilizando la sentencia
WHENEVER. . . . . . . . . . . 41
Adicin de sentencias no ejecutables a una
aplicacin . . . . . . . . . . . . 43
Conexin de una aplicacin con una base
de datos . . . . . . . . . . . . 43
Codificacin de transacciones . . . . . 44
sentencia COMMIT . . . . . . . . 45
sentencia ROLLBACK. . . . . . . . 46
Finalizacin de un programa de aplicacin 48
Finalizacin implcita de una transaccin
en una aplicacin autnoma . . . . . 48
Infraestructura de seudocdigo de
aplicacin . . . . . . . . . . . . 49
Recursos para crear prototipos de
sentencias de SQL . . . . . . . . . 50
API administrativas en SQL incorporado o
en programas de CLI de DB2 . . . . . 52
Definicin de FIPS 127-2 e ISO/ANS
SQL92 . . . . . . . . . . . . . 52
Control de valores de datos y relaciones . . 52
Control de valores de datos . . . . . . 52
Control de valores de datos mediante tipos
de datos . . . . . . . . . . . . 53
restricciones exclusivas . . . . . . . 53
restricciones de comprobacin de tabla . . 54
vistas con la opcin Check . . . . . . 55
lgica de aplicacin y tipos de variables de
programa . . . . . . . . . . . . 55
Control de relaciones de datos . . . . . 56
activadores . . . . . . . . . . . 57
activadores anteriores . . . . . . . . 57
activadores posteriores . . . . . . . 58
lgica de aplicacin . . . . . . . . 58
Lgica de aplicacin en el servidor . . . 59
Consideraciones sobre autorizacin para SQL
y API . . . . . . . . . . . . . . 60
SQL incorporado . . . . . . . . . 60
SQL dinmico . . . . . . . . . . 61
SQL esttico . . . . . . . . . . . 63
API . . . . . . . . . . . . . . 63
Prueba de la aplicacin . . . . . . . . 64
Configuracin del entorno de prueba para
una aplicacin . . . . . . . . . . 64
Configuracin de un entorno de prueba 64
Creacin de tablas y vistas de prueba 65
Generacin de datos de prueba . . . 66
Depuracin y optimizacin de una
aplicacin . . . . . . . . . . . . 68
Macro automtica de proyectos de IBM DB2
Universal Database para Microsoft Visual
C++. . . . . . . . . . . . . . . 69
La macro automtica de proyectos de IBM
DB2 Universal Database para Microsoft
Visual C++ . . . . . . . . . . . 69
Terminologa de la macro automtica de
herramientas de IBM DB2 Universal
Database para Microsoft Visual C++ . . . 74
Requisitos previos para programacin
Antes de desarrollar una aplicacin, necesita el entorno operativo adecuado.
Se debe instalar y configurar adecuadamente lo siguiente:
v Un compilador o intrprete soportado para desarrollar las aplicaciones.
v DB2 Universal Database, de forma local o remota.
v DB2 Application Development Client.
Puede desarrollar aplicaciones en un servidor o en cualquier cliente que tenga
instalado DB2 Application Development Client. Puede ejecutar aplicaciones
con el servidor, DB2 Run-Time Client o DB2 Administrative Client. Tambin
puede desarrollar programas Java JDBC en uno de estos clientes, suponiendo
que instale el componente Java Enablement cuando instale el cliente. Esto
significa que puede ejecutar cualquier aplicacin DB2 en estos clientes. Sin
embargo, a no ser que tambin instale DB2 Application Development Client
con estos clientes, slo puede desarrollar aplicaciones JDBC en los mismos.
DB2 da soporte a los lenguajes de programacin C, C++, Java (SQLj), COBOL
y FORTRAN a travs de sus precompiladores. Adems, DB2 proporciona
soporte para los lenguajes interpretados dinmicamente Perl, Java (JDBC) y
REXX.
Nota: el soporte de FORTRAN y REXX se estabiliz en DB2 Versin 5 y no se
ha planificado ninguna mejora para el soporte de FORTRAN o REXX
en el futuro.
DB2 proporciona una base de datos de ejemplo, que necesitar para ejecutar
los programas de ejemplo suministrados.
v Configuracin del entorno de desarrollo de aplicaciones en el manual
Gua de desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
v Configuracin de la base de datos sample en el manual Gua de desarrollo
Visin general de la codificacin de aplicaciones DB2
Las secciones siguientes contienen una visin general sobre cmo codificar
una aplicacin de DB2.
Programacin de una aplicacin autnoma
Una aplicacin autnoma es una aplicacin que no llama a objetos de base de
datos, como procedimientos almacenados, cuando se ejecuta. Cuando escriba
la aplicacin, debe asegurarse de que determinadas sentencias de SQL
aparezcan al principio y al final del programa para manejar la transicin de
lenguaje principal a las sentencias de SQL incorporado.
Procedimiento:
Para programar una aplicacin autnoma, debe asegurarse de:
1. Crear la seccin de declaracin.
2. Establecer conexin con la base de datos.
3. Escribir una o ms transacciones.
4. Finalizar cada transaccin utilizando uno de los siguientes mtodos:
v Confirmar los cambios realizados por la aplicacin en la base de datos.
v Retrotraer los cambios realizados por la aplicacin en la base de datos.
5. Finalizar el programa.
v Requisitos previos para programacin en la pgina 32
v Infraestructura de seudocdigo de aplicacin en la pgina 49
v Recursos para crear prototipos de sentencias de SQL en la pgina 50
v Archivos de ejemplo en el manual Gua de desarrollo de aplicaciones:
v Programas de ejemplo: estructura y diseo en el manual Gua de desarrollo
v Creacin de una seccin de declaracin de una aplicacin autnoma en la
pgina 34
v Conexin de una aplicacin con una base de datos en la pgina 43
v Codificacin de transacciones en la pgina 44
v Finalizacin de una transaccin con la sentencia COMMIT en la pgina
45
v Finalizacin de una transaccin con la sentencia ROLLBACK en la pgina
46
Captulo 2. Codificacin de una aplicacin DB2 33
v Finalizacin de un programa de aplicacin en la pgina 48
v Configuracin de un entorno de prueba en la pgina 64
Creacin de una seccin de declaracin de una aplicacin autnoma
El principio de cada programa debe contener una seccin de declaracin, que
contiene:
v Declaraciones de todas las variables y estructuras de datos que el gestor de
bases de datos utiliza para interactuar con el programa de sistema principal
v Sentencias de SQL que proporcionan funciones de manejo de errores
configurando el rea de comunicaciones de SQL (SQLCA)
Tenga en cuenta que las aplicaciones DB2 escritas en Java lanzan un
SQLException, que debe manejar en un bloque catch en lugar de utilizando
SQLCA.
Un programa puede contener varias secciones declare de SQL.
Procedimiento:
Para crear la seccin de declaracin:
1. Utilice la sentencia de SQL BEGIN DECLARE SECTION para abrir la
seccin.
2. Codifique las declaraciones.
3. Utilice la sentencia de SQL END DECLARE SECTION para finalizar la
seccin.
v Valores de SQLSTATE y SQLCODE en Java en la pgina 335
v Declaracin de variables que interactan con el gestor de bases de datos
en la pgina 34
v Declaracin de variables que representan objetos de SQL en la pgina 35
v Relacin de variables del lenguaje principal con una sentencia de SQL en
la pgina 39
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Declaracin de la SQLCA para el manejo de errores en la pgina 40
Declaracin de variables que interactan con el gestor de bases de datos
Todas las variables que interactan con el gestor de bases de datos se deben
declarar en la seccin de declaracin de SQL.
Las variables de programa de sistema principal declaradas en una seccin de
declaracin de SQL se denominan variables del lenguaje principal. Puede
utilizar variables del lenguaje principal en referencias a variables del lenguaje
principal en sentencias de SQL. El cdigo variable-lenguaje-principal se utiliza
en diagramas de sintaxis en sentencias de SQL.
Procedimiento:
Para declarar una variable, codifquela en la seccin de declaracin de SQL. A
continuacin se muestra un ejemplo de variable del lenguaje principal en
C/C++:
EXEC SQL BEGIN DECLARE SECTION;
short dept=38, age=26;
double salary;
char CH;
char name1[9], NAME2[9];
/* Comentario de C */
short nul_ind;
EXEC SQL END DECLARE SECTION;
Los atributos de cada variable del lenguaje principal dependen del modo en
que se utiliza la variable en la sentencia de SQL. Por ejemplo, las variables
que reciben datos de tablas de DB2 o que almacenan datos en las mismas
deben tener atributos de tipo de datos y longitud compatibles con la columna
a la que se accede. Para determinar el tipo de datos de cada variable, debe
estar familiarizado con los tipos de datos de DB2.
v Tipos de datos SQL soportados en C y C++ en la pgina 218
v Tipos de datos de SQL soportados en COBOL en la pgina 254
v Tipos de datos SQL soportados en FORTRAN en la pgina 276
v Tipos de datos SQL soportados en Java en la pgina 291
v Tipos de datos SQL soportados en REXX en la pgina 381
Declaracin de variables que representan objetos de SQL
Declare las variables que representan objetos de SQL en la seccin de
declaracin de SQL del programa de aplicacin.
Procedimiento:
Codifique la variable en el formato adecuado para el lenguaje en el que
escribe el programa de aplicacin.
Cuando codifique la variable, recuerde que los nombres de tablas, alias, vistas
y correlaciones tienen una longitud mxima de 128 bytes. Los nombres de
columna tienen una longitud mxima de 30 bytes. Los nombres de esquema
tienen una longitud mxima de 30 bytes. Es posible que en futuros releases de
DB2 aumenten las longitudes de nombres de columna y de otros
identificadores de objetos SQL hasta 128 bytes. Si declara variables que
representan objetos SQL con longitudes de menos de 128 bytes, futuros
aumentos en longitudes de identificadores de objetos SQL pueden afectar a la
estabilidad de las aplicaciones. Por ejemplo, si declara la variable
char[9]schema_name en una aplicacin C++ para que albergue un nombre de
esquema, la aplicacin funciona correctamente para los nombres de esquema
permitidos en DB2 Versin 6, que tienen una longitud mxima de 8 bytes.
char[9] schema_name; /* alberga nombre de esquema delimitado por nulos de hasta 8 bytes;
funciona para DB2 Versin 6, pero puede truncar nombres de esquema en futuros releases */
Sin embargo, si migra la base de datos a una versin de DB2 que acepta
nombres de esquema con una longitud mxima de 30 bytes, la aplicacin no
puede diferenciar entre los nombres de esquema LONGSCHEMA1 y LONGSCHEMA2.
El gestor de bases de datos trunca los nombres de esquema a su lmite de 8
bytes, LONGSCHE, y cualquier sentencia de la aplicacin que dependa de
diferenciar los nombres de esquema fallar. Para aumentar la longevidad de la
aplicacin, declare la variable de nombre de esquema con una longitud de 128
bytes del siguiente modo:
char[129] schema_name; /* alberga nombre de esquema delimitado por nulos hasta 128 bytes
vlido para DB2 Versin 7 y siguientes */
Para mejorar el futuro funcionamiento de la aplicacin, considere la
posibilidad de declarar todas las variables de la aplicacin que representan
nombres de objetos SQL con longitudes de 128 bytes. Debe sopesar la ventaja
de mejorar la compatibilidad frente al aumento de recursos del sistema que
necesitan las variables ms largas.
Para aplicaciones C/C++, puede simplificar la codificacin de declaraciones y
aumentar la claridad del cdigo si utiliza la expansin de macro C para
declarar las longitudes de identificadores de objetos SQL. Puesto que el
archivo include sql.h declara que SQL_MAX_IDENT sea 128, puede declarar
fcilmente identificadores de objetos SQL con la macro SQL_MAX_IDENT. Por
ejemplo:
#include <sql.h>
char[SQL_MAX_IDENT+1] schema_name;
char[SQL_MAX_IDENT+1] table_name;
char[SQL_MAX_IDENT+1] employee_column;
char[SQL_MAX_IDENT+1] manager_column;
v Variables del lenguaje principal en C y C++ en la pgina 183
v Sintaxis de las variables del lenguaje principal de tipo carcter fijas y
terminadas en nulo en C y C++ en la pgina 189
v Expansin de macros en C en la pgina 200
v Variables del lenguaje principal en COBOL en la pgina 240
v Variables del lenguaje principal en FORTRAN en la pgina 269
v Variables del lenguaje principal en Java en la pgina 290
v Variables del lenguaje principal en REXX en la pgina 374
v Sintaxis de las variables numricas del lenguaje principal en C y C++ en
la pgina 187
v Sintaxis de las variables del lenguaje principal de tipo carcter de longitud
variable en C o C++ en la pgina 190
v Sintaxis de la declaracin grfica de formatos grficos de un solo grfico y
terminados en nulo en C y C++ en la pgina 192
v Sintaxis para la declaracin grfica del formato estructurado
VARGRAPHIC en C o C++ en la pgina 194
v Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
C o C++ en la pgina 195
v Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en C o C++ en la pgina 198
v Sintaxis de declaraciones de variables del lenguaje principal de referencia
de archivos en C o C++ en la pgina 199
v Sintaxis de las variables numricas del lenguaje principal en COBOL en
la pgina 242
fija en COBOL en la pgina 243
v Sintaxis de las variables grficas del lenguaje principal de longitud fija en
COBOL en la pgina 245
v Sintaxis de las variables del lenguaje principal LOB en COBOL en la
pgina 246
v Sintaxis de las variables del lenguaje principal de localizador de LOB en
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
v Sintaxis de las variables numricas del lenguaje principal en FORTRAN
en la pgina 271
v Sintaxis de las variables de tipo carcter del lenguaje principal en
FORTRAN en la pgina 271
grande (LOB) en FORTRAN en la pgina 274
v Sintaxis de las declaraciones de localizador de LOB en REXX en la pgina
378
v Sintaxis de las declaraciones de referencia de archivos LOB en REXX en
la pgina 379
Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn
Puede utilizar el Generador de declaraciones para generar declaraciones
correspondientes a una determinada tabla de una base de datos. ste crea
archivos fuente de declaracin en SQL incorporado que puede insertar
fcilmente en las aplicaciones. db2dclgn da soporte a los lenguajes C/C++,
Java, COBOL y FORTRAN.
Procedimiento:
Para generar archivos de declaracin, entre el mandato db2dclgn en el
siguiente formato:
db2dclgn -d database-name -t table-name [options]
Por ejemplo, para generar las declaraciones para la tabla STAFF en la base de
datos SAMPLE en C en el archivo de salida staff.h, emita el siguiente
mandato:
db2dclgn -d sample -t staff -l C
El archivo staff.h resultante contiene:
struct
{
short id;
struct
{
short length;
char data[9];
} name;
short dept;
char job[5];
short years;
double salary;
double comm;
} staff;
v db2dclgn - Mandato Generador de declaraciones en el manual Consulta de
mandatos
Relacin de variables del lenguaje principal con una sentencia de SQL
Puede utilizar variables del lenguaje principal para recibir datos del gestor de
bases de datos o para transferir datos al mismo desde el programa de sistema
principal. Las variables del lenguaje principal que reciben datos del gestor de
bases de datos son variables del lenguaje principal de salida, mientras que las que
transfieren datos al mismo desde el programa de sistema principal son
variables del lenguaje principal de entrada.
Considere la siguiente sentencia SELECT INTO:
SELECT HIREDATE, EDLEVEL
INTO :hdate, :lvl
FROM EMPLOYEE
WHERE EMPNO = :idno
La sentencia contiene dos variables del lenguaje principal de salida, hdate y
lvl, y una variable del lenguaje principal de entrada, idno. El gestor de bases
de datos utiliza los datos almacenados en la variable del lenguaje principal
idno para determinar el EMPNO de la fila que se recupera de la tabla
EMPLOYEE. Si el gestor de bases de datos encuentra una fila que cumple con
los criterios de bsqueda, hdate y lvl reciben los datos almacenados en las
columnas HIREDATE y EDLEVEL, respectivamente. Esta sentencia ilustra una
interaccin entre el programa de sistema principal y el gestor de bases de
datos utilizando columnas de la tabla EMPLOYEE.
Procedimiento:
Para definir la variable del lenguaje principal para utilizarla con una columna:
1. Averige el tipo de datos SQL correspondiente a dicha columna. Para ello,
consulte el catlogo del sistema, que es un conjunto de vistas que
contienen informacin sobre todas las tablas creadas en la base de datos.
2. Codifique las declaraciones adecuadas segn el lenguaje principal.
A cada columna de una tabla se asigna un tipo de datos en la definicin
CREATE TABLE. Debe relacionar este tipo de datos con el tipo de datos de
lenguaje principal. Por ejemplo, el tipo de datos INTEGER es un entero
con signo de 32 bits. Esto equivale a las siguientes entradas de descripcin
de datos en cada uno de los lenguajes principales, respectivamente:
C/C++:
sqlint32 variable_name;
Java: int variable_name;
COBOL:
01 variable-name PICTURE S9(9) COMPUTATIONAL-5.
FORTRAN:
INTEGER*4 variable_name
Tambin puede utilizar el programa de utilidad de generacin de
declaraciones (db2dclgn) para generar las declaraciones adecuadas para una
determinada tabla de una base de datos.
v Vistas de catlogo en el manual Consulta de SQL, Volumen 1
v Declaracin de variables que interactan con el gestor de bases de datos
en la pgina 34
pgina 34
Declaracin de la SQLCA para el manejo de errores
Puede declarar la SQLCA en el programa de aplicacin para que el gestor de
bases de datos pueda devolver informacin a la aplicacin. Cuando
preprocesa el programa, el gestor de bases de datos inserta las declaraciones
de variables del lenguaje principal en lugar de la sentencia INCLUDE. El
sistema se comunica con el programa utilizando las variables para distintivos
de aviso, cdigos de error e informacin de diagnstico.
Despus de ejecutar cada sentencia de SQL, el sistema devuelve un cdigo de
retorno en SQLCODE y en SQLSTATE. SQLCODE es un valor entero que
resume la ejecucin de la sentencia y SQLSTATE es un campo de carcter que
proporciona cdigos de error comunes entre los productos de bases de datos
relacionales de IBM. SQLSTATE tambin cumple con los estndares ISO/ANS
SQL92 y FIPS 127-2.
Observe que si SQLCODE es menor que 0, significa que se ha producido un
error y que la sentencia no se ha procesado. Si SQLCODE es mayor que 0,
significa que se ha emitido un aviso, pero la sentencia se procesa.
Para una aplicacin DB2 escrita en C o C++, si la aplicacin est formada por
varios archivos fuente, slo uno de los archivos debera incluir la sentencia
EXEC SQL INCLUDE SQLCA para evitar varias definiciones de SQLCA. El
resto de los archivos fuente deberan utilizar las siguientes lneas:
#include "sqlca.h"
extern struct sqlca sqlca;
Procedimiento:
Para declarar la SQLCA, codifique la sentencia INCLUDE SQLCA en el programa
del siguiente modo:
v Para aplicaciones C o C++ utilice:
EXEC SQL INCLUDE SQLCA;
v En aplicaciones Java no se utiliza de forma explcita la SQLCA. Utilice en
su lugar los mtodos de instancia SQLException para obtener los valores de
SQLSTATE y SQLCODE.
v Para aplicaciones COBOL utilice:
EXEC SQL INCLUDE SQLCA END-EXEC.
v Para aplicaciones FORTRAN utilice:
EXEC SQL INCLUDE SQLCA
Si la aplicacin debe cumplir con el estndar ISO/ANS SQL92 o FIPS 127-2,
no utilice las sentencias anteriores ni la sentencia INCLUDE SQLCA.
v Definicin de FIPS 127-2 e ISO/ANS SQL92 en la pgina 52
v Manejo de errores utilizando la sentencia WHENEVER en la pgina 41
v Variables SQLSTATE y SQLCODE en C y C++ en la pgina 224
v Variables SQLSTATE y SQLCODE en COBOL en la pgina 257
v Variables SQLSTATE y SQLCODE en FORTRAN en la pgina 279
v Variables SQLSTATE y SQLCODE en Perl en la pgina 366
pgina 34
Manejo de errores utilizando la sentencia WHENEVER
La sentencia WHENEVER hace que el precompilador genere cdigo fuente
que indica a la aplicacin que vaya a una etiqueta especificada si se produce
un error, un aviso o si no se encuentran filas durante la ejecucin. La
sentencia WHENEVER afecta a las siguientes sentencias de SQL ejecutables
hasta que otra sentencia WHENEVER altera la situacin.
La sentencia WHENEVER tiene tres formas bsicas:
EXEC SQL WHENEVER SQLERROR accin
EXEC SQL WHENEVER SQLWARNING accin
EXEC SQL WHENEVER NOT FOUND accin
En las sentencias anteriores:
SQLERROR
Identifica cualquier condicin en la que SQLCODE < 0.
SQLWARNING
Identifica cualquier condicin en la que SQLWARN(0) = W o
SQLCODE > 0 pero no es igual a 100.
NOT FOUND
Identifica cualquier condicin en la que SQLCODE = 100.
En cada caso, accin puede ser cualquiera de las siguientes:
CONTINUE
Indica que hay que continuar con la siguiente instruccin de la
aplicacin.
GO TO etiqueta
Indica que hay que ir a la sentencia que va inmediatamente detrs de
la etiqueta especificada despus de GO TO. (GO TO puede
especificarse como dos palabras o como una sola, GOTO.)
Si no se utiliza la sentencia WHENEVER, la accin por omisin consiste en
continuar el proceso si se produce una condicin de error, de aviso o de
excepcin durante la ejecucin.
La sentencia WHENEVER debe aparecer antes de las sentencias de SQL que
desea que se vean afectadas. De lo contrario, el precompilador no sabe que se
debe generar cdigo de manejo de errores adicional para las sentencias de
SQL ejecutables. Puede tener cualquier combinacin de las tres formas bsicas
activas en cualquier momento. El orden en el que declare las tres formas no es
significativo.
Para evitar una situacin de bucle infinito, asegrese de deshacer el manejo
WHENEVER antes de que se ejecute alguna sentencia de SQL dentro del
manejador. Puede hacerlo utilizando la sentencia WHENEVER SQLERROR
CONTINUE.
v WHENEVER sentencia en el manual Consulta de SQL, Volumen 2
Adicin de sentencias no ejecutables a una aplicacin
Si tiene que incluir sentencias de SQL no ejecutables en un programa de
aplicacin, normalmente puede colocarlas en la seccin de declaracin de la
aplicacin. Las sentencias INCLUDE, INCLUDE SQLDA y DECLARE
CURSOR son ejemplos de sentencias no ejecutables.
Procedimiento:
Si desea utilizar la sentencia no ejecutable INCLUDE en la aplicacin,
codifquela del siguiente modo:
INCLUDE nombre-archivo-texto
pgina 34
Conexin de una aplicacin con una base de datos
El programa debe establecer una conexin con la base de datos de destino
para que pueda ejecutar las sentencias de SQL ejecutables. Esta conexin
identifica el ID de autorizacin del usuario que est ejecutando el programa y
el nombre del servidor de base de datos en el que se ejecuta el programa.
Generalmente, el proceso de la aplicacin slo puede conectarse a un servidor
de base de datos cada vez. Este servidor se denomina el servidor actual. Sin
embargo, la aplicacin puede conectarse a varios servidores de bases de datos
dentro de un entorno de actualizacin mltiple. En este caso, slo un servidor
puede ser el servidor actual.
Restricciones:
Se aplican las siguientes restricciones:
v Una conexin dura hasta que se emite una sentencia CONNECT RESET,
CONNECT TO o DISCONNECT.
v En un entorno de actualizacin mltiple, una conexin tambin dura hasta
que se emite DB2 RELEASE y luego DB2 COMMIT. Una sentencia
CONNECT TO no termina una conexin cuando se utiliza la actualizacin
mltiple.
Procedimiento:
El programa puede establecer una conexin con un servidor de bases de
datos:
v De forma explcita, mediante la sentencia CONNECT
v De forma implcita, estableciendo conexin con el servidor de bases de
datos por omisin
v Para aplicaciones Java, mediante una instancia Connection
Consulte la descripcin de la sentencia CONNECT para obtener informacin
sobre estados de conexin y para ver cmo se utiliza la sentencia CONNECT.
Tras la inicializacin, el solicitante de la aplicacin establece un servidor de
base de datos por omisin. Si hay conexiones implcitas habilitadas, los
procesos de la aplicacin iniciados tras la inicializacin se conectan de forma
implcita al servidor de base de datos por omisin. Es recomendable utilizar la
sentencia CONNECT como primera sentencia de SQL ejecutada por un
programa de aplicacin. Una sentencia CONNECT explcita evita la ejecucin
accidental de sentencias de SQL contra la base de datos por omisin.
v Actualizacin mltiple en la pgina 461
v CONNECT (Tipo 1) sentencia en el manual Consulta de SQL, Volumen 2
Codificacin de transacciones
Una transaccin es una secuencia de sentencias de SQL (posiblemente con
cdigo de lenguaje de sistema principal) que el gestor de bases de datos trata
como una unidad. Un trmino alternativo que se utiliza a menudo para
transaccin es unidad de trabajo.
Requisitos previos:
Se debe establecer una conexin con la base de datos contra la que se va a
ejecutar la transaccin.
Procedimiento:
Para codificar una transaccin:
1. Inicie la transaccin con una sentencia de SQL ejecutable.
Una vez establecida la conexin con la base de datos, el programa puede
emitir una o ms:
v Sentencias de manipulacin de datos (por ejemplo, la sentencia SELECT)
v Sentencias de definicin de datos (por ejemplo, la sentencia CREATE)
v Sentencias de control de datos (por ejemplo, la sentencia GRANT)
Una sentencia de SQL ejecutable siempre se produce dentro de una
transaccin. Si un programa contiene una sentencia de SQL ejecutable
despus de que finalice una transaccin, inicia automticamente una nueva
transaccin.
Nota: las seis sentencias siguientes no inician una transaccin porque no
son sentencias ejecutables:
v BEGIN DECLARE SECTION
v INCLUDE SQLCA
v END DECLARE SECTION
v INCLUDE SQLDA
v DECLARE CURSOR
v WHENEVER
2. Finalice la transaccin de una de las siguientes formas:
v Confirme (COMMIT) la transaccin
v Retrotraiga (ROLLBACK) la transaccin
v Finalizacin de una transaccin con la sentencia COMMIT en la pgina
45
v Finalizacin de una transaccin con la sentencia ROLLBACK en la pgina
46
Finalizacin de una transaccin con la sentencia COMMIT
La sentencia COMMIT finaliza la transaccin actual y hace que los cambios en
la base de datos realizados durante la transaccin estn visibles para otros
procesos.
Procedimiento:
Confirme los cambios en cuanto los requisitos de la aplicacin lo permitan. En
concreto, escriba los programas de modo que los cambios no confirmados no
se mantengan mientras se espere una entrada de un terminal, puesto que esto
podra ocasionar que los recursos de la base de datos se mantuvieran durante
mucho tiempo. Al mantener estos recursos se evita la ejecucin de otras
aplicaciones que necesitan dichos recursos.
Los programas de aplicacin deben finalizar de forma explcita cualquier
transaccin antes de terminar.
Si no finaliza las transacciones de forma explcita, DB2 confirma
automticamente todos los cambios realizados durante la transaccin
pendiente del programa cuando el programa finaliza satisfactoriamente,
excepto en sistemas operativos Windows. En sistemas operativos Windows, si
no confirma de forma explcita una transaccin, el gestor de bases de datos
siempre retrotrae los cambios.
DB2 retrotrae los cambios bajo las siguientes condiciones:
v Una condicin de registro lleno
v Cualquier otra condicin del sistema que haga que finalice el proceso del
gestor de bases de datos
La sentencia COMMIT no tiene ningn efecto sobre el contenido de las
variables del lenguaje principal.
v Finalizacin implcita de una transaccin en una aplicacin autnoma en
la pgina 48
v Cdigos de retorno en la pgina 134
v Informacin de error en los campos SQLCODE, SQLSTATE y SQLWARN
en la pgina 134
v COMMIT sentencia en el manual Consulta de SQL, Volumen 2
Finalizacin de una transaccin con la sentencia ROLLBACK
Para garantizar la coherencia de datos en una transaccin, el sistema gestor de
bases de datos se asegura de que todas las operaciones de una transaccin se
completan o de que ninguna se completa. Supongamos, por ejemplo, que el
programa tiene que deducir dinero de una cuenta y aadirlo a otra. Si coloca
estas dos actualizaciones en una sola transaccin, y se produce un error del
sistema mientras se estn procesando, cuando vuelva a iniciar el sistema el
gestor de bases de datos realiza automticamente una recuperacin de error
para restaurar los datos al estado en que estaban antes de que comenzara la
transaccin. Si se produce un error del programa, el gestor de bases de datos
restaura todos los cambios realizados por la sentencia que ha ocasionado el
error. El gestor de bases de datos no deshar el trabajo realizado en la
transaccin antes de la ejecucin de la sentencia errnea, a no ser que la
retrotraiga de forma especfica.
Procedimiento:
Para evitar que los cambios afectados por la transaccin se confirmen en la
base de datos, emita la sentencia ROLLBACK para finalizar la transaccin. La
sentencia ROLLBACK devuelve la base de datos al estado en que estaba antes
de que se ejecutara la transaccin.
Nota: en sistemas operativos Windows, si no confirma de forma explcita una
transaccin, el gestor de bases de datos siempre retrotrae los cambios.
Si utiliza la sentencia ROLLBACK en una rutina en la que se entr debido a
un error o aviso y utiliza la sentencia de SQL WHENEVER, debe especificar
WHENEVER SQLERROR CONTINUE y WHENEVER SQLWARNING
CONTINUE antes de ROLLBACK. Esto evita un bucle del programa si la
sentencia ROLLBACK falla con un error o aviso.
En el caso de un error grave, recibir un mensaje que indicar que no puede
emitir una sentencia ROLLBACK. No emita una sentencia ROLLBACK si se
produce un error grave, como una prdida de comunicaciones entre las
aplicaciones cliente y servidor o si la base de datos resulta daada. Despus
de un error grave, la nica sentencia que puede emitir es una sentencia
CONNECT.
La sentencia ROLLBACK no tiene ningn efecto sobre el contenido de las
Puede codificar una o ms transacciones dentro de un solo programa de
aplicacin, y se puede acceder a ms de una base de datos desde una sola
transaccin. Una transaccin que accede a ms de una base de datos se
denomina actualizacin mltiple.
la pgina 48
v Unidad de trabajo remota en la pgina 461
v Actualizacin mltiple en la pgina 461
v WHENEVER sentencia en el manual Consulta de SQL, Volumen 2
Finalizacin de un programa de aplicacin
Finalice un programa de aplicacin para liberar los recursos que utilizaba el
programa.
Procedimiento:
Para finalizar correctamente el programa:
1. Finalice la transaccin actual (si se est procesando alguna) emitiendo de
forma explcita una sentencia COMMIT o ROLLBACK.
2. Libere la conexin con el servidor de bases de datos utilizando la sentencia
CONNECT RESET.
3. Libere los recursos utilizados por el programa. Por ejemplo, libere el
almacenamiento temporal o las estructuras de datos utilizadas.
Nota: si la transaccin actual sigue activa cuando termina el programa, DB2
finaliza de forma explcita la transaccin. Puesto que el comportamiento
de DB2 cuando finaliza de forma implcita una transaccin depende de
cada plataforma, debe finalizar de forma explcita todas las
transacciones emitiendo una sentencia COMMIT o ROLLBACK antes
de que termine el programa.
la pgina 48
Finalizacin implcita de una transaccin en una aplicacin autnoma
Si el programa termina sin finalizar la transaccin actual, DB2 termina de
forma implcita la transaccin actual. DB2 termina de forma implcita la
transaccin actual emitiendo una sentencia COMMIT o ROLLBACK y luego la
aplicacin finaliza. Si la emisin de una sentencia COMMIT o ROLLBACK por
parte de DB2 depende de factores como los siguientes:
v Si la aplicacin ha terminado normalmente
En la mayora de los sistemas operativos soportados, DB2 confirma de
forma implcita una transaccin si la terminacin es normal o retrotrae de
forma implcita la transaccin si la terminacin es anmala. Tenga en cuenta
que lo que el programa considera una terminacin anmala puede no ser
considerado como tal por el gestor de bases de datos. Por ejemplo, puede
codificar exit(-16) cuando la aplicacin encuentre un error inesperado y
terminar la aplicacin de inmediato. El gestor de bases de datos considera
que esto es una terminacin normal y confirma la transaccin. El gestor de
bases de datos considera elementos tales como una excepcin o una
infraccin de segmentacin como terminaciones anmalas.
v La plataforma en la que se ejecuta el servidor DB2
En sistemas operativos Windows de 32 bits, DB2 siempre retrotrae la
transaccin, independientemente de si la aplicacin termina de forma
normal o anmala. Si desea que la transaccin se confirme, debe emitir la
sentencia COMMIT de forma explcita.
v Si la aplicacin utiliza las API de contexto de DB2 para el acceso a bases de
datos de varias hebras
Si la aplicacin las utiliza, DB2 retrotrae de forma implcita la transaccin
tanto si la aplicacin termina de forma normal como si lo hace de forma
anmala. A no ser que confirme de forma explcita la transaccin utilizando
la sentencia COMMIT, DB2 retrotrae la transaccin.
v Objetivo del acceso a base de datos de varias hebras en la pgina 227
v COMMIT sentencia en el manual Consulta de SQL, Volumen 2
v ROLLBACK sentencia en el manual Consulta de SQL, Volumen 2
Infraestructura de seudocdigo de aplicacin
El siguiente ejemplo resume la infraestructura general correspondiente a un
programa de aplicacin de DB2 en formato de seudocdigo. Por supuesto,
debe adaptar esta infraestructura para que se ajuste a su propio programa.
Iniciar programa
EXEC SQL BEGIN DECLARE SECTION |
DECLARE USERID FIXED CHARACTER (8) |
DECLARE PW FIXED CHARACTER (8) |
| Configuracin
(otras declaraciones de variables del lenguaje principal) | de aplicacin
|
EXEC SQL END DECLARE SECTION |
EXEC SQL INCLUDE SQLCA |
EXEC SQL WHENEVER SQLERROR GOTO ERRCHK |
(lgica de programa)
EXEC SQL CONNECT TO base_de_datos A USER :id_usuario USING :pw |
EXEC SQL SELECT ... |
EXEC SQL INSERT ... | Primera unidad
(ms sentencias de SQL) | de trabajo
EXEC SQL COMMIT |
(ms lgica de programa)
EXEC SQL CONNECT TO base_de_datos B USER :id_usuario USING :pw |
EXEC SQL DELETE ... | Segunda unidad
EXEC SQL COMMIT |
EXEC SQL CONNECT TO base_de_datos A |
EXEC SQL DELETE ... | Tercera unidad
EXEC SQL COMMIT |
EXEC SQL CONNECT RESET |
ERRCHK |
| Limpieza de
(comprobar informacin de error en SQLCA) | aplicacin
|
Finalizar programa
v Programacin de una aplicacin autnoma en la pgina 33
Recursos para crear prototipos de sentencias de SQL
A medida que disea y codifica la aplicacin, puede aprovechar determinadas
funciones y programas de utilidad del gestor de bases de datos para crear
prototipos de partes del cdigo SQL y para mejorar el rendimiento. Por
ejemplo, puede hacer lo siguiente:
v Utilizar el Centro de control o el procesador de lnea de mandatos (CLP)
para probar muchas sentencias de SQL antes de intentar compilar y enlazar
un programa completo.
Esto le permite definir y manipular informacin almacenada en una tabla
de base de datos, ndice o vista. Puede aadir, suprimir o actualizar
informacin, as como generar informes a partir del contenido de las tablas.
Observe que tiene que modificar mnimamente la sintaxis de algunas
sentencias de SQL para utilizar variables del lenguaje principal en el
programa de SQL incorporado. Las variables del lenguaje principal se
utilizan para almacenar datos que representan salida en la pantalla.
Adems, algunas sentencias de SQL incorporado (como BEGIN DECLARE
SECTION) no reciben soporte del Centro de mandatos ni de CLP puesto
que no resultan relevantes para dicho entorno.
Tambin puede redirigir la entrada y la salida de las peticiones del
procesador de lnea de mandatos. Por ejemplo, podra crear uno o ms
archivos que contengan sentencias de SQL que necesita como entrada en
una peticin del procesador de lnea de mandatos para no tener que volver
a escribir la sentencia.
v Utilizar el recurso Explain para obtener una idea de los costes estimados de
las sentencias DELETE, INSERT, UPDATE o SELECT que tiene intencin de
utilizar en el programa. El recurso Explain coloca la informacin sobre la
estructura y los costes estimados de la sentencia en cuestin en tablas
suministradas por el usuario. Puede ver esta informacin utilizando Visual
Explain o el programa de utilidad db2exfmt.
v Utilizar las vistas del catlogo del sistema para recuperar fcilmente
informacin sobre las bases de datos existentes. El gestor de bases de datos
crea y mantiene las tablas del catlogo del sistema en las que se basan las
vistas durante el funcionamiento normal a medida que las bases de datos se
crean, modifican y actualizan. Estas vistas contienen datos sobre cada base
de datos, que incluyen autorizaciones otorgadas, nombres de columna, tipos
de datos, ndices, dependencias de paquetes, restricciones referenciales,
nombres de tabla, vistas, etc. Los datos de las vistas del catlogo del
sistema estn disponibles a travs de los recursos de consulta normales de
SQL.
Puede actualizar algunas vistas del catlogo del sistema que contienen
informacin estadstica que utiliza el optimizador de SQL. Puede cambiar
algunas columnas de estas vistas para que afecten al optimizador o para
investigar el rendimiento de bases de datos hipotticas. Puede utilizar este
mtodo para simular un sistema de produccin en su sistema de desarrollo
o prueba y analizar el comportamiento de las consultas.
v Vistas de catlogo en el manual Consulta de SQL, Volumen 1
v Catalog statistics tables en el manual Administration Guide: Performance
v Catalog statistics for modeling and what-if planning en el manual
Administration Guide: Performance
v General rules for updating catalog statistics manually en el manual
v SQL explain facility en el manual Administration Guide: Performance
v Herramientas de DB2 Universal Database para desarrollar aplicaciones en
la pgina 5
v Apndice A, Sentencias de SQL soportadas en la pgina 521
API administrativas en SQL incorporado o en programas de CLI de DB2
La aplicacin puede utilizar API para acceder a las funciones del gestor de
bases de datos que no estn disponibles utilizando sentencias de SQL.
Puede utilizar las API de DB2 para:
v Manipular el entorno del gestor de bases de datos, que incluye la
catalogacin y descatalogacin de bases de datos y nodos y la exploracin
de directorios de bases de datos y de nodos. Tambin puede utilizar API
para crear, suprimir y migrar bases de datos.
v Proporcionar recursos para importar y exportar datos y administrar, hacer
copia de seguridad y restaurar la base de datos.
v Modificar los valores de parmetros de configuracin del gestor de bases de
datos y de la base de datos.
v Proporcionar operaciones especficas del entorno cliente/servidor.
v Proporcionar la interfaz en tiempo de ejecucin para sentencias de SQL
precompiladas. El desarrollador no suele llamar directamente a estas API.
En su lugar, el precompilador las inserta en el archivo fuente modificado
despus del proceso.
El gestor de bases de datos incluye API para proveedores de lenguajes que
desean escribir su propio precompilador y otras API tiles para desarrollar
aplicaciones.
v Programas de ejemplo: estructura y diseo en el manual Gua de desarrollo
Definicin de FIPS 127-2 e ISO/ANS SQL92
FIPS 127-2 hace referencia a Federal Information Processing Standards Publication
127-2 for Database Language SQL. ISO/ANS SQL92 hace referencia a American
National Standard Database Language SQL X3.135-1992 e International Standard
ISO/IEC 9075:1992, Database Language SQL.
Control de valores de datos y relaciones
Las secciones siguientes describen cmo controlar valores de datos y
relaciones entre los datos.
Control de valores de datos
Un rea tradicional de la lgica de aplicacin es validar y proteger la
integridad de los datos, controlando los valores permitidos en la base de
datos. Las aplicaciones tienen lgica que comprueba de forma especfica la
validez de los valores de datos a medida que se entran. Por ejemplo,
comprobacin de que el nmero de departamento es un nmero vlido y de
que hace referencia a un departamento existente. Hay varias formas de
proporcionar estas mismas funciones en DB2, pero desde dentro de la base de
datos.
v Control de valores de datos mediante tipos de datos en la pgina 53
v Control de valores de datos mediante restricciones exclusivas en la
pgina 53
v Control de valores de datos mediante restricciones de comprobacin de
tabla en la pgina 54
v Control de valores de datos mediante restricciones de integridad
referencial en la pgina 54
v Control de valores de datos mediante vistas con la opcin Check en la
pgina 55
v Control de valores de datos mediante lgica de aplicacin y tipos de
variables de programa en la pgina 55
Control de valores de datos mediante tipos de datos
La base de datos almacena cada elemento de datos en una columna de una
tabla y define cada columna con un tipo de datos. Este tipo de datos establece
ciertos lmites en los tipos de valores para la columna. Por ejemplo, un entero
debe ser un nmero comprendido dentro de un rango fijo. El uso de la
columna en sentencias de SQL debe cumplir con determinados
comportamientos; por ejemplo, la base de datos no compara un entero con
una serie de caracteres. DB2 incluye un grupo de tipos de datos integrados
con caractersticas y comportamientos definidos. DB2 tambin da soporte a la
definicin de sus propios datos, denominados tipos diferenciados definidos por el
usuario, que se basan en los tipos integrados pero no dan soporte
automticamente a todos los comportamientos del tipo integrado. Tambin
puede utilizar tipos de datos, como objeto grande binario (BLOB), para
almacenar datos que pueden consistir en un grupo de valores relacionados,
como una estructura de datos.
v Tipos diferenciados definidos por el usuario en el manual Gua de
Control de valores de datos mediante restricciones exclusivas
Las restricciones exclusivas evitan la presencia de valores duplicados en una o
ms columnas dentro de una tabla. Las claves exclusivas y primarias son las
restricciones exclusivas soportadas. Por ejemplo, puede definir una restriccin
exclusiva en la columna DEPTNO de la tabla DEPARTMENT para asegurar
que no se asigna el mismo nmero de departamento a dos departamentos.
Utilice restricciones exclusivas si necesita aplicar la norma de exclusividad
para todas las aplicaciones que utilizan los datos de una tabla.
v Defining a unique constraint en el manual Administration Guide:
Implementation
v Adding a unique constraint en el manual Administration Guide:
Implementation
Control de valores de datos mediante restricciones de comprobacin de
tabla
Puede utilizar una restriccin de comprobacin de tabla para definir
restricciones, adems de las del tipo de datos, sobre los valores permitidos
para una columna de una tabla. Las restricciones de comprobacin de tabla
adoptan la forma de comprobaciones de rango o comparaciones con otros
valores de la misma fila de la misma tabla.
Si la norma se aplica a todas las aplicaciones que utilizan los datos, utilice una
restriccin de comprobacin de tabla para aplicar la restriccin sobre los datos
permitidos en la tabla. Las restricciones de comprobacin de tabla hacen que
la restriccin se aplique de forma general y sea ms fcil de mantener.
v Defining a table check constraint en el manual Administration Guide:
Implementation
v Adding a table check constraint en el manual Administration Guide:
Implementation
Control de valores de datos mediante restricciones de integridad
referencial
Utilice las restricciones de integridad referencial (RI) si debe mantener
relaciones basadas en valores para todas las aplicaciones que utilizan los
datos. Por ejemplo, puede utilizar una restriccin RI para asegurar que el
valor de una columna DEPTNO de una tabla EMPLOYEE coincide con un
valor de la tabla DEPARTMENT. Esta restriccin evita inserciones,
actualizaciones o supresiones que daran lugar a la prdida de informacin de
DEPARTMENT. Al centralizar las normas en la base de datos, las restricciones
RI hacen que las normas se apliquen de forma general y sean ms fciles de
mantener.
v Restricciones en el manual Consulta de SQL, Volumen 1
v Control de relaciones de datos mediante restricciones de integridad
v Diferencias en la integridad referencial entre sistemas de bases de datos
relacionales de IBM en la pgina 535
Control de valores de datos mediante vistas con la opcin Check
Si la aplicacin no puede definir las normas deseadas como restricciones de
comprobacin de tabla, o si las normas no se aplican a todos los usos de los
datos, hay otra alternativa a colocar las normas en la lgica de la aplicacin.
Puede considerar la posibilidad de crear una vista de la tabla con las
condiciones sobre los datos como parte de la clusula WHERE y la clusula
WITH CHECK OPTION especificada. Esta definicin de vista restringe la
recuperacin de datos al conjunto que es vlido para su aplicacin. Adems, si
puede actualizar la vista, la clusula WITH CHECK OPTION restringe
actualizaciones, inserciones y supresiones en las filas que se aplican a su
aplicacin.
v CREATE VIEW sentencia en el manual Consulta de SQL, Volumen 2
Control de valores de datos mediante lgica de aplicacin y tipos de
variables de programa
Cuando escribe su lgica de aplicacin en un lenguaje de programacin,
tambin declara variables para proporcionar algunas de las mismas
restricciones sobre los datos que se han descrito en otros temas sobre control
de valores de datos. Adems, puede escribir cdigo que haga cumplir normas
en la aplicacin en lugar de en la base de datos. Coloque la lgica en el
servidor de aplicaciones cuando:
v Las normas no se apliquen de forma general, excepto en el caso de vistas
que utilizan la opcin WITH CHECK OPTION
v No tenga control sobre las definiciones de los datos en la base de datos
v Crea que la norma puede ser ms eficiente si se maneja en la lgica de
aplicacin
Por ejemplo, es posible que se tengan que procesar errores en los datos de
entrada en el orden en que se entran, pero no se puede garantizar el orden de
las operaciones dentro de la base de datos.
v Control de valores de datos mediante vistas con la opcin Check en la
pgina 55
Control de relaciones de datos
Una de las principales reas de inters de la lgica de aplicacin es la gestin
de las relaciones entre las distintas entidades lgicas del sistema. Por ejemplo,
si aade un nuevo departamento, tiene que crear un nuevo cdigo de cuenta.
DB2 proporciona dos mtodos para gestionar las relaciones entre distintos
objetos en la base de datos: restricciones de integridad referencial y
activadores.
v Control de relaciones de datos mediante restricciones de integridad
v Control de relaciones de datos mediante activadores en la pgina 57
v Control de relaciones de datos mediante activadores anteriores en la
pgina 57
v Control de relaciones de datos mediante activadores posteriores en la
pgina 58
v Control de relaciones de datos mediante lgica de aplicacin en la pgina
58
Control de relaciones de datos mediante restricciones de integridad
referencial
Las restricciones de integridad referencial (RI), consideradas desde la
perspectiva del control de relaciones de datos, le permiten controlar las
relaciones entre datos en ms de una tabla. Utilice las sentencias CREATE
TABLE o ALTER TABLE para definir el comportamiento de operaciones que
afectan a la clave primaria relacionada, como DELETE y UPDATE.
Las restricciones RI hacen cumplir las normas sobre los datos en una o ms
tablas. Si las normas se aplican para todas las aplicaciones que utilizan los
datos, las restricciones RI centralizan las normas en la base de datos. Esto
hace que las normas se apliquen de forma general y sean ms fciles de
mantener.
v Restricciones en el manual Consulta de SQL, Volumen 1
v Defining referential constraints en el manual Administration Guide:
Implementation
v ALTER TABLE sentencia en el manual Consulta de SQL, Volumen 2
v CREATE TABLE sentencia en el manual Consulta de SQL, Volumen 2
Control de relaciones de datos mediante activadores
Puede utilizar activadores antes o despus de una actualizacin para dar
soporte a la lgica que tambin se puede llevar a cabo en una aplicacin. Si
las normas u operaciones que soportan los activadores se aplican a todas las
aplicaciones que utilizan los datos, los activadores centralizan las normas u
operaciones en la base de datos, lo que hace que estn disponibles de forma
general y sean ms fciles de mantener.
pgina 57
pgina 58
v Creating a trigger en el manual Administration Guide: Implementation
v Creacin de activadores en el manual Gua de desarrollo de aplicaciones:
v CREATE TRIGGER sentencia en el manual Consulta de SQL, Volumen 2
Control de relaciones de datos mediante activadores anteriores
Si se utilizan activadores que se ejecutan antes de una actualizacin o
insercin, los valores que se estn actualizando o insertando se pueden
modificar antes de que la base de datos se modifique realmente. Estos se
pueden utilizar para transformar entrada procedente de la aplicacin (vista de
usuario de los datos) en un formato de base de datos interno, si se desea.
Estos activadores anteriores tambin se pueden utilizar para hacer que se
activen otras operaciones que no son de base de datos a travs de funciones
definidas por el usuario.
pgina 58
Control de relaciones de datos mediante activadores posteriores
Los activadores que se ejecutan despus de una actualizacin, insercin o
supresin se pueden utilizar de varias formas:
v Los activadores pueden actualizar, insertar o suprimir datos en la misma
tabla o en otras tablas. Esto resulta til para mantener relaciones entre datos
o para mantener informacin de seguimiento de auditora.
v Los activadores pueden comparar datos con valores de datos en el resto de
la tabla o en otras tablas. Esto resulta til cuando no puede utilizar
restricciones RI ni restricciones de comprobacin debido a las referencias a
datos desde otras filas de esta o de otras tablas.
v Los activadores pueden utilizar funciones definidas por el usuario para
activar operaciones que no son de base de datos. Esto resulta til, por
ejemplo, para emitir alertas o actualizar informacin fuera de la base de
datos.
pgina 57
Control de relaciones de datos mediante lgica de aplicacin
Es posible que decida escribir cdigo para aplicar normas o realizar
operaciones relacionadas en la aplicacin en lugar de en la base de datos.
Debe hacerlo en los casos en los que no puede aplicar de forma general las
normas a la base de datos. Tambin puede elegir el hecho de colocar la lgica
en la aplicacin si no tiene control sobre las definiciones de los datos de la
base de datos o si cree que la lgica de aplicacin puede manejar las normas
u operaciones de forma ms eficiente.
v Lgica de aplicacin en el servidor en la pgina 59
Lgica de aplicacin en el servidor
Un ltimo aspecto del diseo de aplicaciones para el que DB2 ofrece
funciones adicionales es la ejecucin de parte de la lgica de aplicacin en el
servidor de base de datos. Generalmente, elegir este diseo para mejorar el
rendimiento, pero tambin puede ejecutar lgica de aplicacin en el servidor
para dar soporte a funciones comunes.
Puede utilizar lo siguiente:
Un procedimiento almacenado es una rutina para la aplicacin a la que se
llama desde la lgica de aplicacin cliente, pero se ejecuta en el servidor de
base de datos. La razn ms comn para utilizar un procedimiento
almacenado es para el proceso intensivo de bases de datos que slo genera
una pequea cantidad de datos de resultados. Esto puede ahorrar una gran
cantidad de comunicaciones a travs de la red durante la ejecucin del
procedimiento almacenado. Tambin puede considerar la posibilidad de
utilizar un procedimiento almacenado para un conjunto de operaciones que
son comunes para varias aplicaciones. De este modo, todas las aplicaciones
utilizan la misma lgica para llevar a cabo la operacin.
v Funciones definidas por el usuario
Puede escribir una funcin definida por el usuario (UDF) para utilizarla
para llevar a cabo operaciones dentro de una sentencia de SQL para que
devuelva:
Un solo valor escalar (funcin escalar)
Una tabla procedente de una fuente de datos que no sea DB2, por
ejemplo un archivo ASCII o una pgina Web (funcin de tabla)
Las UDF resultan tiles para tareas como transformar valores de datos,
realizar clculos sobre uno o ms valores de datos o extraer partes de un
valor (como extraer partes de un objeto grande).
v activadores
Se pueden utilizar activadores para invocar funciones definidas por el
usuario. Esto resulta til si desea que siempre se lleve a cabo una
determinada operacin no SQL cuando se produzcan determinadas
sentencias o se cambien valores de datos. Ejemplos tales son operaciones
como emitir un mensaje de correo electrnico bajo circunstancias especficas
o grabar informacin de tipo de alerta en un archivo.
pgina 57
pgina 58
v Guidelines for stored procedures en el manual Administration Guide:
Performance
v Interacciones de los activadores con las restricciones referenciales en el
manual Gua de desarrollo de aplicaciones: Programacin de aplicaciones de
servidor
Consideraciones sobre autorizacin para SQL y API
Las secciones siguientes describen las consideraciones generales sobre
autorizacin para SQL incorporado y las consideraciones sobre autorizacin
para SQL esttico y dinmico y para las API.
Consideraciones sobre autorizacin para SQL incorporado
Una autorizacin permite a un usuario o grupo llevar a cabo una tarea general
como conectarse a una base de datos, crear tablas o administrar un sistema.
Un privilegio otorga a un usuario o grupo el derecho a acceder a un objeto de
base de datos especfico de una forma especificada. DB2 utiliza un grupo de
privilegios para proteger la informacin que almacena en el mismo.
La mayora de las sentencias de SQL necesitan algn tipo de privilegio sobre
los objetos de base de datos que utiliza la sentencia. La mayora de llamadas a
API no suelen necesitar ningn privilegio sobre los objetos de base de datos
que utiliza la llamada, aunque muchas API necesitan que el usuario tenga la
autorizacin necesaria para invocarlas. Las API de DB2 le permiten realizar
funciones administrativas de DB2 desde dentro del programa de aplicacin.
Por ejemplo, para recrear un paquete almacenado en la base de datos sin
necesidad de disponer de un archivo de vinculacin, puede utilizar la API
sqlarbnd (o REBIND).
Cuando disee la aplicacin, tenga en cuenta los privilegios que necesitarn
los usuarios para ejecutar la aplicacin. Los privilegios que necesitan los
usuarios dependen de:
v Si la aplicacin utiliza SQL dinmico, incluidos JDBC y CLI de DB2, o SQL
esttico. Para obtener informacin sobre los privilegios necesarios para
emitir una sentencia, consulte la descripcin de dicha sentencia.
v Qu API utiliza la aplicacin. Para obtener informacin sobre las
autorizaciones y los privilegios necesarios para una llamada a API, consulte
la descripcin de dicha API.
Supongamos que tenemos dos usuarios, PAYROLL y BUDGET, que tienen que
realizar consultas contra la tabla STAFF. PAYROLL es responsable de pagar a
los empleados de la empresa, de modo que tiene que emitir varias sentencias
SELECT al emitir cheques. PAYROLL tiene que poder acceder al salario de
cada empleado. BUDGET es responsable de determinar la cantidad de dinero
necesaria para pagar los salarios. Sin embargo, BUDGET no debera poder ver
el salario de ningn empleado en particular.
Puesto que PAYROLL emite muchas sentencias SELECT diferentes, la
aplicacin que disee para PAYROLL probablemente podra utilizar de forma
eficiente cdigo SQL dinmico. El cdigo SQL dinmico necesitara que
PAYROLL tuviera el privilegio SELECT sobre la tabla STAFF. Este requisito no
representa un problema porque PAYROLL necesita acceso completo a la tabla.
Por otro lado, BUDGET no debera tener acceso al salario de cada empleado.
Esto significa que no debe otorgar el privilegio SELECT sobre la tabla STAFF
a BUDGET. Puesto que BUDGET necesita acceso al total de todos los salarios
de la tabla STAFF, podra crear una aplicacin de SQL esttico para ejecutar
una sentencia SELECT SUM(SALARY) FROM STAFF, vincular la aplicacin y
otorgar el privilegio EXECUTE sobre el paquete de la aplicacin a BUDGET.
Esto permite a BUDGET obtener la informacin necesaria sin exponer la
informacin que BUDGET no debera ver.
v Consideraciones sobre autorizacin para SQL dinmico en la pgina 61
v Consideraciones sobre autorizacin para SQL esttico en la pgina 63
v Authorization en el manual Administration Guide: Planning
Consideraciones sobre autorizacin para SQL dinmico
Para utilizar SQL dinmico en un paquete vinculado con DYNAMICRULES
RUN (valor por omisin), la persona que ejecuta una aplicacin de SQL
dinmico debe tener los privilegios necesarios para emitir cada peticin de
SQL realizada, as como el privilegio EXECUTE sobre el paquete. Los
privilegios se pueden otorgar al ID de autorizacin del usuario, a cualquier
grupo del que el usuario sea miembro o a PUBLIC.
Si vincula la aplicacin con la opcin DYNAMICRULES BIND, DB2 asocia el
ID de autorizacin con los paquetes de la aplicacin. Esto permite que
cualquier usuario que ejecute la aplicacin herede los privilegios asociados
con su ID de autorizacin.
Si el programa no contiene SQL esttico, la persona que vincula la aplicacin
(para aplicaciones de SQL dinmico incorporado) slo necesita la autorizacin
BINDADD sobre la base de datos. De nuevo, este privilegio se puede otorgar
al ID de autorizacin del usuario, a un grupo del que el usuario sea miembro
o a PUBLIC.
Cuando un programa muestra un comportamiento de vinculacin o de
definicin, el usuario que ejecuta la aplicacin slo necesita el privilegio
EXECUTE sobre el paquete para poderlo ejecutar. En el momento de la
ejecucin, el vinculador de un paquete que muestra un comportamiento de
vinculacin debe tener los privilegios necesarios para ejecutar todas las
sentencias dinmicas generadas por el paquete, puesto que toda la
comprobacin de autorizaciones para sentencias dinmicas se lleva a cabo
utilizando el ID del vinculador y no el de los ejecutores. Paralelamente, el que
define una rutina cuyos paquetes muestran comportamiento de definicin
deben tener todos los privilegios necesarios para ejecutar todas las sentencias
dinmicas generadas por el paquete con comportamiento de definicin. Si
tiene autorizacin SYSADM o DBADM y crea un paquete con
comportamiento de vinculacin, considere la posibilidad de utilizar la opcin
OWNER BIND para designar un ID de autorizacin diferente. La opcin
OWNER BIND evita que un paquete herede automticamente los privilegios
SYSADM o DBADM dentro de sentencias de SQL dinmico. Para obtener ms
informacin sobre las opciones de vinculacin DYNAMICRULES y OWNER,
consulte el mandato BIND. Para obtener ms informacin sobre
comportamientos de paquetes, consulte la descripcin de los efectos de
DYNAMICRULES en sentencias de SQL dinmico.
v Consideraciones sobre autorizacin para SQL incorporado en la pgina 60
v Efectos de DYNAMICRULES en SQL dinmico en la pgina 147
v Mandato BIND en el manual Consulta de mandatos
Consideraciones sobre autorizacin para SQL esttico
Para utilizar SQL esttico, el usuario que ejecuta la aplicacin slo necesita el
privilegio EXECUTE sobre el paquete. No se necesitan privilegios para cada
una de las sentencias que forman el paquete. El privilegio EXECUTE se puede
otorgar al ID de autorizacin del usuario, a cualquier grupo del que el usuario
sea miembro o a PUBLIC.
A no ser que especifique la opcin VALIDATE RUN cuando vincule la
aplicacin, el ID de autorizacin que utilice para vincular la aplicacin debe
tener los privilegios necesarios para llevar a cabo todas las sentencias de la
aplicacin. Si se especific VALIDATE RUN en el momento de la vinculacin
(BIND), todos los errores de autorizacin correspondientes a cualquier SQL
esttico dentro de este paquete no harn que la operacin BIND falle y dichas
sentencias se volvern a validar en el momento de la ejecucin. La persona
que vincula la aplicacin siempre debe tener autorizacin BINDADD. Los
privilegios necesarios para ejecutar las sentencias se deben otorgar al ID de
autorizacin del usuario o a PUBLIC. No se utilizan privilegios de grupo
cuando se vinculan sentencias de SQL esttico. Al igual que sucede con SQL
dinmico, el privilegio BINDADD se puede otorgar al ID de autorizacin del
usuario, a un grupo del que el usuario sea miembro o a PUBLIC.
Estas propiedades de SQL esttico le proporcionan control preciso sobre el
acceso a informacin en DB2.
Consideraciones sobre autorizacin para API
La mayora de las API que proporciona DB2 no necesitan el uso de
privilegios, aunque muchas necesitan algn tipo de autorizacin para
invocarlas. Para las API que necesitan privilegio, ste se debe otorgar al
usuario que ejecuta la aplicacin. El privilegio se puede otorgar al ID de
autorizacin del usuario, a cualquier grupo del que el usuario sea miembro o
a PUBLIC. Para obtener informacin sobre el privilegio y autorizacin
necesarios para emitir cada llamada de API, consulte la descripcin de la API.
Se puede acceder a algunas API a travs de una interfaz de procedimiento
almacenado. Para obtener informacin sobre si se puede acceder a una API
especfica a travs de un procedimiento almacenado, consulte la descripcin
de dicha API.
Prueba de la aplicacin
Las secciones siguientes describen cmo configurar un entorno de prueba y
cmo depurar y optimizar la aplicacin.
Configuracin del entorno de prueba para una aplicacin
Las secciones siguientes describen cmo configurar el entorno de prueba para
la aplicacin.
Configuracin de un entorno de prueba
Para validar la aplicacin, debe configurar un entorno de prueba. Por ejemplo,
necesita una base de datos para probar el cdigo SQL de la aplicacin.
Procedimiento:
Para configurar el entorno de prueba, siga los siguientes pasos:
1. Cree una base de datos de prueba.
Para crear una base de datos de prueba, escriba una pequea aplicacin de
servidor que llame a la API CREATE DATABASE o utilice el procesador
de lnea de mandatos.
2. Cree tablas y vistas de prueba.
Si la aplicacin actualiza, inserta o suprime datos de tablas y vistas, utilice
datos de prueba para verificar su ejecucin. Si la aplicacin slo recupera
datos de tablas y vistas, considere la posibilidad de utilizar datos de nivel
de produccin cuando la pruebe.
3. Genere datos de prueba para las tablas.
Los datos de entrada que se utilizan para probar una aplicacin deben ser
datos vlidos que representen todas las posibles condiciones de entrada. Si
la aplicacin verifica que los datos de entrada son vlidos, incluya datos
vlidos y no vlidos para verificar que los datos vlidos se procesan y los
datos no vlidos se marcan.
4. Depure y optimice la aplicacin.
v Creacin de tablas y vistas de prueba en la pgina 65
v Generacin de datos de prueba en la pgina 66
v Depuracin y optimizacin de una aplicacin en la pgina 68
v sqlecrea - Create Database en el manual Administrative API Reference
v Mandato CREATE DATABASE en el manual Consulta de mandatos
Creacin de tablas y vistas de prueba
Para disear las tablas de prueba y vistas necesarias, primero analice los
requisitos de datos de la aplicacin. Para crear una tabla, necesita la
autorizacin CREATETAB y el privilegio CREATEIN sobre el esquema.
Consulte la sentencia CREATE TABLE para ver autorizaciones alternativas.
Procedimiento:
Para crear tablas de prueba:
1. Liste los datos a los que accede la aplicacin y describa el modo en que se
accede a cada elemento de datos. Por ejemplo, supongamos que la
aplicacin que se est desarrollando accede a las tablas TEST.TEMPL,
TEST.TDEPT y TEST.TPROJ. Podra registrar el tipo de accesos, tal como
se muestra en la siguiente tabla.
Tabla 1. Descripcin de los datos de la aplicacin
Nombre de tabla
o vista
Insertar
filas
Suprimir
filas
Nombre
columna
Tipo de datos Acceso
de
actualizacin
TEST.TEMPL No No EMPNO
LASTNAME
WORKDEPT
PHONENO
JOBCODE
CHAR(6)
VARCHAR(15)
CHAR(3)
CHAR(4)
DECIMAL(3)
S
S
S
TEST.TDEPT No No DEPTNO
MGRNO
CHAR(3)
CHAR(6)
TEST.TPROJ S S PROJNO
DEPTNO
RESPEMP
PRSTAFF
PRSTDATE
PRENDATE
CHAR(6)
CHAR(3)
CHAR(6)
DECIMAL(5,2)
DECIMAL(6)
DECIMAL(6)
S
S
S
S
S
2. Cuando la descripcin del acceso a datos de la aplicacin est completa,
construya las tablas y vistas de prueba necesarias para probar la
aplicacin:
v Cree una tabla de prueba cuando la aplicacin modifique datos en una
tabla o vista. Cree las siguientes tablas de prueba utilizando la sentencia
de SQL CREATE TABLE:
TEMPL
TPROJ
v Cree una vista de prueba cuando la aplicacin no modifique datos en la
base de datos de produccin.
En este ejemplo, cree una vista de prueba de la tabla TDEPT utilizando
la sentencia de SQL CREATE VIEW.
3. Genere datos de prueba para las tablas.
Si el esquema de base de datos se est desarrollando junto con la aplicacin,
las definiciones de las tablas de prueba se pueden definir con ms precisin
repetidamente durante el proceso de desarrollo. Generalmente, la aplicacin
primaria no puede crear las tablas y acceder a las mismas porque el gestor de
bases de datos no puede vincular sentencias que hacen referencia a tablas y
vistas que no existen. Para que el proceso de creacin y cambio de tablas no le
lleve tanto tiempo, considere la posibilidad de desarrollar una aplicacin
separada para crear las tablas. Tambin puede crear tablas de prueba de forma
interactiva mediante el procesador de lnea de mandatos (CLP).
Una vez finalizado el procedimiento, debe crear los temas relacionados para
esta tarea.
v Generacin de datos de prueba en la pgina 66
Generacin de datos de prueba
Despus de crear las tablas de prueba, puede llenarlas con datos de prueba
para verificar el comportamiento de manejo de datos de la aplicacin.
Procedimiento:
Utilice cualquiera de los siguientes mtodos para insertar datos en una tabla:
v INSERT...VALUES (una sentencia de SQL) coloca una o ms filas en una
tabla cada vez que se emite el mandato.
v INSERT...SELECT obtiene datos de una tabla existente (basada en una
clusula SELECT) y los coloca en la tabla identificada con la sentencia
INSERT.
v El programa de utilidad IMPORT o LOAD inserta gran cantidad de datos
nuevos o existentes procedentes de una fuente definida.
v El programa de utilidad RESTORE se puede utilizar para duplicar el
contenido de una base de datos existente en una base de datos de prueba
idntica utilizando una copia de seguridad (BACKUP) de la base de datos
original.
v El programa de utilidad DB2MOVE mueve un gran nmero de tablas entre
bases de datos DB2 situadas en estaciones de trabajo.
Las siguientes sentencias de SQL muestran una tcnica que puede utilizar
para llenar tablas con datos de prueba generados de forma aleatoria.
Supongamos que la tabla EMP contiene cuatro columnas, ENO (nmero de
empleado), LASTNAME (apellido), HIREDATE (fecha de contratacin) y
SALARY (salario del empleado) tal como se muestra en la siguiente sentencia
CREATE TABLE:
CREATE TABLE EMP (ENO INTEGER, LASTNAME VARCHAR(30),
HIREDATE DATE, SALARY INTEGER);
Supongamos que desea llenar esta tabla con nmeros de empleado, desde 1 a
un nmero, por ejemplo 100, con datos aleatorios para el resto de las
columnas. Puede hacerlo utilizando la siguiente sentencia de SQL:
INSERT INTO EMP
-- generar 100 registros
WITH DT(ENO) AS (VALUES(1) UNION ALL
SELECT ENO+1 FROM DT WHERE ENO < 100 ) 1
-- Ahora utilizar los registros generados en DT para crear otras columnas
-- del registro de empleado.
SELECT ENO, 2
TRANSLATE(CHAR(INTEGER(RAND()*1000000)), 3
CASE MOD(ENO,4) WHEN 0 THEN aeiou || bcdfg
WHEN 1 THEN aeiou || hjklm
WHEN 2 THEN aeiou || npqrs
ELSE aeiou || twxyz END,
1234567890) AS LASTNAME,
CURRENT DATE - (RAND()*10957) DAYS AS HIREDATE, 4
INTEGER(10000+RAND()*200000) AS SALARY 5
FROM DT;
SELECT * FROM EMP;
A continuacin se explica la sentencia anterior:
1. La primera parte de la sentencia INSERT genera 100 registros
correspondientes a los 100 primeros empleados utilizando una subconsulta
recursiva para generar los nmeros de empleado. Cada registro contiene el
nmero de empleado. Para cambiar el nmero de empleados, utilice un
nmero distinto de 100.
2. La sentencia SELECT genera la columna LASTNAME. Empieza generando
un entero aleatorio de hasta 6 dgitos de longitud utilizando la funcin
RAND. Luego convierte el entero en su formato de carcter numrico
utilizando la funcin CHAR.
3. Para convertir los caracteres numricos en caracteres alfabticos, la
sentencia utiliza la funcin TRANSLATE para convertir los diez caracteres
numricos (de 0 a 9) en caracteres alfabticos. Puesto que hay ms de 10
caracteres alfabticos, la sentencia selecciona entre cinco conversiones
diferentes. Esto da como resultado nombres que tienen suficientes vocales
aleatorias para que se puedan pronunciar y por eso las vocales se incluyen
en cada conversin.
4. La sentencia genera un valor de HIREDATE aleatorio. El valor de
HIREDATE va, hacia atrs, desde la fecha actual hasta hace 30 aos.
HIREDATE se calcula restando un nmero aleatorio de das, comprendido
entre 0 y 10.957, de la fecha actual. (10.957 es el nmero de das que hay
en 30 aos.)
5. Finalmente, la sentencia genera aleatoriamente el valor de SALARY. El
salario mnimo es 10.000, al que se suma un nmero aleatorio
comprendido entre 0 y 200.000.
Es posible que tambin desee considerar la posibilidad de crear prototipos de
funciones definidas por el usuario (UDF) que desarrolle contra los datos de
prueba.
v Import Overview en el manual Data Movement Utilities Guide and Reference
v Load Overview en el manual Data Movement Utilities Guide and Reference
v Depuracin y optimizacin de una aplicacin en la pgina 68
v Funcin escalar INSERT en el manual Consulta de SQL, Volumen 1
v Mandato RESTORE DATABASE en el manual Consulta de mandatos
Depuracin y optimizacin de una aplicacin
Puede depurar y optimizar la aplicacin mientras la desarrolla.
Procedimiento:
Para depurar y optimizar la aplicacin:
v Cree prototipos de las sentencias de SQL. Puede utilizar el procesador de
lnea de mandatos, el recurso Explain, analizar las vistas del catlogo del
sistema para obtener informacin sobre las tablas y bases de datos que
manipula el programa y actualizar determinadas estadsticas del catlogo
del sistema para simular condiciones de produccin.
v Utilice el recurso del marcador para comprobar la sintaxis de las sentencias
de SQL en aplicaciones que se desarrollan para DB2 Universal Database
para OS/390 y z/OS o para ver el cumplimiento con el estndar de nivel
bsico SQL92. Este recurso se invoca durante la precompilacin.
v Utilice las API de manejo de errores. Por ejemplo, puede utilizar las API de
manejo de errores para imprimir todos los mensajes durante la fase de
prueba.
v Utilice el supervisor del sistema de bases de datos para capturar
determinada informacin sobre optimizacin para analizarla.
v Catalog statistics for modeling and what-if planning en el manual
v Recursos para crear prototipos de sentencias de SQL en la pgina 50
v The database system-monitor information en el manual Administration
Guide: Performance
v Requisitos del archivo fuente para aplicaciones de SQL incorporado en la
pgina 86
Macro automtica de proyectos de IBM DB2 Universal Database para Microsoft
Visual C++
Las secciones siguientes describen la macro automtica de proyectos de IBM
DB2 Universal Database para Microsoft Visual C++.
La macro automtica de proyectos de IBM DB2 Universal Database para
Microsoft Visual C++
Microsoft Visual C++ es una serie de asistentes y herramientas de gestin que
se conectan al componente Visual C++ del IDE Visual Studio. Las
herramientas y asistentes automatizan y simplifican varias tareas que se deben
llevar a cabo para desarrollar aplicaciones para DB2 que utiliza SQL
incorporado.
Puede utilizar la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++ para desarrollar, empaquetar y desplegar:
v Procedimientos almacenados escritos en C/C++ para DB2 Universal
Database en sistemas operativos Windows
v Aplicaciones cliente de SQL incorporado de Windows C/C++ que acceden
a servidores DB2 Universal Database
v Aplicaciones cliente de Windows C/C++ que invocan procedimientos
almacenados utilizando reiniciadores de llamada de funcin C/C++
Microsoft Visual C++ le permite centrarse en el diseo y en la lgica de su
aplicacin DB2 en lugar de tenerse que preocupar de la creacin y despliegue
de la misma.
Algunas de las tareas que lleva a cabo la macro automtica de proyectos de
IBM DB2 Universal Database para Microsoft Visual C++ incluyen:
v Creacin de un nuevo mdulo de SQL incorporado
v Insercin de sentencias de SQL en un mdulo de SQL incorporado
utilizando SQL Assist
v Adicin de procedimientos almacenados importados
v Creacin de un procedimiento almacenado exportado
v Empaquetado del proyecto de DB2
v Despliegue del proyecto de DB2 desde dentro de Visual C++
Microsoft Visual C++ se presenta en forma de una barra de herramientas. Los
botones de la barra de herramientas incluyen:
Propiedades de proyecto de DB2
Gestiona las propiedades del proyecto (opciones de base de datos de
desarrollo y de generacin de cdigo)
Nuevo objeto de DB2
Aade un nuevo mdulo de SQL incorporado, procedimiento
almacenado importado o procedimiento almacenado exportado
Mdulos de SQL incorporado de DB2
Gestiona la lista de mdulos de SQL incorporado y sus opciones de
precompilador
Procedimientos almacenados importados de DB2
Gestiona la lista de procedimientos almacenados importados
Procedimientos almacenados exportados de DB2
Gestiona la lista de procedimientos almacenados exportados
Empaquetar proyecto de DB2
Empaqueta los archivos externos de proyecto de DB2
Desplegar proyecto de DB2
Despliega los archivos externos de proyecto de DB2 empaquetado
Microsoft Visual C++ tambin tiene los tres siguientes botones ocultos, que
pueden dejarse visibles utilizando las opciones estndares de personalizacin
de las herramientas de Visual C++:
Nuevo mdulo de SQL incorporado de DB2
Aade un nuevo mdulo de SQL incorporado de C/C++
Nuevo procedimiento almacenado importado de DB2
Importa un nuevo procedimiento almacenado de base de datos
Nuevo procedimiento almacenado exportado de DB2
Exporta un nuevo procedimiento almacenado de base de datos
Microsoft Visual C++ puede generar automticamente los siguientes
elementos de cdigo:
v Archivos de mdulo de SQL incorporado que forman el esqueleto con
sentencias de SQL opcionales de ejemplo
v Funciones estndares de SQL incorporado de conexin y desconexin de
base de datos
v Funciones de reiniciador de llamada de procedimiento almacenado
importado
v Plantillas de funcin de procedimiento almacenado exportado
v Archivos de lenguaje de definicin de datos (DDL) de procedimiento
almacenado exportado
Para obtener ms informacin sobre la Macro automtica de proyectos de IBM
DB2 Universal Database para Microsoft Visual C++, consulte:
v La ayuda en lnea correspondiente a la macro automtica de proyectos de
IBM DB2 Universal Database para Microsoft Visual C++
v http://www.ibm.com/software/data/db2/udb/ide/index.html
v Activacin de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++ en la pgina 73
v Activacin de la macro automtica de herramientas de IBM DB2 Universal
v Terminologa de la macro automtica de proyectos de IBM DB2 Universal
Terminologa de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++
La terminologa asociada con la macro automtica de proyectos de IBM DB2
Universal Database para Microsoft Visual C++ es la siguiente:
proyecto de IDE
El proyecto estndar Visual C++
proyecto de DB2
EL grupo de objetos de proyecto de DB2 que se insertan en el
proyecto de IDE. Los objetos de proyecto de DB2 se pueden insertar
en cualquier proyecto de Visual C++. El proyecto de DB2 le permite
gestionar diversos objetos de DB2, como mdulos de SQL
incorporado, procedimientos almacenados importados y
procedimientos almacenados exportados. Puede aadir, suprimir y
modificar estos objetos y sus propiedades.
mdulo
Un archivo en cdigo fuente C/C++ que puede contener sentencias de
SQL.
base de datos de desarrollo
La base de datos que sirve para compilar mdulos de SQL
intercalado. La base de datos de desarrollo tambin sirve para buscar
la lista de definiciones de procedimientos almacenados de base de
datos que se pueden importar.
mdulo de SQL incorporado
Un archivo en cdigo fuente C/C++ que contiene SQL dinmico o
esttico incorporado.
procedimiento almacenado importado
Un procedimiento almacenado, ya definido en la base de datos, que
invoca el proyecto.
procedimiento almacenado exportado
Un procedimiento almacenado de base de datos que crea y define el
proyecto.
v La macro automtica de proyectos de IBM DB2 Universal Database para
Microsoft Visual C++ en la pgina 69
Activacin de la macro automtica de proyectos de IBM DB2 Universal
Active la macro automtica de proyectos de IBM DB2 Universal Database
para Microsoft Visual C++ para acceder a la barra de herramientas flotante.
Nota: si la barra de herramientas se cierra accidentalmente, puede desactivar
y volver a activar la macro automtica o utilizar las opciones de
personalizacin estndar de Microsoft Visual C++ para volver a
visualizar la barra de herramientas.
Procedimiento:
1. Inicie y detenga Visual C++ al menos una vez con su ID de conexin
actual. La primera vez que se ejecuta Visual C++, se crea un perfil para el
ID de usuario, y esto es lo que se actualiza mediante el mandato db2vccmd.
Si no lo ha iniciado una vez e intenta ejecutar db2vccmd, se puede
encontrar errores como los siguientes:
"Registering DB2 Project add-in ...Failed! (rc = 2)"
2. Registre la macro automtica, si an no la ha hecho, especificando lo
siguiente en la lnea de mandatos:
db2vccmd register
3. Seleccione Herramientas > Personalizar. Se abrir el cuaderno
Personalizar.
4. Seleccione la pestaa Macros automticas y archivos de macro. Se abrir
la pgina Macros automticas y archivos de macro.
5. Seleccione el recuadro Macro automtica de proyectos de IBM DB2.
6. Pulse Aceptar. Se crear una barra de herramientas flotante.
Activacin de la macro automtica de herramientas de IBM DB2 Universal
La macro automtica de herramientas de DB2 es una barra de herramientas
que permite ejecutar algunas de las herramientas de desarrollo y
administracin de DB2 desde dentro del entorno de desarrollo integrado de
Visual C++.
Procedimiento:
Para activar la macro automtica de herramientas de IBM DB2 Universal
Database para Microsoft Visual C++, siga los pasos siguientes:
1. Inicie y detenga Visual C++ al menos una vez con su ID de conexin
actual. La primera vez que se ejecuta Visual C++, se crea un perfil para el
ID de usuario, y esto es lo que se actualiza mediante el mandato db2vccmd.
Si no lo ha iniciado una vez e intenta ejecutar db2vccmd, se puede
encontrar errores como los siguientes:
"Registering DB2 Project add-in ...Failed! (rc = 2)"
2. Registre la macro automtica, si an no la ha hecho, especificando lo
siguiente en la lnea de mandatos:
db2vccmd register
3. Seleccione Herramientas > Personalizar. Se abrir el cuaderno
Personalizar.
4. Seleccione la pestaa Macros automticas y archivos de macro.
5. Seleccione el recuadro Macro automtica de herramientas de IBM DB2.
6. Pulse Aceptar. Se crear una barra de herramientas flotante.
Nota: si la barra de herramientas se cierra accidentalmente, puede desactivar
y volver a activar la macro automtica o utilizar las opciones de
personalizacin estndar de Visual C++ para volver a visualizar la
barra de herramientas.
Parte 2. SQL incorporado
Captulo 3. Visin general sobre SQL incorporado
Incorporacin de sentencias de SQL en un
lenguaje principal . . . . . . . . . . 77
Creacin y preparacin del archivo fuente . . 79
Paquetes, vinculacin y SQL incorporado . . 82
Creacin de paquetes para SQL
incorporado . . . . . . . . . . . 82
Precompilacin de archivos fuente que
contienen SQL incorporado . . . . . . 84
Requisitos del archivo fuente para
aplicaciones de SQL incorporado . . . . 86
Compilacin y enlace de archivos fuente
que contienen SQL incorporado . . . . 88
Creacin de paquetes mediante el mandato
BIND . . . . . . . . . . . . . 89
Creacin de versiones de paquetes . . . 90
Efecto de registros especiales en SQL
dinmico vinculado . . . . . . . . 91
Resolucin de nombres de tabla no
calificados. . . . . . . . . . . . 92
Consideraciones adicionales cuando se
vincula. . . . . . . . . . . . . 93
Ventajas de la vinculacin diferida . . . 94
Contenido del archivo de vinculacin . . 95
Relaciones entre aplicacin, archivo de
vinculacin y paquete. . . . . . . . 95
Indicaciones horarias generadas por el
precompilador . . . . . . . . . . 96
Revinculacin de paquetes . . . . . . 98
Incorporacin de sentencias de SQL en un lenguaje principal
Puede escribir aplicaciones con sentencias de SQL incorporadas dentro de un
lenguaje principal. Las sentencias de SQL proporcionan la interfaz de base de
datos, mientras que el lenguaje principal proporciona el soporte restante
necesario para que se ejecute la aplicacin.
Procedimiento:
Utilice los ejemplos de la tabla siguiente como gua para ver cmo se
incorporan sentencias de SQL en una aplicacin de lenguaje principal. En el
ejemplo, la aplicacin comprueba el campo SQLCODE de la estructura SQLCA
para determinar si la actualizacin ha resultado satisfactoria.
Tabla 2. Incorporacin de sentencias de SQL en un lenguaje principal
Lenguaje Cdigo fuente de ejemplo
C/C++
EXEC SQL UPDATE staff SET job = Clerk WHERE job = Mgr;
if ( SQLCODE < 0 )
printf( "Update Error: SQLCODE = %ld \n", SQLCODE );
Java (SQLj)
try {
#sql { UPDATE staff SET job = Clerk WHERE job = Mgr };
}
catch (SQLException e) {
println( "Update Error: SQLCODE = " + e.getErrorCode() );
}
Tabla 2. Incorporacin de sentencias de SQL en un lenguaje principal (continuacin)
COBOL
EXEC SQL UPDATE staff SET job = Clerk WHERE job = Mgr END_EXEC.
IF SQLCODE LESS THAN 0
DISPLAY UPDATE ERROR: SQLCODE = , SQLCODE.
FORTRAN
EXEC SQL UPDATE staff SET job = Clerk WHERE job = Mgr
if ( sqlcode .lt. 0 ) THEN
write(*,*) Update error: sqlcode = , sqlcode
Las sentencias de SQL que se colocan en una aplicacin no son especficas del
lenguaje principal. El gestor de bases de datos proporciona una forma de
convertir la sintaxis de SQL para que la procese el lenguaje de sistema
principal:
v Para los lenguajes C, C++, COBOL o FORTRAN, esta conversin la maneja
el precompilador de DB2. El precompilador de DB2 se invoca utilizando el
mandato PREP. El precompilador convierte las sentencias de SQL
incorporado directamente en llamadas a API de servicios de tiempo de
ejecucin de DB2.
v Para el lenguaje Java, el conversor SQLj convierte clusulas SQLj en
sentencias JDBC. El conversor SQLj se invoca con el mandato sqlj.
Cuando el precompilador procesa un archivo fuente, busca especficamente
sentencias de SQL y evita el lenguaje principal que no es SQL. Puede
encontrar sentencias de SQL porque estn especificadas entre delimitadores
especiales. Los ejemplos de la tabla siguiente muestran cmo utilizar
delimitadores y comentarios para crear sentencias de SQL incorporado en los
lenguajes de sistema principal compilados soportados.
Tabla 3. Incorporacin de sentencias de SQL en un lenguaje principal
C/C++
/* Aqu slo se permiten comentarios de C o C++ */
EXEC SQL
-- Aqu se permiten comentarios de SQL
/* o comentarios de C */
// o comentarios de C++
DECLARE C1 CURSOR FOR sname;
/* Aqu slo se permiten comentarios de C o C++ */
Tabla 3. Incorporacin de sentencias de SQL en un lenguaje principal (continuacin)
SQLj
/* Aqu slo se permiten comentarios de Java */
#sql c1 = {
/* o comentarios de Java */
// o comentarios de Java
SELECT name FROM employee
};
/* Aqu slo se permiten comentarios de Java */
COBOL
* Consulte la documentacin de COBOL para ver normas de comentarios
* Aqu slo se permiten comentarios de COBOL
EXEC SQL
* o comentarios de COBOL de lnea completa
DECLARE C1 CURSOR FOR sname END-EXEC.
* Aqu slo se permiten comentarios de COBOL
FORTRAN
C Aqu slo se permiten comentarios de FORTRAN
EXEC SQL
+ -- Aqu se permiten comentarios de SQL y
C comentarios de FORTRAN de lnea completa
+ DECLARE C1 CURSOR FOR sname
I=7 ! End of line Aqu se permiten comentarios de FORTRAN
C Aqu slo se permiten comentarios de FORTRAN
v SQL incorporado en aplicaciones REXX en la pgina 372
v Sentencias de SQL incorporado en C y C++ en la pgina 182
v Sentencias de SQL incorporado en COBOL en la pgina 237
v Sentencias de SQL incorporado en FORTRAN en la pgina 267
v Sentencias de SQL incorporado en Java en la pgina 306
Creacin y preparacin del archivo fuente
Puede crear el cdigo fuente en un archivo ASCII estndar, denominado un
archivo fuente, utilizando un editor de texto. El archivo fuente debe tener la
extensin adecuada para el lenguaje principal en el que escribe el cdigo.
Nota: no todas las plataformas dan soporte a todos los lenguajes principales.
Para este tema, daremos por supuesto que ya ha escrito el cdigo fuente.
Captulo 3. Visin general sobre SQL incorporado 79
Si ha escrito la aplicacin utilizando un lenguaje principal compilado, debe
seguir pasos adicionales para crear la aplicacin. Adems de compilar y
enlazar el programa, debe precompilarlo y vincularlo.
Dicho de forma sencilla, la precompilacin convierte sentencias de SQL
incorporado en llamadas a API en tiempo de ejecucin de DB2 que un
compilador de sistema principal puede procesar y crea un archivo de
vinculacin. El archivo de vinculacin contiene informacin sobre las
sentencias de SQL del programa de aplicacin. El mandato BIND crea un
paquete en la base de datos. Opcionalmente, el precompilador puede llevar a
cabo al paso de vinculacin en el momento de la precompilacin.
La vinculacin es el proceso de crear un paquete a partir de un archivo de
vinculacin y de almacenarlo en una base de datos. Si la aplicacin accede a
ms de una base de datos, debe crear un paquete para cada base de datos.
La figura siguiente muestra el orden de estos pasos, junto con los distintos
mdulos de una tpica aplicacin de DB2 compilada.
v Precompilacin de archivos fuente que contienen SQL incorporado en la
pgina 84
Archivos fuente
con
sentencias SQL
Archivos fuente
modificados
Archivos
de objetos
Archivos fuente
sin
sentencias SQL
Bibliotecas
Precompilador
(db2 PREP)
PACKAGE
Crear un
paquete
Compi l ador de l enguaj e de
si st ema pr i nci pal
Enlazador de lenguaje
de sistema principal
Programa
ejecutable
Paquete del gestor de base de datos (Paquete)
Archivo
de vinculacin
Vinculador
(db2 BIND)
BINDFILE
Crear un archivo
de vinculacin
1
2
3
4
6
5
Figura 1. Preparacin de programas escritos en lenguajes principal compilados
pgina 86
v Compilacin y enlace de archivos fuente que contienen SQL incorporado
en la pgina 88
v SQL incorporado en la pgina 9
Paquetes, vinculacin y SQL incorporado
Las secciones siguientes describen cmo crear paquetes para aplicaciones de
SQL incorporado, as como otros temas, como la vinculacin diferida y las
relaciones entre la aplicacin, el archivo de vinculacin y el paquete.
Creacin de paquetes para SQL incorporado
Para ejecutar aplicaciones escritas en lenguajes principales compilados, debe
crear los paquetes que necesita el gestor de bases de datos en el momento de
la ejecucin. Esto implica llevar a cabo los pasos siguientes, tal como se
muestra en la siguiente figura:
v Precompilacin (paso 2), para convertir las sentencias fuente de SQL
incorporado en un formato que el gestor de bases de datos pueda utilizar
Archivos fuente
con
sentencias SQL
Archivos fuente
modificados
Archivos
de objetos
Archivos fuente
sin
sentencias SQL
Bibliotecas
Precompilador
(db2 PREP)
PACKAGE
Crear un
paquete
Compi l ador de l enguaj e de
si st ema pr i nci pal
Enlazador de lenguaje
de sistema principal
Programa
ejecutable
Paquete del gestor de base de datos (Paquete)
Archivo
de vinculacin
Vinculador
(db2 BIND)
BINDFILE
Crear un archivo
de vinculacin
1
2
3
4
6
5
Figura 2. Preparacin de programas escritos en lenguajes principales compilados
v Compilacin y enlace (pasos 3 y 4), para crear los mdulos de objetos
necesarios, y
v Vinculacin (paso 5), para crear el paquete que utilizar el gestor de bases
de datos cuando se ejecute el programa.
v Precompilacin de archivos fuente que contienen SQL incorporado en la
pgina 84
pgina 86
v Compilacin y enlace de archivos fuente que contienen SQL incorporado
en la pgina 88
v Creacin de paquetes mediante el mandato BIND en la pgina 89
v Creacin de versiones de paquetes en la pgina 90
v Efecto de registros especiales en SQL dinmico vinculado en la pgina 91
v Resolucin de nombres de tabla no calificados en la pgina 92
v Consideraciones adicionales cuando se vincula en la pgina 93
v Ventajas de la vinculacin diferida en la pgina 94
v Relaciones entre aplicacin, archivo de vinculacin y paquete en la
pgina 95
v Indicaciones horarias generadas por el precompilador en la pgina 96
v Revinculacin de paquetes en la pgina 98
v Opciones del conversor SQLj en la pgina 312
v db2bfd - Mandato Herramienta de descripcin de archivo de vinculacin
en el manual Consulta de mandatos
Precompilacin de archivos fuente que contienen SQL incorporado
Despus de crear los archivos fuente, debe precompilar cada archivo de
lenguaje principal que contenga sentencias de SQL con el mandato PREP para
archivos fuente de lenguaje principal. El precompilador convierte las
sentencias de SQL contenidas en el archivo fuente en comentarios y genera las
llamadas a API en tiempo de ejecucin de DB2 para dichas sentencias.
Antes de precompilar una aplicacin, debe conectarse con el servidor, de
forma implcita o explcita. Aunque precompile programas de aplicacin en la
estacin de trabajo cliente y el precompilador genere fuente modificada y
mensajes en el cliente, el precompilador utiliza la conexin con el servidor
para llevar a cabo parte de la validacin.
El precompilador tambin crea la informacin que necesita el gestor de bases
de datos para procesar las sentencias de SQL contra una base de datos. Esta
informacin se almacena en un paquete, en un archivo de vinculacin o en
ambos, en funcin de las opciones del precompilador seleccionadas.
A continuacin se muestra un ejemplo tpico de cmo utilizar el
precompilador. Para precompilar un archivo fuente de SQL incorporado C
denominado filename.sqc, puede emitir el siguiente mandato para crear un
archivo fuente C con el nombre por omisin filename.c y un archivo de
vinculacin con el nombre por omisin filename.bnd:
DB2 PREP filename.sqc BINDFILE
El precompilador genera un mximo de cuatro tipos de salida:
Fuente modificada
Este archivo es la nueva versin del archivo fuente original
despus de que el precompilador convierta las sentencias de
SQL en llamadas a API en tiempo de ejecucin de DB2. Se le
asigna la extensin adecuada para el lenguaje principal.
Paquete Si utiliza la opcin PACKAGE (el valor por omisin) o si no
especifica ninguna de las opciones BINDFILE, SYNTAX o
SQLFLAG, el paquete se almacena en la base de datos
conectada. El paquete contiene toda la informacin necesaria
para ejecutar las sentencias de SQL esttico de un archivo
fuente particular contra esta base de datos nicamente. A no
ser que especifique otro nombre con la opcin PACKAGE
USING, el precompilador forma el nombre del paquete a
partir de los 8 primeros caracteres del nombre del archivo
fuente.
Si utiliza la opcin PACKAGE sin SQLERROR CONTINUE, la
base de datos que se utiliza durante el proceso de
precompilacin debe contener todos los objetos de base de
datos a los que hacen referencia las sentencias de SQL esttico
en el archivo fuente. Por ejemplo, no puede precompilar una
sentencia SELECT a no ser que la tabla a la que hace
referencia exista en la base de datos.
Con la opcin VERSION, el archivo de vinculacin (si se
utiliza la opcin BINDFILE) y el paquete (tanto si se vincula
en el momento de PREP como si se vincula por separado) se
designarn con un identificador de versin particular. Pueden
existir simultneamente muchas versiones de paquetes con el
mismo nombre y creador.
Archivo de vinculacin
Si utiliza la opcin BINDFILE, el precompilador crea un
archivo de vinculacin (con la extensin .bnd) que contiene
los datos necesarios para crear un paquete. Este archivo se
puede utilizar ms adelante con el mandato BIND para
vincular la aplicacin a una o ms bases de datos. Si especifica
BINDFILE y no especifica la opcin PACKAGE, la vinculacin
se difiere hasta que invoca el mandato BIND. Observe que para
el procesador de lnea de mandatos (CLP), el valor por
omisin para PREP no especifica la opcin BINDFILE. Por lo
tanto, si utiliza el CLP y desea que la vinculacin se difiera,
tiene que especificar la opcin BINDFILE.
Si se especifica SQLERROR CONTINUE se crea un paquete,
aunque se produzcan errores al vincular sentencias de SQL.
Estas sentencias que no se pueden vincular por motivos de
autorizacin o de existencia se pueden vincular de forma
incremental en el momento de la ejecucin si tambin se
especifica VALIDATE RUN. Si se intenta ejecutarlas en el
momento de la ejecucin se genera un error.
Archivo de mensajes
Si utiliza la opcin MESSAGES, el precompilador redirige los
mensajes al archivo indicado. Estos mensajes incluyen avisos y
mensajes de error que describen problemas encontrados
durante la precompilacin. Si el archivo fuente no se
precompila satisfactoriamente, utilice los mensajes de aviso y
de error para determinar el problema, corrija el archivo fuente
y luego vuelva a intentar precompilar el archivo fuente. Si no
utiliza la opcin MESSAGES, los mensajes de precompilacin
se graban en la salida estndar.
v Creacin de versiones de paquetes en la pgina 90
v Mandato PRECOMPILE en el manual Consulta de mandatos
Requisitos del archivo fuente para aplicaciones de SQL incorporado
Siempre debe precompilar un archivo fuente contra una base de datos
especfica, incluso si finalmente no utiliza la base de datos con la aplicacin.
En la prctica, puede utilizar una base de datos de prueba para desarrollo y,
despus de probar por completo la aplicacin, puede vincular su archivo de
vinculacin a una o ms bases de datos de produccin. Esta prctica recibe el
nombre de vinculacin diferida.
Si la aplicacin utiliza una pgina de cdigos distinta de la pgina de cdigos
de la base de datos, debe tener en cuenta qu pgina de cdigos debe utilizar
al precompilar.
Si la aplicacin utiliza funciones definidas por el usuario (UDF) o tipos
diferenciados definidos por el usuario (UDT), es posible que tenga que utilizar
la opcin FUNCPATH al precompilar la aplicacin. Esta opcin especifica la
va de acceso de funcin que se utiliza para resolver las UDF y UDT para
aplicaciones que contienen SQL esttico. Si no se especifica FUNCPATH, la va
de acceso de funcin por omisin es SYSIBM, SYSFUN, USER, donde USER
hace referencia al ID de usuario actual.
Para precompilar un programa de aplicacin que accede a ms de un servidor,
puede hacer una de las siguientes cosas:
v Dividir las sentencias de SQL correspondientes a cada base de datos en
archivos fuente separados. No combine sentencias de SQL correspondientes
a distintas bases de datos en el mismo archivo. Cada archivo fuente se
puede precompilar contra la base de datos apropiada. Este es el mtodo
recomendado.
v Codificar la aplicacin utilizando nicamente sentencias de SQL dinmico y
vincular contra cada base de datos a la que va a acceder el programa.
v Si todas las bases de datos se parecen, es decir, tienen la misma definicin,
puede agrupar las sentencias de SQL en un archivo fuente.
Los mismos procedimientos se aplican si la aplicacin va a acceder a un
servidor de aplicaciones de sistema principal, AS/400 o iSeries a travs de
DB2 Connect. Precomplela contra el servidor al que se va a conectar,
utilizando las opciones de PREP disponibles para dicho servidor.
Si va a precompilar una aplicacin que se va a ejecutar en DB2 Universal
Database para OS/390 y z/OS, considere la posibilidad de utilizar el recurso
del marcador para comprobar la sintaxis de las sentencias de SQL. El
marcador indica la sintaxis de SQL a la que da soporte DB2 Universal
Database pero a la que no da soporte DB2 Universal Database para OS/390 y
z/OS. Tambin puede utilizar el marcador para comprobar que la sintaxis de
SQL cumple con la sintaxis de nivel bsico de SQL92. Puede utilizar la opcin
SQLFLAG en el mandato PREP para invocarlo y para especificar la versin de
la sintaxis de SQL de DB2 Universal Database para OS/390 y z/OS que se va
a utilizar para la comparacin. El recurso del marcador no obliga a realizar
ningn cambio en el uso de SQL; slo emite mensajes de informacin y de
aviso sobre las incompatibilidades de la sintaxis y no termina el preproceso de
forma anmala.
v Ventajas de la vinculacin diferida en la pgina 94
v Conversin de caracteres entre distintas pginas de cdigos en la pgina
436
v Cundo se produce la conversin de pgina de cdigos en la pgina 437
v Sustitucin de caracteres durante conversiones de pginas de cdigos en
la pgina 438
v Conversiones de pginas de cdigos soportadas en la pgina 438
v Factor de expansin de conversin de pgina de cdigos en la pgina 440
Compilacin y enlace de archivos fuente que contienen SQL incorporado
Compile los archivos fuente modificados y los archivos fuente adicionales que
no contienen sentencias de SQL utilizando el compilador de lenguaje principal
adecuado. El compilador de lenguaje convierte cada archivo fuente
modificado en un mdulo de objeto.
Consulte la documentacin sobre programacin correspondiente a su
plataforma operativa para ver las excepciones a las opciones del compilador
por omisin. Consulte la documentacin del compilador para ver una
descripcin completa de las opciones disponibles del compilador.
El enlazador del lenguaje principal crea una aplicacin ejecutable. Por
ejemplo:
v En sistemas operativos Windows, la aplicacin puede ser un archivo
ejecutable o una biblioteca de enlace dinmico (DLL).
v En sistemas basados en UNIX, la aplicacin puede ser un mdulo de carga
ejecutable o una biblioteca compartida.
Nota: aunque las aplicaciones pueden ser DLL en sistemas operativos
Windows, es la aplicacin y no el gestor de bases de datos de DB2 la
que carga directamente las DLL. En sistemas operativos Windows, el
gestor de bases de datos puede cargar DLL. Los procedimientos
almacenados se crean normalmente como DLL o bibliotecas
compartidas.
Para crear el archivo ejecutable, enlace lo siguiente:
v Mdulos de objetos de usuario, generados por el compilador del lenguaje a
partir de los archivos fuente modificados y otros archivos que no contienen
sentencias de SQL.
v API de biblioteca de lenguaje principal, que se suministran con el
compilador del lenguaje.
v La biblioteca del gestor de bases de datos que contiene las API del gestor
de bases de datos correspondientes a su entorno operativo. Consulte la
documentacin sobre programacin adecuada para su plataforma operativa
para ver el nombre especfico de la biblioteca del gestor de bases de datos
que necesita para las API del gestor de bases de datos.
v Creacin y ejecucin de aplicaciones REXX en la pgina 383
v Creacin de applets JDBC en el manual Gua de desarrollo de aplicaciones:
v Creacin de aplicaciones JDBC en el manual Gua de desarrollo de
v Creacin de applets SQLJ en el manual Gua de desarrollo de aplicaciones:
v Creacin de aplicaciones SQLJ en el manual Gua de desarrollo de
v Creacin de aplicaciones C en AIX en el manual Gua de desarrollo de
v Creacin de aplicaciones C++ en AIX en el manual Gua de desarrollo de
v Creacin de aplicaciones IBM COBOL en AIX en el manual Gua de
v Creacin de aplicaciones Micro Focus COBOL en AIX en el manual Gua
de desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
Creacin de paquetes mediante el mandato BIND
La vinculacin es el proceso que crea el paquete que necesita el gestor de
bases de datos para poder acceder a la base de datos cuando se ejecuta la
aplicacin. La vinculacin se puede realizar de forma implcita, especificando
la opcin PACKAGE durante la precompilacin, o de forma explcita,
utilizando el mandato BIND contra el archivo de vinculacin creado durante la
precompilacin.
A continuacin se muestra un ejemplo tpico de cmo utilizar el mandato
BIND. Para vincular un archivo de vinculacin denominado filename.bnd a la
base de datos, puede emitir el siguiente mandato:
DB2 BIND filename.bnd
Se crea un paquete para cada mdulo de cdigo fuente precompilado por
separado. Si una aplicacin tiene cinco archivos fuente, de los cuales tres
necesitan precompilacin, se crean tres paquetes o archivos de vinculacin.
Por omisin, a cada paquete se le asigna un nombre que coincide con el
nombre del mdulo fuente a partir del cual se ha originado el archivo .bnd,
pero truncado a 8 caracteres. Para especificar de forma explcita otro nombre
de paquete, debe utilizar la opcin PACKAGE USING en el mandato PREP. La
versin de un paquete la proporciona la opcin de precompilacin VERSION
y su valor por omisin es una serie vaca. Si el nombre y esquema de este
paquete recin creado coinciden con el nombre de un paquete que existe
actualmente en la base de datos de destino, pero el identificador de versin
difiere, se crea un paquete nuevo y se conserva el paquete anterior. Sin
embargo, si existe un paquete cuyo nombre, esquema y versin coinciden con
los del paquete que se est vinculando, el paquete se elimina y se sustituye
por el paquete nuevo que se est vinculando (si se especifica ACTION ADD
en la vinculacin se evita que se devuelva un error (SQL0719)).
Creacin de versiones de paquetes
Si tiene que crear varias versiones de una aplicacin, puede utilizar la opcin
VERSION del mandato PRECOMPILE. Esta opcin permite la coexistencia de
varias versiones del mismo nombre de paquete (es decir, el nombre del
paquete y el nombre del creador). Por ejemplo, supongamos que tiene una
aplicacin denominada foo que se compila desde foo.sqc. Precompilara y
vinculara el paquete foo a la base de datos y distribuira la aplicacin a los
usuarios. Luego los usuarios podran ejecutar la aplicacin. Para realizar
cambios en la aplicacin, actualizara foo.sqc y luego repetira el proceso de
recompilacin, vinculacin y envo de la aplicacin a los usuarios. Si no se
especifica la opcin VERSION para la primera o segunda precompilacin de
foo.sqc, el primer paquete se sustituye por el segundo. Cualquier usuario que
intente ejecutar la versin antigua de la aplicacin recibir un error SQLCODE
-818, que indica un error de falta de coincidencia de indicacin horaria.
Para evitar el error de falta de coincidencia de indicacin horaria y para
permitir que ambas versiones de la aplicacin se ejecutan al mismo tiempo,
utilice la creacin de versiones de paquetes. Como ejemplo, cuando cree la
primera versin de foo, precomplela utilizando la opcin VERSION, del
siguiente modo:
DB2 PREP FOO.SQC VERSION V1.1
Ahora se puede ejecutar esta primera versin del programa. Cuando cree la
nueva versin de foo, precomplela con el mandato:
DB2 PREP FOO.SQC VERSION V1.2
En este momento esta nueva versin de la aplicacin tambin se ejecutar,
aunque an se estn ejecutando instancias de la primera aplicacin. Puesto
que la versin de paquete correspondiente al primer paquete es V1.1 y la
versin de paquete correspondiente al segundo es V1.2, no hay conflicto de
nombres: ambos paquetes existirn en la base de datos y ambas versiones de
la aplicacin se pueden utilizar.
Puede utilizar la opcin ACTION de los mandatos PRECOMPILE o BIND
junto con la opcin VERSION del mandato PRECOMPILE. La opcin
ACTION sirve para controlar el modo en que las distintas versiones de
paquetes se pueden aadir o sustituir.
Los privilegios de paquetes no tienen granularidad a nivel de versin. Es
decir, una accin GRANT o REVOKE de un privilegio de paquete se aplica a
todas las versiones de un paquete que comparten el nombre y el creador. As,
si se otorgaran los privilegios del paquete foo a un usuario o un grupo
despus de que se creara la versin V1.1, cuando se distribuyera la versin
V1.2 el usuario o grupo tendra los mismos privilegios sobre la versin V1.2.
Este comportamiento suele ser necesario porque normalmente los mismos
usuarios y grupos tienen los mismos privilegios sobre todas las versiones de
un paquete. Si no desea que se apliquen los mismos privilegios de paquete a
todas las versiones de una aplicacin, no utilice la opcin PRECOMPILE
VERSION al realizar versiones del paquete. En su lugar, utilice distintos
nombres de paquetes (cambiando el nombre del archivo fuente actualizado o
utilizando la opcin PACKAGE USING para cambiar el nombre del paquete
de forma explcita).
v Indicaciones horarias generadas por el precompilador en la pgina 96
Efecto de registros especiales en SQL dinmico vinculado
Para sentencias preparadas de forma dinmica, los valores de varios registros
especiales determinan el entorno de compilacin de sentencias:
v El registro especial CURRENT QUERY OPTIMIZATION determina qu
clase de optimizacin se utiliza.
v El registro especial CURRENT PATH determina la va de acceso de funcin
utilizada para la resolucin de UDF y UDT.
v El registro CURRENT EXPLAIN SNAPSHOT determina qu informacin de
instantnea de Explain se captura.
v El registro CURRENT EXPLAIN MODE determina si la informacin de
tabla de Explain se captura, para cualquier sentencia de SQL dinmico que
se pueda elegir. Los valores por omisin correspondientes a estos registros
especiales son los mismos que se utilizan para las opciones de vinculacin
relacionadas.
v Registro especial CURRENT EXPLAIN MODE en el manual Consulta de
SQL, Volumen 1
v Registro especial CURRENT EXPLAIN SNAPSHOT en el manual Consulta
de SQL, Volumen 1
v Registro especial CURRENT PATH en el manual Consulta de SQL,
Volumen 1
v Registro especial CURRENT QUERY OPTIMIZATION en el manual
Consulta de SQL, Volumen 1
Resolucin de nombres de tabla no calificados
Puede manejar nombres de tabla no calificados en la aplicacin utilizando uno
de los siguientes mtodos:
v Para cada usuario, vincule el paquete con distintos parmetros de
COLLECTION procedentes de los distintos identificadores de autorizacin
utilizando los siguientes mandatos:
CONNECT TO db_name USER user_name
BIND file_name COLLECTION schema_name
En el ejemplo anterior, db_name es el nombre de la base de datos, user_name
es el nombre del usuario y file_name es el nombre de la aplicacin que se va
a vincular. Tenga en cuenta que user_name y schema_name suelen tener el
mismo valor. Luego utilice la sentencia SET CURRENT PACKAGESET para
especificar qu paquete utilizar y, por lo tanto, qu calificadores se
utilizarn. El calificador por omisin es el identificador de autorizacin que
se utiliza al vincular el paquete.
v Cree vistas para cada usuario con el mismo nombre que la tabla de modo
que los nombres de tabla no calificados se resuelvan correctamente.
v Cree un alias para que cada usuario apunte a la tabla deseada.
v SET CURRENT PACKAGESET sentencia en el manual Consulta de SQL,
Volumen 2
Consideraciones adicionales cuando se vincula
Si la pgina de cdigos de la aplicacin utiliza una pgina de cdigos distinta
de la de la base de datos, es posible que deba tener en cuenta qu pgina de
cdigos utilizar al vincular.
Si la aplicacin emite llamadas a alguna de las API de programas de utilidad
del gestor de bases de datos, como por ejemplo IMPORT o EXPORT, debe
vincular los archivos de vinculacin suministrados por el programa de
utilidad a la base de datos.
Puede utilizar opciones de vinculacin para controlar determinadas
operaciones que se producen durante la vinculacin, como en los siguientes
ejemplos:
v La opcin de vinculacin QUERYOPT aprovecha una clase de optimizacin
especfica al vincular.
v La opcin de vinculacin EXPLSNAP almacena informacin de instantnea
de Explain para las sentencias de SQL que se pueden elegir en las tablas de
Explain.
v La funcin de vinculacin FUNCPATH resuelve correctamente tipos
diferenciados definidos por el usuario y funciones definidas por el usuario
en SQL esttico.
Si el proceso de vinculacin comienza pero nunca vuelve, es posible que otras
aplicaciones conectadas a la base de datos mantengan bloqueos que necesita.
En este caso, asegrese de que no haya aplicaciones conectadas a la base de
datos. Si las hay, desconecte todas las aplicaciones en el servidor y el proceso
de vinculacin continuar.
Si la aplicacin va a acceder a un servidor utilizando DB2 Connect, puede
utilizar las opciones de BIND disponibles para dicho servidor.
Los archivos de vinculacin no son compatibles con versiones anteriores de
DB2 Universal Database. En entornos de nivel mixto, DB2 slo puede utilizar
las funciones disponibles al nivel inferior del entorno de base de datos. Por
ejemplo, si un cliente V8 se conecta a un servidor V7.2, el cliente slo podr
utilizar funciones de V7.2. Como los archivos de vinculacin expresan las
funciones de la base de datos, estn sujetos a la restriccin de nivel mixto.
Si tiene que volver a vincular archivos de vinculacin de nivel superior en
sistemas de nivel inferior, puede:
v Utilizar un DB2 Application Development Client de nivel inferior con el
servidor de nivel superior y crear archivos de vinculacin que se puedan
suministrar y vincular al entorno de DB2 Universal Database de nivel
inferior.
v Utilizar un cliente DB2 de nivel superior en el entorno de produccin de
nivel inferior para vincular los archivos de vinculacin de nivel superior
creados en el entorno de prueba. El cliente de nivel superior slo pasa las
opciones que se aplican al servidor de nivel inferior.
v Binding utilities to the database en el manual Administration Guide:
Implementation
436
v Sustitucin de caracteres durante conversiones de pginas de cdigos en
la pgina 438
Ventajas de la vinculacin diferida
La precompilacin con la vinculacin habilitada permite que una aplicacin
acceda nicamente a la base de datos utilizada durante el proceso de
precompilacin. Sin embargo, la precompilacin con vinculacin diferida
permite que una aplicacin acceda a muchas bases de datos, puesto que
puede vincular el archivo BIND contra cada una. Este mtodo de desarrollo
de aplicaciones es ms flexible por el hecho de que las aplicaciones slo se
precompilan una vez, pero la aplicacin se puede vincular a una base de
datos en cualquier momento.
Utilizar la API BIND durante la ejecucin permite que una aplicacin se
vincule a s misma, quizs como parte de un procedimiento de instalacin o
antes de que se ejecute un mdulo asociado. Por ejemplo, una aplicacin
puede realizar varias tareas, de las cuales slo una necesita el uso de
sentencias de SQL. Puede disear la aplicacin de modo que se vincule a s
misma a una base de datos slo cuando la aplicacin llame a la tarea que
necesita sentencias de SQL y slo si an no existe un paquete asociado.
Otra ventaja del mtodo de vinculacin diferida es que le permite crear
paquetes sin suministrar el cdigo fuente a los usuarios finales. Puede
suministrar los archivos de vinculacin asociados con la aplicacin.
v sqlabndx - Bind en el manual Administrative API Reference
Contenido del archivo de vinculacin
Con el programa de utilidad de Descripcin de archivos de vinculacin de
DB2 (db2bfd), puede visualizar fcilmente el contenido de un archivo de
vinculacin para examinar y verificar las sentencias de SQL que contiene, as
como visualizar las opciones de precompilacin utilizadas para crear el
archivo de vinculacin. Esto puede resultar til en la determinacin de
problemas relacionados con el archivo de vinculacin de la aplicacin.
v db2bfd - Mandato Herramienta de descripcin de archivo de vinculacin
en el manual Consulta de mandatos
Relaciones entre aplicacin, archivo de vinculacin y paquete
Un paquete es un objeto almacenado en la base de datos que incluye
informacin necesaria para ejecutar sentencias de SQL especficas en un solo
archivo fuente. Una aplicacin de base de datos utiliza un paquete para cada
archivo fuente precompilado utilizado para crear la aplicacin. Cada paquete
constituye una entidad separada y no tiene ninguna relacin con ningn otro
paquete utilizado por la misma o por otras aplicaciones. Los paquetes se crean
ejecutando el precompilador contra un archivo fuente con la vinculacin
habilitada o ejecutando el vinculador posteriormente con uno o ms archivos
de vinculacin.
Las aplicaciones de bases de datos utilizan paquetes por algunas de las
mismas razones por las que se compilan las aplicaciones: mejora de
rendimiento y de compactacin. Al precompilar una sentencia de SQL, la
sentencia se compila en el paquete cuando se crea la aplicacin en lugar de
hacerlo en el tiempo de ejecucin. Cada sentencia se analiza y se almacena en
el paquete una serie de operandos interpretados de forma ms eficiente. En el
timpo de ejecucin, el cdigo que ha generado el precompilador llama a las
API del gestor de bases de datos de servicios de tiempo de ejecucin con la
informacin sobre variables necesaria para la entrada o salida de datos y la
informacin almacenada en el paquete se ejecuta.
Las ventajas de la precompilacin slo se aplican a sentencias de SQL esttico.
Las sentencias de SQL que se ejecutan de forma dinmica (utilizando
PREPARE y EXECUTE o EXECUTE IMMEDIATE) no se precompilan; por lo
tanto, deben pasar por todo el conjunto de pasos de proceso en el tiempo de
ejecucin.
Nota: no d por supuesto que una versin esttica de una sentencia de SQL
se ejecuta automticamente ms rpido que la misma sentencia
procesada de forma dinmica. En algunos casos, SQL esttico es ms
rpido debido al proceso general necesario para preparar la sentencia
dinmica. En otros casos, la misma sentencia preparada de forma
dinmica se ejecuta ms rpido, porque el optimizador puede utilizar
las estadsticas actuales de la base de datos en lugar de las estadsticas
de base de datos disponibles en el momento de la vinculacin anterior.
Observe que si la transaccin tarda menos de un par de segundos en
completarse, SQL esttico suele ser ms rpido. Para elegir el mtodo a
utilizar, debe realiza prototipos de ambas formas de vinculacin.
v SQL dinmico frente a SQL esttico en la pgina 141
Indicaciones horarias generadas por el precompilador
Al generar un paquete o un archivo de vinculacin, el precompilador genera
una indicacin horaria. La indicacin horaria se almacena en el archivo de
vinculacin o paquete y en el archivo fuente modificado. La indicacin horaria
tambin recibe el nombre de smbolo de coherencia.
Cuando una aplicacin se precompila con la vinculacin habilitada, el paquete
y el archivo fuente modificado se generan con indicaciones horarias que
coinciden. Si existen varias versiones de un paquete (utilizando la opcin
PRECOMPILE VERSION), cada versin contendr una indicacin horaria
asociada. Cuando se ejecuta una aplicacin, el nombre del paquete, el creador
y la indicacin horaria se envan al gestor de bases de datos, el cual
comprueba si hay algn paquete cuyo nombre, creador e indicacin horaria
coinciden con los enviados por la aplicacin. Si no existe dicha coincidencia,
se devuelve uno de los siguientes cdigos de error de SQL a la aplicacin:
v SQL0818N (conflicto de indicaciones horarias). Este error se devuelve si se
encuentra un solo paquete que coincide con el nombre y creador (pero no
con el smbolo de coherencia) y el paquete tiene la versin (una serie
vaca)
v SQL0805N (paquete no encontrado). Este error se devuelve en las dems
situaciones.
Recuerde que cuando vincula una aplicacin a una base de datos, los ocho
primeros caracteres del nombre de la aplicacin se utilizan como el nombre
del paquete a no ser que altere temporalmente el valor por omisin utilizando la
opcin PACKAGE USING en el mandato PREP. Asimismo, el ID de versin ser
(una serie vaca), a no ser que se especifique mediante la opcin VERSION
del mandato PREP. Esto significa que si precompila y vincula dos programas
utilizando el mismo nombre sin cambiar el ID de versin, el segundo paquete
sustituir al paquete del primero. Cuando ejecute el primer programa,
obtendr un error de indicacin horaria o de paquete no encontrado porque la
indicacin horaria correspondiente al archivo fuente modificado ya no
coincide con la del paquete ene la base de datos. El error de paquete no
encontrado puede proceder del uso de la opcin de precompilacin o de
vinculacin ACTION REPLACE REPLVER, como en el siguiente ejemplo:
1. Precompile y vincule el paquete SCHEMA1.PKG especificando VERSION
VER1. Luego genere la aplicacin asociada A1.
2. Precompile y vincule el paquete SCHEMA1.PKG, especificando VERSION
VER2 ACTION REPLACE REPLVER VER1. Luego genere la aplicacin
asociada A2.
La segunda precompilacin y vinculacin genera un paquete
SCHEMA1.PKG que tiene para VERSION el valor VER2 y la especificacin
de ACTION REPLACE REPLVER VER1 elimina el paquete
SCHEMA1.PKG que tena para VERSION el valor VER1.
Si se intenta ejecutar la primera aplicacin, se producir una falta de
coincidencia de paquetes y el intento fallar.
Un sntoma parecido sucedera en el siguiente ejemplo:
En este momento es posible ejecutar ambas aplicaciones, A1 y A2, que se
ejecutaran desde los paquetes SCHEMA1.PKG con versiones VER1 y
VER2 respectivamente. Si, por ejemplo, se elimina el primer paquete
(utilizando la sentencia DROP PACKAGE SCHEMA1.PKG VERSION VER1
SQL), el intento de ejecutar la aplicacin A1 fallara con un error de
paquete no encontrado.
Cuando un archivo fuente se precompila pero no se crea un paquete
respectivo, se genera un archivo de vinculacin y un archivo fuente
modificado con indicaciones horarias coincidentes. Para ejecutar la aplicacin,
el archivo de vinculacin se vincula en un paso BIND independiente para
crear un paquete y el archivo fuente modificado se compila y se enlaza. Para
una aplicacin que necesita varios mdulos fuente, el proceso de vinculacin
se debe realizar para cada archivo de vinculacin.
En este escenario de vinculacin diferida, las indicaciones horarias de la
aplicacin y del paquete coinciden porque el archivo de vinculacin contiene
la misma indicacin horaria que el que se almacen en el archivo fuente
modificado durante la precompilacin.
Revinculacin de paquetes
Revincular es el proceso de volver a crear un paquete correspondiente a un
programa de aplicacin que se haba vinculado previamente. Debe revincular
paquetes si se han marcado como no vlidos o no operativos. Sin embargo, en
algunas situaciones es posible que desee revincular paquetes que son vlidos.
Por ejemplo, es posible que desee aprovechar un ndice recin creado o
utilizar estadsticas actualizadas despus de ejecutar el mandato RUNSTATS.
Los paquetes pueden depender de varios tipos de objetos de bases de datos
como tablas, vistas, alias, ndices, activadores, restricciones referenciales y
restricciones de comprobacin de tabla. Si un paquete depende de un objeto
de base de datos (como una tabla, vista, activador, etc) y dicho objeto se
elimina, el paquete se coloca en estado no vlido. Si el objeto que se elimina es
una UDF, el paquete se coloca en estado no operativo.
El gestor de bases de datos revincula de forma implcita (o automtica) los
paquetes no vlidos cuando se ejecutan. Los paquetes no operativos se deben
revincular de forma explcita ejecutando el mandato BIND o el mandato
REBIND. Tenga que cuenta que la revinculacin implcita puede ocasionar
errores inesperados si la revinculacin implcita falla. Es decir, se devuelve el
error de revinculacin implcita en la sentencia que se ejecuta, que puede no
ser la sentencia que realmente contiene el error. Si se intenta ejecutar un
paquete no operativo, se produce un error. Puede decidir revincular de forma
explcita paquetes no vlidos en lugar de dejar que el sistema los revincule
automticamente. Esto le permite controlar cundo se produce la
revinculacin.
La opcin de qu mandato utilizar para revincular de forma explcita un
paquete depende de las circunstancias. Debe utilizar el mandato BIND para
revincular un paquete correspondiente a un programa que se ha modificado
para incluir ms o menos sentencias de SQL o sentencias de SQL modificadas.
Tambin debe utilizar el mandato BIND si tiene que cambiar opciones de
vinculacin con respecto a los valores con los que se vincul originalmente el
paquete. En todos los dems casos, utilice el mandato BIND o REBIND. Debe
utilizar REBIND cuando la situacin no necesite de forma especfica el uso de
BIND, puesto que el rendimiento de REBIND es significativamente mejor que el
de BIND.
Si coexisten varias versiones del mismo nombre de paquete en el catlogo, no
se puede revincular ms una versin simultneamente.
v Statement dependencies when changing objects en el manual
Administration Guide: Implementation
v Mandato REBIND en el manual Consulta de mandatos
Captulo 4. Cmo escribir programas de SQL esttico
Caractersticas de SQL esttico y razones
para utilizarlo . . . . . . . . . . . 101
Ventajas del SQL esttico . . . . . . . 102
Programa de SQL esttico de ejemplo . . . 103
Recuperacin de datos en programas de SQL
esttico . . . . . . . . . . . . . 105
programas de SQL esttico. . . . . . . 106
Variables del lenguaje principal en SQL
esttico . . . . . . . . . . . . 106
principal en programas de SQL esttico . 108
Cmo hacer referencia a variables del
lenguaje principal en programas de SQL
esttico . . . . . . . . . . . . 110
Variables de indicador en programas de SQL
esttico . . . . . . . . . . . . . 110
Inclusin de variables de indicador en
Tipos de datos para variables de
indicador en programas de SQL esttico . 113
Ejemplo de variable de indicador en un
programa de SQL esttico . . . . . . 116
Seleccin de varias filas mediante un cursor 118
Seleccin de varias filas utilizando un
cursor. . . . . . . . . . . . . 118
Consideraciones sobre tipos de cursor y
unidad de trabajo . . . . . . . . . 120
SQL esttico . . . . . . . . . . 122
Manipulacin de datos recuperados. . . . 124
Actualizacin y supresin de datos
recuperados en programas de SQL
esttico . . . . . . . . . . . . 124
Tipos de cursor . . . . . . . . . 125
Ejemplo de captacin en un programa de
SQL esttico . . . . . . . . . . 126
Desplazamiento por datos recuperados y
manipulacin de los mismos . . . . . . 127
Desplazamiento por datos recuperados
previamente . . . . . . . . . . 127
Cmo conservar una copia de los datos 128
Recuperacin de datos por segunda vez 129
Diferencias en el orden de filas entre la
primera y la segunda tabla de resultados . 130
Colocacin de un cursor al final de una
tabla . . . . . . . . . . . . . 131
Actualizacin de datos recuperados
previamente . . . . . . . . . . 131
Ejemplo de insercin, actualizacin y
supresin en un programa de SQL
esttico . . . . . . . . . . . . 132
Informacin de diagnstico . . . . . . 134
Cdigos de retorno . . . . . . . . 134
Informacin de error en los campos
SQLCODE, SQLSTATE y SQLWARN . . 134
Truncamiento de smbolos en la
estructura SQLCA . . . . . . . . 135
Consideraciones sobre el manejador de
excepciones, seales e interrupciones . . 136
Consideraciones sobre rutinas de lista de
salida . . . . . . . . . . . . . 137
Recuperacin de mensajes de error en
una aplicacin . . . . . . . . . . 137
Caractersticas de SQL esttico y razones para utilizarlo
Cuando la sintaxis de las sentencias de SQL incorporado se conoce por
completo en el momento de la precompilacin, las sentencias reciben el
nombre de SQL esttico. Esto es para distinguirlas de las sentencias de SQL
dinmico, cuya sintaxis no se conoce hasta el tiempo de ejecucin.
Nota: SQL esttico no recibe soporte en lenguajes interpretados, como REXX.
La estructura de una sentencia de SQL se debe especificar por completo para
que una sentencia se considere esttica. Por ejemplo, los nombres de las
columnas y tablas a las que se hace referencia en una sentencia se deben
conocer por completo en el momento de la precompilacin. La nica
informacin que se puede especificar en el tiempo de ejecucin son los valores
de las variables del lenguaje principal a las que hace referencia la sentencia.
Sin embargo, la informacin sobre variables del lenguaje principal, como tipos
de datos, debe estar ya precompilada.
Cuando se prepara una sentencia de SQL esttico, se crea un formato
ejecutable de la sentencia y se almacena en el paquete en la base de datos. El
formato ejecutable se puede construir en el momento de la precompilacin o
en un momento de vinculacin posterior. En cualquier caso, la preparacin se
produce antes del tiempo de ejecucin. Se utiliza la autorizacin de la persona
que vincula la aplicacin y la optimizacin se basa en estadsticas de base de
datos y en parmetros de configuracin que pueden no estar actualizados
cuando se ejecuta la aplicacin.
Ventajas del SQL esttico
La programacin utilizando SQL esttico requiere menos esfuerzo que cuando
se utiliza SQL dinmico incorporado. Las sentencias de SQL esttico
simplemente se incorporan en el archivo fuente del lenguaje principal y el
precompilador maneja la conversin necesaria a llamadas a API de servicios
de tiempo de ejecucin del gestor de bases de datos que el compilador del
lenguaje principal pueda procesar.
Puesto que se utiliza la autorizacin de la persona que vincula la aplicacin, el
usuario final no necesita privilegios directos para ejecutar las sentencias del
paquete. Por ejemplo, una aplicacin puede permitir que un usuario actualice
partes de una tabla sin otorgar un privilegio de actualizacin sobre la tabla
entera. Esto se puede conseguir restringiendo las sentencias de SQL esttico
para permitir actualizaciones slo en ciertas columnas o en un rango de
valores.
Las sentencias de SQL esttico son permanentes, lo que significa que las
sentencias duran mientras exista el paquete.
Las sentencias de SQL dinmico se colocan en antememoria hasta que dejan
de ser vlidas, se liberan por razones de gestin de espacio o se cierra la base
de datos. Si hace falta, el compilador de SQL de DB2 vuelve a compilar de
forma implcita las sentencias de SQL dinmico cuando una sentencia
colocada en antememoria deja de ser vlida.
La ventaja clave de SQL esttico, con respecto a permanencia, es que las
sentencias estticas existen despus de que se cierre una determinada base de
datos, mientras que las sentencias de SQL dinmico dejan de existir cuando
esto sucede. Adems, el compilador de SQL de DB2 no tiene que compilar
SQL esttico en el tiempo de ejecucin, mientras que SQL dinmico se tiene
que compilar de forma explcita en el tiempo de ejecucin (por ejemplo,
mediante la sentencia PREPARE). Puesto que DB2 coloca en antememoria
sentencias de SQL dinmico, DB2 no tiene que compilar con frecuencia las
sentencias, aunque se tienen que compilar al menos una vez cuando el
usuario ejecuta la aplicacin.
SQL esttico puede proporcionar ventajas de rendimiento. Para programas de
SQL sencillos de corta ejecucin, una sentencia de SQL esttico se ejecuta ms
rpido que la misma sentencia procesada de forma dinmica porque el
proceso general de preparacin de un formato ejecutable de la sentencia se
realiza en el momento de la precompilacin en lugar de en el tiempo de
ejecucin.
Nota: el rendimiento de SQL esttico depende de las estadsticas de la base
de datos la ltima vez que se vincul la aplicacin. Sin embargo, si
estas estadsticas cambian, el rendimiento de SQL dinmico equivalente
puede ser muy diferente. Si, por ejemplo, se aade un ndice a una base
de datos posteriormente, una aplicacin que utilice SQL esttico no
puede aprovechar el ndice a no ser que se revincule a la base de datos.
Adems, si utiliza variables del lenguaje principal en una sentencia de
SQL esttico, el optimizador no podr aprovechar ninguna de las
estadsticas de distribucin correspondientes a la tabla.
v EXECUTE sentencia en el manual Consulta de SQL, Volumen 2
Programa de SQL esttico de ejemplo
Este programa de ejemplo muestra ejemplos de sentencias de SQL esttico y
llamadas a API del gestor de bases de datos en los lenguajes C/C++, Java y
COBOL.
El ejemplo en C/C++ y Java consulta la tabla org de la base de datos sample
para buscar el nombre de departamento y nmero de departamento que se
encuentra en Nueva York y luego coloca el nombre de departamento y
nmero de departamento en variables del lenguaje principal.
El ejemplo en COBOL consulta la tabla employee de la base de datos sample
para buscar el nombre del empleado cuyo apellido es Johnson y luego coloca
el nombre en una variable del lenguaje principal.
Captulo 4. Cmo escribir programas de SQL esttico 103
Nota: el lenguaje REXX no da soporte a SQL esttico, as que no se
proporciona ningn ejemplo.
v C/C++ (tbread)
SELECT deptnumb, deptname INTO :deptnumb, :deptname
FROM org
WHERE location = New York
Esta consulta est en la funcin TbRowSubselect() del ejemplo. Para obtener
ms informacin, consulte los siguientes ejemplos relacionados.
v Java (TbRead.sqlj)
#sql cur2 = {SELECT deptnumb, deptname
FROM org
WHERE location = New York};
// captar el cursor
#sql {FETCH :cur2 INTO :deptnumb, :deptname};
Esta consulta est en la funcin rowSubselect() del ejemplo TbRead.sqlj.
Para obtener ms informacin, consulte los siguientes ejemplos
relacionados.
v COBOL (static.sqb)
El ejemplo static contiene ejemplos de sentencias de SQL esttico y
llamadas a API del gestor de bases de datos en el lenguaje COBOL. La
sentencia SELECT INTO selecciona una fila de datos de tablas de una base
de datos, y los valores de esta fila se asignan a variables del lenguaje
principal especificadas en la sentencia. Por ejemplo, la siguiente sentencia
distribuye el nombre del empleado cuyo apellido es JOHNSON a la
variable del lenguaje principal firstname:
SELECT FIRSTNME
INTO :firstname
FROM EMPLOYEE
WHERE LASTNAME = JOHNSON
v Recuperacin de datos en programas de SQL esttico en la pgina 105
v Recuperacin de mensajes de error en una aplicacin en la pgina 137
v Declaracin de variables del lenguaje principal en programas de SQL
esttico en la pgina 108
v Seleccin de varias filas utilizando un cursor en la pgina 118
v Configuracin de la base de datos sample en el manual Gua de desarrollo
v SELECT INTO sentencia en el manual Consulta de SQL, Volumen 2
Ejemplos relacionados:
v dtlob.out -- HOW TO USE THE LOB DATA TYPE (C)
v tbinfo.out -- HOW TO GET INFORMATION AT THE TABLE LEVEL (C)
v tbread.out -- HOW TO READ TABLES (C)
v tbread.sqc -- How to read tables (C)
v dtlob.sqC -- How to use the LOB data type (C++)
v tbinfo.sqC -- How to get information at the table level (C++)
v tbread.out -- HOW TO READ TABLES (C++)
v tbread.sqC -- How to read tables (C++)
v static.sqb -- Get table data using static SQL statement (IBM COBOL)
v static.sqb -- Get table data using static SQL statement (MF COBOL)
v TbRead.out -- HOW TO READ TABLE DATA (JDBC)
v TbRead.sqlj -- How to read table data (SQLj)
Recuperacin de datos en programas de SQL esttico
Una de las tareas ms comunes de un programa de aplicacin SQL es
recuperar datos. Esta tarea se lleva a cabo utilizando la sentencia select, que es
una forma de consulta que busca filas de tablas de la base de datos que
cumplen con las condiciones de bsqueda especificadas. Si existen dichas filas,
los datos se recuperan y se colocan en variables especificadas en el programa
de sistema principal, donde se pueden utilizar con el fin para el que est
diseado.
Despus de escribir una sentencia select, codifique las sentencias de SQL que
definen el modo en que la informacin se pasar a la aplicacin.
Puede entender el resultado de una sentencia select como una tabla que tiene
filas y columnas, parecida a una tabla de la base de datos. Si slo se devuelve
una fila, puede distribuir los resultados directamente en variables del lenguaje
principal especificadas por la sentencia SELECT INTO.
Si se devuelve ms de una fila, debe utilizar un cursor para captarlas de una
en una. Un cursor es una estructura de control con nombre que utiliza un
programa de aplicacin para apuntar a una fila especfica dentro de un
conjunto ordenado de filas.
v Variables del lenguaje principal en SQL esttico en la pgina 106
v Ejemplo de un cursor en un programa de SQL esttico en la pgina 122
v Cmo hacer referencia a variables del lenguaje principal en programas de
SQL esttico en la pgina 110
v Inclusin de variables de indicador en programas de SQL esttico en la
pgina 110
v Declaracin y utilizacin de cursores en programas de SQL esttico en la
pgina 119
Variables del lenguaje principal en programas de SQL esttico
Las secciones siguientes describen cmo utilizar variables del lenguaje
principal en programas de SQL esttico.
Variables del lenguaje principal en SQL esttico
Las variables del lenguaje principal son variables a las que hacen referencia las
sentencias de SQL incorporado. Transmiten datos entre el gestor de bases de
datos y un programa de aplicacin. Cuando utilice una variable lenguaje
principal en una sentencia de SQL, debe preceder su nombre con un signo de
dos puntos :). Cuando utilice una variable del lenguaje principal en una
sentencia de lenguaje principal, omita el signo de dos puntos.
Las variables del lenguaje principal se declaran en lenguajes principales
compilados y estn delimitadas por las sentencias BEGIN DECLARE
SECTION y END DECLARE SECTION. Estas sentencias permiten al
precompilador encontrar las declaraciones.
Nota: los programas Java JDBC y SQLj no utilizan secciones declare. Las
variables del lenguaje principal en Java siguen la sintaxis normal de
declaracin de variables Java.
Las variables del lenguaje principal se declaran utilizando un subconjunto del
lenguaje principal.
Las siguientes normas se aplican a secciones de declaracin de variables del
lenguaje principal:
v Todas las variables del lenguaje principal se deben declarar en el archivo
fuente antes de que se haga referencia a las mismas, excepto para las
variables del lenguaje principal que hacen referencia a estructuras SQLDA.
v Se pueden utilizar varias secciones declare en un archivo fuente.
v El precompilador desconoce las normas de establecimiento de mbito de
Con respecto a sentencias de SQL, todas las variables del lenguaje principal
tienen mbito global independientemente de dnde se declaren realmente
en un solo archivo fuente. Por lo tanto, los nombres de variables del
lenguaje principal deben ser exclusivos dentro de un archivo fuente.
Esto no significa que el precompilador de DB2 cambie el mbito de
variables del lenguaje principal por global para que se pueda acceder a las
mismas fuera del mbito en el que se han definido. Supongamos que
tenemos el siguiente ejemplo:
foo1(){
.
.
.
BEGIN SQL DECLARE SECTION;
int x;
END SQL DECLARE SECTION;
x=10;
.
.
.
}
foo2(){
.
.
.
y=x;
.
.
.
}
En funcin del lenguaje, el ejemplo anterior no se podr compilar porque la
variable x no est declarada en la funcin foo2() o el valor de x no se
establecer en 10 en foo2(). Para evitar este problema, debe declarar x
como una variable global o pasar x como parmetro a la funcin foo2() del
siguiente modo:
foo1(){
.
.
.
BEGIN SQL DECLARE SECTION;
int x;
END SQL DECLARE SECTION;
x=10;
foo2(x);
.
.
.
}
foo2(int x){
.
.
.
y=x;
.
.
.
}
v Variables del lenguaje principal en C y C++ en la pgina 183
v Variables del lenguaje principal en COBOL en la pgina 240
v Variables del lenguaje principal en FORTRAN en la pgina 269
v Variables del lenguaje principal en Java en la pgina 290
v Variables del lenguaje principal en REXX en la pgina 374
Declaracin de variables del lenguaje principal en programas de SQL
esttico
Declare variables del lenguaje principal para que el programa se pueda
utilizar para transmitir datos entre el gestor de bases de datos y la aplicacin.
Procedimiento:
Declare las variables del lenguaje principal utilizando la sintaxis
correspondiente al lenguaje principal que est utilizando. La tabla siguiente
contiene ejemplos.
Tabla 4. Declaraciones de variables del lenguaje principal por lenguaje principal
C/C++
double salary;
char CH;
char name1[9], NAME2[9];
/* Comentario de C */
short nul_ind;
Java
// Observe que las declaraciones de variables del lenguaje principal
// Java siguen las normas normales de declaracin de variables Java
// y no tienen equivalente de DECLARE SECTION
double salary;
char CH;
String name1[9], NAME2[9];
/* Comentario de Java */
short nul_ind;
COBOL
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 age PIC S9(4) COMP-5 VALUE 26.
01 DEPT PIC S9(9) COMP-5 VALUE 38.
01 salary PIC S9(6)V9(3) COMP-3.
01 CH PIC X(1).
01 name1 PIC X(8).
01 NAME2 PIC X(8).
* Comentario de COBOL
01 nul-ind PIC S9(4) COMP-5.
EXEC SQL END DECLARE SECTION END-EXEC.
FORTRAN
EXEC SQL BEGIN DECLARE SECTION
integer*2 age /26/
integer*4 dept /38/
real*8 salary
character ch
character*8 name1,NAME2
C Comentario de FORTRAN
integer*2 nul_ind
EXEC SQL END DECLARE SECTION
Cmo hacer referencia a variables del lenguaje principal en programas de
SQL esttico
Despus de declarar la variable del lenguaje principal, puede hacer referencia
a la misma en el programa de aplicacin. Cuando utilice una variable del
lenguaje principal en una sentencia de SQL, preceda su nombre con un signo
de dos puntos (:). Si utiliza una variable del lenguaje principal en una
sentencia del lenguaje principal, omita los dos puntos.
Procedimiento:
Haga referencia a las variables del lenguaje principal utilizando la sintaxis
correspondiente al lenguaje principal que est utilizando. La tabla siguiente
contiene ejemplos.
Tabla 5. Referencias a variables del lenguaje principal por lenguaje principal
C/C++
EXEC SQL FETCH C1 INTO :cm;
printf( "Commission = %f\n", cm );
JAVA (SQLj)
#SQL { FETCH :c1 INTO :cm };
System.out.println("Commission = " + cm);
COBOL
EXEC SQL FETCH C1 INTO :cm END-EXEC
DISPLAY Commission = cm
FORTRAN
EXEC SQL FETCH C1 INTO :cm
WRITE(*,*) Commission = , cm
Variables de indicador en programas de SQL esttico
Las secciones siguientes describen cmo utilizar las variables de indicador en
programas de SQL esttico.
Inclusin de variables de indicador en programas de SQL esttico
Las aplicaciones escritas en lenguajes que no sean Java deben prepararse para
recibir valores nulos asociando una variable de indicador con cualquier variable
del lenguaje principal que pueda recibir un nulo. Las aplicaciones Java
comparan el valor de la variable del lenguaje principal con null de Java para
determinar si el valor recibido es nulo. El gestor de bases de datos y la
aplicacin de sistema principal comparten una variable de indicador; por lo
tanto, la variable de indicador se debe declarar en la aplicacin como una
variable del lenguaje principal. Esta variable del lenguaje principal
corresponde al tipo SMALLINT de datos de SQL.
Una variable de indicador se coloca en una sentencia de SQL inmediatamente
despus de la variable del lenguaje principal y va precedida por dos puntos.
Un espacio puede separar la variable de indicador de la variable del lenguaje
principal, aunque no es necesario. Sin embargo, no coloque una coma entre la
variable del lenguaje principal y la variable de indicador. Tambin puede
especificar una variable de indicador utilizando la palabra clave INDICATOR
opcional, que debe colocar entre la variable del lenguaje principal y su
indicador.
Procedimiento:
Utilice la palabra clave INDICATOR para escribir variables de indicador. La
tabla siguiente contiene ejemplos correspondientes a los lenguajes principales
soportados:
Tabla 6. Variables de indicador por lenguaje principal
C/C++
EXEC SQL FETCH C1 INTO :cm INDICATOR :cmind;
if ( cmind < 0 )
printf( "Commission is NULL\n" );
JAVA (SQLj)
#SQL { FETCH :c1 INTO :cm };
if ( cm == null )
System.out.println( "Commission is NULL\n" );
COBOL
EXEC SQL FETCH C1 INTO :cm INDICATOR :cmind END-EXEC
IF cmind LESS THAN 0
DISPLAY Commission is NULL
FORTRAN
EXEC SQL FETCH C1 INTO :cm INDICATOR :cmind
IF ( cmind .LT. 0 ) THEN
WRITE(*,*) Commission is NULL
ENDIF
En los ejemplos anteriores, cmind se examina para ver si tiene un valor
negativo. Si el valor no es negativo, la aplicacin puede utilizar el valor
devuelto de cm. Si el valor es negativo, el valor captado es NULL y no se
debe utilizar cm. En este caso, el gestor de bases de datos no cambia el valor
de la variable del lenguaje principal.
Nota: si el parmetro de configuracin de base de datos dft_sqlmathwarn tiene
el valor YES, el valor de cmind puede ser -2. Este valor indica un valor
NULL causado por la evaluacin de una expresin con un error
aritmtico o por un desbordamiento al intentar convertir el valor de
resultado numrico en la variable del lenguaje principal.
Si el tipo de datos puede manejar valores NULL, la aplicacin debe
proporcionar un indicador de NULL. De lo contrario, puede producirse un
error. Si no se utiliza un indicador de valor NULL, se devuelve un SQLCODE
-305 (SQLSTATE 22002).
Si la estructura SQLCA indica un aviso de truncamiento, se pueden examinar
las variables de indicador para ver si hay algn truncamiento. Si una variable
de indicador tiene un valor positivo, significa que se ha producido un
truncamiento.
v Si la parte en segundos de un tipo de datos TIME est truncada, el valor
del indicador contiene la parte en segundos de los datos truncados.
v Para todos los dems tipos de datos de serie, excepto para objetos grandes
(LOB), el valor de indicador representa la longitud real de los datos
devueltos. Los tipos diferenciados definidos por el usuario (UDT) se
manejan del mismo modo que su tipo base.
Cuando se procesan sentencias INSERT o UPDATE, el gestor de bases de
datos comprueba la variable de indicador, si la hay. Si la variable de indicador
es negativa, el gestor de bases de datos establece el valor de la columna de
destino en NULL, si se permiten valores NULL.
Si la variable de indicador es cero o positiva, el gestor de bases de datos
utiliza el valor de la variable del lenguaje principal asociada.
El campo SQLWARN1 de la estructura SQLCA puede contener un valor X o W
si el valor de una columna de serie est truncado cuando se asigna a una
variable del lenguaje principal. El campo contiene un valor N si un terminador
de valores nulos est truncado.
El gestor de bases de datos devuelve un valor X slo si se cumplen todas las
condiciones siguientes:
v Existe una conexin de pgina de cdigos combinada en la que la
conversin de datos de serie de caracteres de la pgina de cdigos de la
base de datos a la pgina de cdigos de la aplicacin implica un cambio en
la longitud de los datos.
v Un cursor est bloqueado.
v La aplicacin proporciona una variable de indicador.
El valor devuelto en la variable de indicador tendr la longitud de la serie de
caracteres resultante en la pgina de cdigos de la aplicacin.
En los dems casos en los que interviene un truncamiento de datos (en
contraste con el truncamiento del terminador de valores NULL), el gestor de
bases de datos devuelve un valor W. En este caso, el gestor de bases de datos
devuelve un valor en la variable de indicador a la aplicacin que tiene la
longitud de la serie de caracteres resultante en la pgina de cdigos del
elemento de lista select (la pgina de cdigos de la aplicacin, la pgina de
cdigos de la base de datos o ninguna).
v Tipos de datos para variables de indicador en programas de SQL esttico
en la pgina 113
Tipos de datos para variables de indicador en programas de SQL esttico
A cada columna de cada tabla de DB2 se asigna un tipo de datos de SQL
cuando se crea la columna. Para obtener informacin sobre cmo se asignan
estos tipos a columnas, consulte la sentencia CREATE TABLE. El gestor de
bases de datos da soporte a los siguientes tipos de datos de columna:
SMALLINT
Entero con signo de 16 bits.
INTEGER
Entero con signo de 32 bits. INT se puede utilizar como sinnimo de
este tipo.
BIGINT
Entero con signo de 64 bits.
DOUBLE
Punto flotante de doble precisin. DOUBLE PRECISION y FLOAT(n)
(donde n es mayor que 24) son sinnimos de este tipo.
REAL Punto flotante de precisin sencilla. FLOAT(n) (donde n es menor que
24) es un sinnimo de este tipo.
DECIMAL
Decimal empaquetado. DEC, NUMERIC y NUM son sinnimos de
este tipo.
CHAR
Serie de caracteres de longitud fija comprendida entre 1 byte y 254
bytes. CHARACTER se puede utilizar como sinnimo de este tipo.
VARCHAR
Serie de caracteres de longitud variable comprendida entre 1 byte y
32672 bytes. CHARACTER VARYING y CHAR VARYING son
sinnimos de este tipo.
LONG VARCHAR
Serie de caracteres de longitud variable larga comprendida entre 1
byte y 32700 bytes.
CLOB Serie de caracteres de longitud variable de objetos grandes de
longitud comprendida entre 1 byte y 2 gigabytes.
BLOB Serie binaria de longitud variable de objetos grandes de longitud
comprendida entre 1 byte y 2 gigabytes.
DATE Serie de caracteres de longitud 10 que representa una fecha.
TIME Serie de caracteres de longitud 8 que representa una hora.
TIMESTAMP
Serie de caracteres de longitud 26 que representa una indicacin
horaria.
Los siguientes tipos de datos slo reciben soporte en entornos de juego de
caracteres de doble byte (DBCS) y de juego de caracteres Extended UNIX
Code (EUC):
GRAPHIC
Serie grfica de longitud fija comprendida entre 1 y 127 caracteres de
doble byte.
VARGRAPHIC
Serie grfica de longitud variable comprendida entre 1 y 16.336
caracteres de doble byte.
LONG VARGRAPHIC
Serie grfica de longitud variable larga comprendida entre 1 y 16.350
caracteres de doble byte.
DBCLOB
Serie grfica de longitud variable de objetos grandes de longitud
comprendida entre 1 y 1.073.741.823 caracteres de doble byte.
Notas:
1. Cada tipo de datos soportado puede tener el atributo NOT NULL. Esto se
trata como otro tipo.
2. El conjunto anterior de tipos de datos se puede ampliar definiendo tipos
diferenciados definidos por el usuario (UDT). Los UDT son tipos de datos
separados que utilizan la representacin de uno de los tipos de SQL
integrados.
Los lenguajes principales soportados tienen tipos de datos que corresponden
con la mayora de los tipos de datos del gestor de bases de datos. Slo estos
tipos de datos de lenguajes principales se pueden utilizar en declaraciones de
variables del lenguaje principal. Cuando el precompilador encuentra una
declaracin de variable del lenguaje principal, determina el valor de tipo de
datos de SQL adecuado. El gestor de bases de datos utiliza este valor para
convertir los datos intercambiados entre l mismo y la aplicacin.
Como programador de aplicaciones, es importante que comprenda el modo en
que el gestor de bases de datos maneja comparaciones y asignaciones entre
distintos tipos de datos. Explicado de forma sencilla, los tipos de datos deben
ser compatibles entre s durante las operaciones de asignacin y comparacin,
tanto si el gestor de bases de datos trabaja con dos tipos de datos de
columnas de SQL como si lo hace con dos tipos de datos de lenguaje principal
o con uno de cada.
La norma general de la compatibilidad de tipos de datos establece que todos
los tipos de datos numricos soportados del lenguaje de sistema principal se
pueden comparar y asignar con todos los tipos de datos numricos del gestor
de bases de datos y que todos los tipos de caracteres del lenguaje de sistema
principal son compatibles con todos los tipos de caracteres del gestor de bases
de datos; los tipos numricos son incompatibles con los tipos de caracteres.
Sin embargo, tambin hay algunas excepciones a esta normal general, en
funcin de la idiosincrasia del lenguaje de sistema principal y de las
limitaciones impuestas cuando se trabaja con objetos grandes.
Dentro de sentencias de SQL, DB2 proporciona conversiones entre tipos de
datos compatibles. Por ejemplo, en la siguiente sentencia SELECT, SALARY y
BONUS son columnas de tipo DECIMAL; sin embargo, la compensacin total
de cada empleado se devuelve como datos de tipo DOUBLE:
SELECT EMPNO, DOUBLE(SALARY+BONUS) FROM EMPLOYEE
Observe que la ejecucin de la sentencia anterior incluye la conversin entre
los tipos de datos DECIMAL y DOUBLE.
Para que los resultados de la consulta resulten ms fciles de leer en pantalla,
puede utilizar la siguiente sentencia SELECT:
SELECT EMPNO, DIGIT(SALARY+BONUS) FROM EMPLOYEE
Para convertir datos dentro de la aplicacin, pngase en contacto con el
proveedor del compilador para obtener rutinas, clases, tipos integrados o API
adicionales que den soporte a esta conversin.
Si la pgina de cdigos de la aplicacin no coincide con la pgina de cdigos
de la base de datos, es posible que los tipos de datos de caracteres tambin
estn sujetos a la conversin de caracteres.
v Consideraciones sobre la conversin de datos en el manual Gua de
436
Ejemplo de variable de indicador en un programa de SQL esttico
A continuacin se muestran ejemplos de cmo utilizar programas C/C++ de
variables de indicador que utilizan SQL esttico:
v Ejemplo 1
El siguiente ejemplo muestra la implantacin de variables de indicador en
columnas de datos que pueden tener valores null. En este ejemplo, la
columna FIRSTNAME no puede contener valores null, pero la columna
WORKDEPT s puede.
char wd[3];
short wd_ind;
char firstname[13];
/* conectar con base de datos de ejemplo */
EXEC SQL SELECT FIRSTNME, WORKDEPT
INTO :firstname, :wd:wdind
FROM EMPLOYEE
WHERE LASTNAME = JOHNSON;
Puesto que la columna WORKDEPT puede tener un valor null, se debe
declarar una variable de indicador como una variable del lenguaje principal
antes de que se utilice.
v Ejemplo 2 (dtlob)
El ejemplo dtlob tiene una funcin denominada BlobFileUse(). La funcin
BlobFileUse() contiene una consulta que lee datos BLOB en un archivo
mediante una sentencia SELECT INTO:
SQL TYPE IS BLOB_FILE blobFilePhoto;
char photoFormat[10];
char empno[7];
short lobind;
/* Conectar con la base de datos de ejemplo */
SELECT picture INTO :blobFilePhoto:lobind
FROM emp_photo
WHERE photo_format = :photoFormat AND empno = 000130
Puesto que la columna BLOBFILEPHOTO puede tener un valor null, se
debe declarar una variable de indicador LOBIND como una variable del
lenguaje principal antes de que se utilice. El ejemplo dtlob muestra cmo
trabajar con LOB. Consulte los ejemplos para obtener ms informacin
sobre cmo utilizar LOB.
v Programa de SQL esttico de ejemplo en la pgina 103
v Inclusin de variables de indicador en programas de SQL esttico en la
pgina 110
v Tipos de datos para variables de indicador en programas de SQL esttico
en la pgina 113
v dtlob.out -- HOW TO USE THE LOB DATA TYPE (C)
v dtlob.sqc -- How to use the LOB data type (C)
v dtlob.out -- HOW TO USE THE LOB DATA TYPE (C++)
v dtlob.sqC -- How to use the LOB data type (C++)
Seleccin de varias filas mediante un cursor
Las secciones siguientes describen cmo seleccionar filas mediante un cursor.
Los programas de ejemplo que muestran cmo declarar un cursor, abrir el
cursor, captar filas de la tabla y cerrar el cursor tambin se describen
brevemente.
Seleccin de varias filas utilizando un cursor
Para permitir que una aplicacin recupere un conjunto de filas, SQL utiliza un
mecanismo denominado un cursor.
Para ayudarle a comprender el concepto de un cursor, supongamos que el
gestor de bases de datos crea una tabla de resultados que contenga todas las
filas recuperadas al ejecutar una sentencia SELECT. Un cursor permite que las
filas procedentes de la tabla de resultados estn disponibles para una
aplicacin, identificando o haciendo referencia a una fila actual de esta tabla.
Cuando se utiliza un cursor, una aplicacin puede recuperar cada fila
secuencialmente de la tabla de resultados hasta que se encuentra una
condicin de fin de datos, es decir, se alcanza la condicin NOT FOUND,
SQLCODE +100 (SQLSTATE 02000). El conjunto de filas obtenido como
resultado de ejecutar la sentencia SELECT puede constar de cero, una o ms
filas, en funcin del nmero de filas que cumplan con la condicin de
bsqueda.
Procedimiento:
Los pasos a seguir para procesar un cursor son los siguientes:
1. Especifique el cursor utilizando una sentencia DECLARE CURSOR.
2. Realice la consulta y cree la tabla de resultados utilizando la sentencia
OPEN.
3. Recupere filas de una en una utilizando la sentencia FETCH.
4. Procese las filas con las sentencias DELETE o UPDATE (si hace falta).
5. Termine el cursor utilizando la sentencia CLOSE.
Una aplicacin puede utilizar varios cursores simultneamente. Cada cursor
necesita su propio conjunto de sentencias DECLARE CURSOR, OPEN, CLOSE
y FETCH.
v Ejemplo de un cursor en un programa de SQL esttico en la pgina 122
Declaracin y utilizacin de cursores en programas de SQL esttico
Utilice la sentencia DECLARE CURSOR para definir y nombrar el cursor y
para identificar el conjunto de filas que se tienen que recuperar mediante una
sentencia SELECT.
La aplicacin asigna un nombre para el cursor. Se hace referencia a este
nombre en siguientes sentencias OPEN, FETCH y CLOSE. La consulta es
cualquier sentencia select vlida.
Restricciones:
La ubicacin de la sentencia DECLARE es arbitraria, pero debe estar antes de
la primera vez que se utiliza el cursor.
Procedimiento:
Utilice la sentencia DECLARE para definir el cursor. La tabla siguiente
contiene ejemplos correspondientes a los lenguajes principales soportados:
Tabla 7. Declaraciones de cursor por lenguaje principal
C/C++
EXEC SQL DECLARE C1 CURSOR FOR
SELECT PNAME, DEPT FROM STAFF
WHERE JOB=:host_var;
JAVA (SQLj)
#sql iterator cursor1(host_var data type);
#sql cursor1 = { SELECT PNAME, DEPT FROM STAFF
WHERE JOB=:host_var };
COBOL
SELECT NAME, DEPT FROM STAFF
WHERE JOB=:host-var END-EXEC.
FORTRAN
+ SELECT NAME, DEPT FROM STAFF
+ WHERE JOB=:host_var
v Consideraciones sobre tipos de cursor y unidad de trabajo en la pgina
120
v Tipos de cursor en la pgina 125
Consideraciones sobre tipos de cursor y unidad de trabajo
Las acciones de una operacin COMMIT o ROLLBACK varan para los
cursores en funcin del modo en que stos se declaren:
Cursores de slo lectura
Si se determina que un cursor es de slo lectura y utiliza un nivel de
aislamiento de lectura repetitiva, se siguen obteniendo y manteniendo
bloqueos de lectura repetitiva en las tablas del sistema que necesita la
unidad de trabajo. Por lo tanto, es importante que las aplicaciones
emitan peridicamente sentencias COMMIT, incluso para cursores de
slo lectura.
Opcin WITH HOLD
Si una aplicacin completa una unidad de trabajo emitiendo una
sentencia COMMIT, el gestor de bases de datos cierra todos los cursores
abiertos, excepto aquellos declarados utilizando la opcin WITH
HOLD.
Un cursor declarado con la opcin WITH HOLD mantiene los
recursos a los que accede en varias unidades de trabajo. El efecto
exacto de declarar un cursor WITH HOLD depende del modo en que
finaliza la unidad de trabajo:
v Si la unidad de trabajo finaliza con una sentencia COMMIT, los
cursores definidos con WITH HOLD permanecen abiertos (OPEN).
El cursor se coloca antes de la siguiente fila lgica de la tabla de
resultados. Adems, las sentencias preparadas que hacen referencia
a cursores OPEN definidos con WITH HOLD se retienen. Slo las
peticiones FETCH y CLOSE asociadas con un determinado cursor
son vlidas inmediatamente despus de la sentencia COMMIT. Las
sentencias UPDATE WHERE CURRENT OF y DELETE WHERE
CURRENT OF slo son vlidas para filas captadas dentro de la
misma unidad de trabajo.
Nota: si un paquete se revincula durante una unidad de trabajo,
todos los cursores retenidos se cierran.
v Si la unidad de trabajo finaliza con una sentencia ROLLBACK,
todos los cursores abiertos se cierran, todos los bloqueos adquiridos
durante la unidad de trabajo se liberan y todas las sentencias
preparadas que dependen del trabajo realizado en dicha unidad se
eliminan.
Por ejemplo, supongamos que la tabla TEMPL contiene 1.000 entradas.
Desea actualizar la columna salary correspondiente a todos los
empleados, y espera emitir una sentencia COMMIT cada vez que
actualiza 100 filas.
1. Declare el cursor utilizando la opcin WITH HOLD:
EXEC SQL DECLARE EMPLUPDT CURSOR WITH HOLD FOR
SELECT EMPNO, LASTNAME, PHONENO, JOBCODE, SALARY
FROM TEMPL FOR UPDATE OF SALARY
2. Abra el cursor y recupere datos de la tabla de resultados, fila a
fila:
EXEC SQL OPEN EMPLUPDT
.
.
.
EXEC SQL FETCH EMPLUPDT
INTO :upd_emp, :upd_lname, :upd_tele, :upd_jobcd, :upd_wage,
3. Cuando desee actualizar o suprimir una fila, utilice una sentencia
UPDATE o DELETE utilizando la opcin WHERE CURRENT OF.
Por ejemplo, para actualizar la fila actual, el programa puede
emitir:
EXEC SQL UPDATE TEMPL SET SALARY = :newsalary
WHERE CURRENT OF EMPLUPDT
4. Despus de emitir una sentencia COMMIT, debe emitir una
sentencia FETCH antes de poder actualizar otra fila.
Debe incluir cdigo en la aplicacin para detectar y manejar un
SQLCODE -501 (SQLSTATE 24501), que se puede devolver en una
sentencia FETCH o CLOSE si la aplicacin:
v Utiliza cursores declarados WITH HOLD.
v Ejecuta ms de una unidad de trabajo y deja un cursor WITH
HOLD abierto en los lmites de la unidad de trabajo (COMMIT
WORK).
Si una aplicacin invalida su paquete eliminando una tabla de la que
depende, el paquete se revincula de forma dinmica. En este caso, se
devuelve un SQLCODE -501 (SQLSTATE 24501) para una sentencia
FETCH o CLOSE porque el gestor de bases de datos cierra el cursor.
El modo de manejar un SQLCODE -501 (SQLSTATE 24501) en esta
situacin depende de si desea captar filas desde el cursor:
v Si desea captar filas desde el cursor, abra el cursor y luego ejecute
la sentencia FETCH. Sin embargo, tenga en cuenta que la sentencia
OPEN vuelve a colocar el cursor al principio. La posicin anterior
retenida en la sentencia COMMIT WORK se pierde.
v Si no desea captar filas desde el cursor, no emita ms peticiones
SQL contra el cursor.
Opcin WITH RELEASE
Cuando una aplicacin cierra un cursor utilizando la opcin WITH
RELEASE, DB2 intenta liberar todos los bloqueos de lectura (READ)
que el cursor sigue reteniendo. El cursor slo continuar reteniendo
bloqueos de grabacin (WRITE). Si la aplicacin cierra el cursor sin
utilizar la opcin RELEASE, los bloqueos READ y WRITE se liberarn
cuando finalice la unidad de trabajo.
pgina 119
Ejemplo de un cursor en un programa de SQL esttico
Los ejemplos tut_read.sqc en C, tut_read.sqC/sqx en C++, TutRead.sqlj en
SQLj y cursor.sqb en COBOL muestran cmo declarar un cursor, abrir el
cursor, captar filas de la tabla y cerrar el cursor.
Puesto que REXX no da soporte a SQL esttico, no se proporciona ningn
ejemplo.
v C/C++
El ejemplo tut_read muestra una sentencia select bsica de una tabla que
utiliza un cursor. Por ejemplo:
/* declarar cursor */
EXEC SQL DECLARE c1 CURSOR FOR
SELECT deptnumb, deptname FROM org WHERE deptnumb < 40;
/* abrir cursor */
EXEC SQL OPEN c1 ;
/* captar cursor */
EXEC SQL FETCH c1 INTO :deptnumb, :deptname;
while (sqlca.sqlcode != 100)
{
printf(" %8d %-14s\n", deptnumb, deptname);
EXEC SQL FETCH c1 INTO :deptnumb, :deptname;
}
/* cerrar cursor */
EXEC SQL CLOSE c1;
v Java
El ejemplo TutRead muestra cmo leer datos de una tabla con una sencilla
sentencia select utilizando un cursor. Por ejemplo:
// definicin del cursor
#sql iterator TutRead_Cursor(int, String);
// declarar cursor
TutRead_Cursor cur2;
#sql cur2 = {SELECT deptnumb, deptname FROM org WHERE deptnumb < 40};
// captar cursor
// recuperar y mostrar el resultado de la sentencia SELECT
while (!cur2.endFetch())
{
System.out.println(deptnumb + ", " + deptname);
}
// cerrar cursor
cur2.close();
v COBOL
El ejemplo cursor muestra un ejemplo de cmo recuperar datos de una
tabla utilizando un cursor con una sentencia de SQL esttico. Por ejemplo:
* Declarar un cursor
SELECT name, dept FROM staff
WHERE job=Mgr END-EXEC.
* Abrir el cursor
EXEC SQL OPEN c1 END-EXEC.
* Captar filas de la tabla staff
perform Fetch-Loop thru End-Fetch-Loop
until SQLCODE not equal 0.
* Cerrar el cursor
EXEC SQL CLOSE c1 END-EXEC.
move "CLOSE CURSOR" to errloc.
v Consideraciones sobre tipos de cursor y unidad de trabajo en la pgina
120
pgina 119
v Tipos de cursor en la pgina 125
v cursor.sqb -- How to update table data with cursor statically (IBM
COBOL)
v tut_read.out -- HOW TO READ TABLES (C)
v tut_read.sqc -- How to read tables (C)
v tut_read.out -- HOW TO READ TABLES (C++)
v tut_read.sqC -- How to read tables (C++)
v TutRead.out -- HOW TO READ TABLE DATA (SQLJ)
v TutRead.sqlj -- Read data in a table (SQLj)
Manipulacin de datos recuperados
Las secciones siguientes describen cmo actualizar y suprimir datos
recuperados. Los programas de ejemplo que muestran cmo manipular datos
tambin se describen brevemente.
Actualizacin y supresin de datos recuperados en programas de SQL
esttico
Se puede actualizar y suprimir la fila a la que hace referencia un cursor. Para
que una fila se pueda actualizar, la consulta correspondiente al cursor no debe
ser de slo lectura.
Procedimiento:
Para actualizar con un cursor, utilice la clusula WHERE CURRENT OF en
una sentencia UPDATE. Utilice la clusula FOR UPDATE para indicar al
sistema que desea actualizar algunas columnas de la tabla de resultados.
Puede especificar una columna en la clusula FOR UPDATE sin que est en
fullselect; por lo tanto, puede actualizar columnas que no recupera
explcitamente el cursor. Si la clusula FOR UPDATE se especifica sin nombres
de columna, se considera que todas las columnas de la tabla o vista
identificada en la primera clusula FROM de fullselect externo se pueden
actualizar. No nombre ms columnas de las que necesita en la clusula FOR
UPDATE. En algunos casos, si se nombran columnas adicionales en la
clusula FOR UPDATE, es posible que DB2 sea menos eficiente al acceder a
los datos.
La supresin con un cursor se realiza utilizando la clusula WHERE
CURRENT OF en una sentencia DELETE. En general, la clusula FOR
UPDATE no se necesita para la supresin de la fila actual de un cursor. La
nica excepcin se produce cuando se utiliza SQL dinmico para la sentencia
SELECT o la sentencia DELETE en una aplicacin que se ha precompilado con
el valor SAA1 para LANGLEVEL y se ha vinculado con BLOCKING ALL. En
este caso, se necesita una clusula FOR UPDATE en la sentencia SELECT.
La sentencia DELETE hace que la fila a la que hace referencia el cursor se
suprima. Esta supresin deja el cursor colocado antes de la siguiente fila y se
debe emitir una sentencia FETCH antes de que se puedan realizar operaciones
WHERE CURRENT OF adicionales contra el cursor.
v Consultas en el manual Consulta de SQL, Volumen 1
Tipos de cursor
Los cursores se dividen en tres categoras:
Slo lectura
Las filas del cursor slo se pueden leer, no actualizar. Los cursores de
slo lectura se utilizan cuando una aplicacin slo va a leer datos, no
a modificarlos. Un cursor se considera de slo lectura si se basa en
una sentencia select de slo lectura. Consulte la descripcin sobre
cmo actualizar y recuperar datos correspondientes a normas para
sentencias select que definen tablas de resultados no actualizables.
Puede haber ventajas en cuanto a rendimiento para cursores de slo
lectura.
Actualizables
Las filas del cursor se pueden actualizar. Los cursores actualizables se
utilizan cuando una aplicacin modifica datos a medida que se captan
las filas en el cursor. La consulta especificada slo puede hacer
referencia a una tabla o vista. La consulta tambin debe incluir la
clusula FOR UPDATE, nombrando cada columna que se va a
actualizar (a no ser que se utilice la opcin de precompilacin
LANGLEVEL MIA).
Ambiguos
No se puede determinar si el cursor es actualizable o de slo lectura a
partir de su definicin o contexto. Esta situacin puede producirse
cuando se encuentra una sentencia de SQL dinmico que se podra
utilizar para cambiar un cursor que de otro modo se considerara de
slo lectura.
Un cursor ambiguo se trata como de slo lectura si se especifica la
opcin BLOCKING ALL al precompilar o vincular. De lo contrario, el
cursor se considera actualizable.
Nota: los cursores que se procesan de forma dinmica siempre son
ambiguos.
v Modalidades de cursor soportadas en IBM OLE DB Provider en la pgina
396
v Actualizacin y supresin de datos recuperados en programas de SQL
Ejemplo de captacin en un programa de SQL esttico
En el siguiente ejemplo se efecta una seleccin en una tabla utilizando un
cursor, se abre el cursor y se captan filas de la tabla. Para cada fila captada, el
programa decide, segn criterios sencillos, si la fila se debe suprimir o
actualizar.
El lenguaje REXX no da soporte a SQL esttico, as que no se proporciona
ningn ejemplo.
v C/C++ (tut_mod.sqc/tut_mod.sqC)
El siguiente ejemplo procede del ejemplo tut_mod. En este ejemplo se
efecta una seleccin en una tabla utilizando un cursor, se abre el cursor, se
captan, se actualizan o se suprimen filas de la tabla y luego se cierra el
cursor.
EXEC SQL DECLARE c1 CURSOR FOR SELECT * FROM staff WHERE id >= 310;
EXEC SQL OPEN c1;
EXEC SQL FETCH c1 INTO :id, :name, :dept, :job:jobInd, :years:yearsInd, :salary,
:comm:commInd;
El ejemplo tbmod es una versin ms larga del ejemplo tut_mod y muestra
casi todos los casos posibles de modificacin de datos de la tabla.
v Java (TutMod.sqlj)
El siguiente ejemplo procede del ejemplo TutMod. En este ejemplo se
efecta una seleccin en una tabla utilizando un cursor, se abre el cursor, se
captan, se actualizan o se suprimen filas de la tabla y luego cierra el cursor.
#sql cur = {SELECT * FROM staff WHERE id >= 310};
#sql {FETCH :cur INTO :id, :name, :dept, :job, :years, :salary, :comm};
El ejemplo TbMod es una versin ms larga del ejemplo TutMod y muestra
casi todos los casos posibles de modificacin de datos de la tabla.
v COBOL (openftch.sqb)
El siguiente ejemplo procede del ejemplo openftch. En este ejemplo se
efecta una seleccin en una tabla utilizando un cursor, se abre el cursor y
se captan filas de la tabla.
SELECT name, dept FROM staff
WHERE job=Mgr
FOR UPDATE OF job END-EXEC.
EXEC SQL OPEN c1 END-EXEC
* llamar a FETCH y al bucle UPDATE/DELETE.
v openftch.sqb -- How to modify table data using cursor statically (IBM
COBOL)
v tbmod.sqc -- How to modify table data (C)
v tut_mod.out -- HOW TO MODIFY TABLE DATA (C)
v tut_mod.sqc -- How to modify table data (C)
v tbmod.sqC -- How to modify table data (C++)
v tut_mod.out -- HOW TO MODIFY TABLE DATA (C++)
v tut_mod.sqC -- How to modify table data (C++)
v TbMod.sqlj -- How to modify table data (SQLj)
v TutMod.out -- HOW TO MODIFY TABLE DATA (SQLJ)
v TutMod.sqlj -- Modify data in a table (SQLj)
Desplazamiento por datos recuperados y manipulacin de los mismos
Las secciones siguientes describen cmo desplazarse por datos recuperados.
Los programas de ejemplo que muestran cmo manipular datos tambin se
describen brevemente.
Desplazamiento por datos recuperados previamente
Cuando una aplicacin recupera datos de la base de datos, la sentencia
FETCH le permite desplazarse hacia adelante por los datos; sin embargo, el
gestor de bases de datos no tiene ninguna sentencia de SQL incorporado que
le permita desplazarse hacia atrs por los datos (equivalente a una operacin
FETCH hacia atrs). Sin embargo, las CLI de DB2 y Java dan soporte a una
operacin FETCH hacia atrs por cursores desplazables de slo lectura.
Procedimiento:
Para aplicaciones de SQL incorporado, puede utilizar las siguientes tcnicas
para desplazarse por los datos que se han recuperado:
v Conserve una copia de los datos que se han captado y desplcese por los
mismos mediante alguna tcnica de programacin.
v Utilice SQL para recuperar de nuevo los datos, normalmente mediante una
segunda sentencia SELECT.
v Especificacin JDBC en la pgina 295
v Cmo conservar una copia de los datos en la pgina 128
v Recuperacin de datos por segunda vez en la pgina 129
v SQLFetchScroll Function (CLI) - Fetch Rowset and Return Data for All
Bound Columns en el manual CLI Guide and Reference, Volume 2
v Cursor Positioning Rules for SQLFetchScroll() (CLI) en el manual CLI
Guide and Reference, Volume 2
Cmo conservar una copia de los datos
En algunas situaciones, puede resultar til mantener una copia de los datos
que capta la aplicacin.
Procedimiento:
Para conservar una copia de los datos, la aplicacin puede hacer lo siguiente:
v Guardar los datos captados en almacenamiento virtual.
v Grabar los datos en un archivo temporal (si los datos no caben en
almacenamiento virtual). Un efecto de este enfoque es que un usuario que
se desplace hacia atrs siempre ve exactamente los mismos datos que se
han captado, incluso si mientras tanto una transaccin ha modificado los
datos de la base de datos.
v Utilizando un nivel de aislamiento de lectura repetida, los datos que
recupera de una transaccin se pueden volver a recuperar cerrando y
abriendo un cursor. Otras aplicaciones no pueden actualizar los datos del
conjunto de resultados. Los niveles de aislamiento y el bloqueo pueden
afectar al modo en que los usuarios actualizan datos.
v Diferencias en el orden de filas entre la primera y la segunda tabla de
resultados en la pgina 130
Recuperacin de datos por segunda vez
La tcnica que utilice para recuperar datos por segunda vez depender del
orden en el que desee volver a ver los datos.
Procedimiento:
Puede recuperar datos por segunda vez mediante cualquiera de los mtodos
siguientes:
v Recuperar datos desde el principio
Para volver a recuperar los datos desde el principio de la tabla de
resultados, cierre el cursor activo y vulvalo a abrir. Esta accin coloca el
cursor al principio de la tabla de resultados. Pero, a no ser que la aplicacin
retenga bloqueos en la tabla, es posible que otros la hayan modificado, de
modo que puede que la que era la primera fila de la tabla de resultados ya
no lo sea.
v Recuperar datos desde el medio
Para recuperar datos por segunda vez desde algn punto del medio de la
tabla de resultados, ejecute una segunda sentencia SELECT y declare un
segundo cursor en la sentencia. Por ejemplo, supongamos que la primera
sentencia SELECT era la siguiente:
SELECT * FROM DEPARTMENT
WHERE LOCATION = 'CALIFORNIA'
ORDER BY DEPTNO
Ahora, supongamos que desea volver a las filas que empiezan con DEPTNO =
'M95' y captar de forma secuencial desde dicho punto. Codifique lo
siguiente:
AND DEPTNO >= 'M95'
ORDER BY DEPTNO
Esta sentencia coloca el cursor donde desea.
v Recuperar datos en orden inverso
El valor por omisin consiste en ordenar las filas en orden ascendente. Si
slo hay una fila para cada valor de DEPTNO, la siguiente sentencia especifica
un orden ascendente exclusivo de filas:
ORDER BY DEPTNO
Para recuperar las mismas filas en orden inverso, especifique que el orden
debe ser descendente, como en la siguiente sentencia:
ORDER BY DEPTNO DESC
Un cursor de la segunda sentencia recupera filas exactamente en el orden
inverso al de un cursor de la primera sentencia. El orden de recuperacin
slo se garantiza si la primera sentencia especifica una secuencia de orden
exclusiva.
Para recuperar filas en orden inverso, puede resultar til tener dos ndices
en la columna DEPTNO, uno en orden ascendente y el otro en orden
descendente.
v Diferencias en el orden de filas entre la primera y la segunda tabla de
resultados en la pgina 130
Diferencias en el orden de filas entre la primera y la segunda tabla de
resultados
Puede que las filas de la segunda tabla de resultados no se visualicen en el
mismo orden que en la primera. El gestor de bases de datos no tiene en
cuenta el orden de las filas como algo significativo a no ser que la sentencia
SELECT utilice ORDER BY. Por lo tanto, si hay varias filas con el mismo valor
DEPTNO, puede que la segunda sentencia SELECT las recupere en un orden
distinto al de la primera. La nica garanta es que todas estarn en orden por
nmero de departamento, tal como solicita la clusula ORDER BY DEPTNO.
La diferencia en el orden se puede producir aunque ejecute la misma
sentencia de SQL, con las mismas variables del lenguaje principal, por
segunda vez. Por ejemplo, las estadsticas del catlogo se podran haber
actualizado entre ejecuciones, o se podran hacer creado o eliminado ndices.
Entonces podra ejecutar de nuevo la sentencia SELECT.
Es ms probable que el orden cambie si la segunda sentencia SELECT tiene
un predicado que la primera no tena; el gestor de bases de datos podra
elegir utilizar un ndice en el nuevo predicado. Por ejemplo, podra elegir un
ndice en LOCATION para la primera sentencia de nuestro ejemplo y un ndice
en DEPTNO para la segunda. Puesto que las filas se captan en orden por la
clave de ndice, el segundo orden no es necesariamente igual al primero.
De nuevo, al ejecutar dos sentencias SELECT parecidas se puede producir un
orden diferente de filas, aunque no se haya producido ningn cambio en las
estadsticas ni se haya creado ni eliminado ningn ndice. En el ejemplo, si
hay varios valores diferentes de LOCATION, el gestor de bases de datos podra
elegir un ndice en LOCATION para ambas sentencias. Si se cambia el valor de
DEPTNO en la segunda sentencia por lo siguiente, el gestor de bases de datos
podra elegir un ndice en DEPTNO:
AND DEPTNO >= 'Z98'
ORDER BY DEPTNO
Debido a la sutil relacin entre el formato de una sentencia de SQL y los
valores de dicha sentencia, nunca d por supuesto que dos sentencias de SQL
diferentes vayan a devolver filas en el mismo orden, a no ser que el orden se
determine de forma exclusiva mediante una clusula ORDER BY.
Colocacin de un cursor al final de una tabla
Si tiene que colocar el cursor al final de una tabla, puede utilizar una
sentencia de SQL para colocarlo.
Procedimiento:
Utilice cualquiera de los ejemplos siguientes como mtodo para colocar un
cursor:
v El gestor de bases de datos no garantiza un orden en los datos almacenados
en una tabla; por lo tanto, el final de una tabla no est definido. Sin
embargo, el orden se define en el resultado de una sentencia de SQL:
ORDER BY DEPTNO DESC
v La sentencia siguiente coloca el cursor en la fila que tiene el valor de DEPTNO
ms alto:
WHERE DEPTNO =
(SELECT MAX(DEPTNO) FROM DEPARTMENT)
Sin embargo, observe que, si hay varias filas con el mismo valor, el cursor se
coloca en la primera de ellas.
Actualizacin de datos recuperados previamente
Para desplazarse hacia atrs y actualizar datos recuperados previamente,
puede utilizar una combinacin de las tcnicas que se utilizan para
desplazarse a travs de datos recuperados previamente y para actualizar datos
recuperados.
Procedimiento:
Para actualizar datos recuperados previamente, puede hacer una de estas dos
cosas:
v Si tiene un segundo cursor en los datos que se tienen que actualizar y la
sentencia SELECT no utiliza ninguno de los elementos restringidos, puede
utilizar la sentencia UPDATE controlada por el cursor. Nombre el segundo
cursor en la clusula WHERE CURRENT OF.
v En otros casos, utilice UPDATE con una clusula WHERE que nombre
todos los valores de la fila o especifique la clave primaria de la tabla. Puede
ejecutar una sentencia varias veces con distintos valores de las variables.
v Actualizacin y supresin de datos recuperados en programas de SQL
v Desplazamiento por datos recuperados previamente en la pgina 127
Ejemplo de insercin, actualizacin y supresin en un programa de SQL
esttico
Los siguientes ejemplos muestran cmo insertar, actualizar y suprimir datos
mediante SQL esttico.
v C/C++ (tut_mod.sqc/tut_mod.sqC)
Los tres ejemplos siguientes proceden del ejemplo tut_mod. Consulte este
ejemplo para ver un programa completo que muestra cmo modificar datos
de tablas en C o C++.
El siguiente ejemplo muestra cmo insertar datos de tablas:
EXEC SQL INSERT INTO staff(id, name, dept, job, salary)
VALUES(380, Pearce, 38, Clerk, 13217.50),
(390, Hachey, 38, Mgr, 21270.00),
(400, Wagland, 38, Clerk, 14575.00);
El siguiente ejemplo muestra cmo actualizar datos de tablas:
EXEC SQL UPDATE staff
SET salary = salary + 10000
WHERE id >= 310 AND dept = 84;
El siguiente ejemplo muestra cmo suprimir datos de una tabla:
EXEC SQL DELETE
FROM staff
WHERE id >= 310 AND salary > 20000;
v Java (TutMod.sqlj)
Los tres ejemplos siguientes proceden del ejemplo TutMod. Consulte este
de tablas en SQLj.
#sql {INSERT INTO staff(id, name, dept, job, salary)
VALUES(380, Pearce, 38, Clerk, 13217.50),
(390, Hachey, 38, Mgr, 21270.00),
(400, Wagland, 38, Clerk, 14575.00)};
#sql {UPDATE staff
SET salary = salary + 1000
WHERE id >= 310 AND dept = 84};
#sql {DELETE FROM staff
WHERE id >= 310 AND salary > 20000};
v COBOL (updat.sqb)
Los tres ejemplos siguientes proceden del ejemplo updat. Consulte este
de tablas en COBOL.
EXEC SQL INSERT INTO staff
VALUES (999, Testing, 99, :job-update, 0, 0, 0)
END-EXEC.
EXEC SQL UPDATE staff
SET job=:job-update
WHERE job=Mgr
END-EXEC.
EXEC SQL DELETE
FROM staff
WHERE job=:job-update
END-EXEC.
v tbinfo.out -- HOW TO GET INFORMATION AT THE TABLE LEVEL
(C++)
v tbmod.out -- HOW TO MODIFY TABLE DATA (C++)
v tbmod.sqC -- How to modify table data (C++)
v tut_mod.out -- HOW TO MODIFY TABLE DATA (C++)
v tut_mod.sqC -- How to modify table data (C++)
v tbmod.out -- HOW TO MODIFY TABLE DATA (C)
v tbmod.sqc -- How to modify table data (C)
v tut_mod.out -- HOW TO MODIFY TABLE DATA (C)
v tut_mod.sqc -- How to modify table data (C)
v TbMod.out -- HOW TO MODIFY TABLE DATA (SQLJ)
v TbMod.sqlj -- How to modify table data (SQLj)
v TutMod.out -- HOW TO MODIFY TABLE DATA (SQLJ)
v TutMod.sqlj -- Modify data in a table (SQLj)
Informacin de diagnstico
Las secciones siguientes describen la informacin de diagnstico disponible
para un programa de SQL esttico, como cdigos de retorno, y cmo debe la
aplicacin recuperar mensajes de error.
Cdigos de retorno
La mayora de las API del gestor de bases de datos devuelven un cdigo de
retorno cero cuando se ejecutan satisfactoriamente. En general, un cdigo de
retorno distinto de cero indica que el mecanismo de manejo de errores
secundarios, la estructura SQLCA, puede estar daado. En este caso, la API
llamada no se ejecuta. Una posible razn de que se dae la estructura SQLCA
es que se haya pasado una direccin no vlida para la estructura.
v SQLCA en el manual Administrative API Reference
Informacin de error en los campos SQLCODE, SQLSTATE y SQLWARN
La informacin de error se devuelve en los campos SQLCODE y SQLSTATE
de la estructura SQLCA, que se actualiza tras cada sentencia de SQL
ejecutable y tras la mayora de las llamadas a API del gestor de bases de
datos.
Un archivo fuente que contiene sentencias de SQL ejecutables puede
proporcionar al menos una estructura SQLCA con el nombre sqlca. La
estructura SQLCA se define en el archivo include SQLCA. Los archivos fuente
sin sentencias de SQL incorporado, pero que llaman a las API del gestor de
bases de datos, tambin pueden proporcionar una o ms estructuras SQLCA,
pero sus nombres son arbitrarios.
Si la aplicacin cumple con el estndar FIPS 127-2, puede declarar SQLSTATE
y SQLCODE como variables del lenguaje principal para aplicaciones C, C++,
COBOL y FORTRAN, en lugar de utilizar la estructura SQLCA.
Un valor SQLCODE igual a 0 significa una ejecucin satisfactoria (con
posibles condiciones de aviso SQLWARN). Un valor positivo significa que la
sentencia se ha ejecutado satisfactoriamente pero con un aviso, como el
truncamiento de una variable del lenguaje principal. Un valor negativo
significa que se ha producido una condicin de error.
Un campo adicional, SQLSTATE, contiene un cdigo de error estandarizado
coherente con otros productos de bases de datos de IBM y con otros gestores
de bases de datos que cumplen con SQL92. En la prctica, debe utilizar
SQLSTATE cuando le preocupe la portabilidad, puesto que los SQLSTATE son
comunes entre varios gestores de bases de datos.
El campo SQLWARN contiene una matriz de indicadores de aviso, incluso si
SQLCODE es cero. El primer elemento de la matriz SQLWARN, SQLWARN0,
contiene un blanco si todos los dems elementos estn en blanco. SQLWARN0
contiene una W si al menos uno de los otros elementos contiene un carcter de
aviso.
Nota: si desea desarrollar aplicaciones que acceden a varios servidores
RDBMS de IBM, debe:
v Si es posible, hacer que las aplicaciones comprueben SQLSTATE en
lugar de SQLCODE.
v Si la aplicacin va a utilizar DB2 Connect, considerar la posibilidad
de utilizar el recurso de correlacin que proporciona DB2 Connect
para correlacionar conversiones de SQLCODE entre bases de datos
distintas.
Truncamiento de smbolos en la estructura SQLCA
Puesto que los smbolos se pueden truncar en la estructura SQLCA, no debe
utilizar la informacin de smbolos cuando realice diagnsticos. Aunque
puede definir nombres de tabla y de columna con longitudes de hasta 128
bytes, los smbolos de SQLCA se truncarn a 17 bytes ms un terminador de
truncamiento (>). La lgica de la aplicacin no debera depender de los
valores reales del campo sqlerrmc.
Consideraciones sobre el manejador de excepciones, seales e
interrupciones
Un manejador de excepciones, seales o interrupciones es una rutina que
adquiere el control cuando se produce una excepcin, seal o interrupcin. El
tipo de manejador aplicable lo determina el entorno operativo, tal como se
muestra a continuacin:
Sistemas operativos Windows
Al pulsar Control-C o Control-Inter se genera una interrupcin.
Sistemas basados en UNIX
Generalmente, al pulsar Control-C se genera una seal de
interrupcin SIGINT. Observe que los teclados se pueden redefinir
fcilmente de modo que se pueda generar una seal SIGINT pulsando
otra secuencia de teclas en la mquina.
No coloque sentencias de SQL (que no sean COMMIT o ROLLBACK) en
manejadores de excepciones, seales e interrupciones. Con estos tipos de
condiciones de error, generalmente desear llevar a cabo una operacin
ROLLBACK para evitar el riesgo de tener datos incoherentes.
Tenga en cuenta que debe tener cuidado cuando codifique COMMIT y
ROLLBACK en manejadores de excepciones/seales/interrupciones. Si llama
a cualquiera de estas sentencias por ellas mismas, la operacin COMMIT o
ROLLBACK no se ejecuta hasta que se completa la sentencia de SQL actual, si
se est ejecutando alguna. Este no es el comportamiento deseado de un
manejador Control-C.
La solucin consiste en llamar a la API INTERRUPT (sqleintr/sqlgintr)
antes de emitir una operacin ROLLBACK. Esta API interrumpe la consulta
de SQL actual (si la aplicacin est ejecutando alguna) y deja que ROLLBACK
comience de inmediato. Si va a realizar una operacin COMMIT en lugar de
ROLLBACK, no desea interrumpir el mandato actual.
Cuando se utiliza APPC para acceder a un servidor de base de datos remoto
(DB2 para AIX o el sistema de bases de datos de sistema principal que utiliza
DB2 Connect), es posible que la aplicacin reciba una seal SIGUSR1. SNA
Services/6000 genera esta seal cuando se produce un error no recuperable y
la conexin SNA se detiene. Es posible que desee instalar un manejador de
seales en la aplicacin para que maneje SIGUSR1.
Consulte la documentacin de su plataforma para ver detalles especficos
sobre consideraciones sobre distintos manejadores.
v Proceso de peticiones de interrupcin en la pgina 532
Consideraciones sobre rutinas de lista de salida
No utilice SQL ni llamadas a API de DB2 en rutinas de lista de salida. Tenga
en cuenta que no puede desconectarse de una base de datos en una rutina de
salida.
Recuperacin de mensajes de error en una aplicacin
En funcin del lenguaje en el que est escrita la aplicacin, debe utilizar un
mtodo u otro para recuperar informacin de error:
v Las aplicaciones C, C++ y COBOL pueden utilizar la API GET ERROR
MESSAGE para obtener la informacin correspondiente relacionada con el
SQLCA que se ha pasado.
v Las aplicaciones JDBC y SQLj emiten una SQLException cuando se produce
un error durante el proceso de SQL. Las aplicaciones pueden obtener y
visualizar una SQLException con el siguiente cdigo:
try {
Statement stmt = connection.createStatement();
int rowsDeleted = stmt.executeUpdate(
"DELETE FROM employee WHERE empno = 000010");
System.out.println( rowsDeleted + " rows were deleted");
}
catch (SQLException sqle) {
System.out.println(sqle);
}
v Las aplicaciones REXX utilizan el procedimiento CHECKERR.
v sqlaintp - Get Error Message en el manual Administrative API Reference
Captulo 5. Cmo escribir programas de SQL dinmico
Caractersticas y razones para utilizar SQL
dinmico. . . . . . . . . . . . . 139
Razones para utilizar SQL dinmico . . 139
Sentencias de soporte de SQL dinmico 140
SQL dinmico frente a SQL esttico . . . 141
Cursores en programas de SQL dinmico 144
SQL dinmico . . . . . . . . . . 145
Efectos de DYNAMICRULES en SQL
dinmico. . . . . . . . . . . . . 147
El SQLDA en programas de SQL dinmico 150
Variables del lenguaje principal en el
SQLDA en programas de SQL dinmico . 150
Declaracin de la estructura SQLDA en
Preparacin de una sentencia de SQL
dinmico utilizando la estructura SQLDA
mnima . . . . . . . . . . . . 153
Asignacin de un SQLDA con suficientes
entradas SQLVAR para un programa de
SQL dinmico . . . . . . . . . . 155
Descripcin de una sentencia SELECT en
Adquisicin de almacenamiento para
albergar una fila . . . . . . . . . 157
Proceso del cursor en un programa de
SQL dinmico . . . . . . . . . . 158
Asignacin de una estructura SQLDA
para un programa de SQL dinmico . . 158
Transferencia de datos en un programa de
SQL dinmico mediante una estructura
SQLDA . . . . . . . . . . . . 162
Proceso de sentencias interactivas de SQL
en programas de SQL dinmico . . . . 163
Determinacin del tipo se sentencia en
Proceso de sentencias SELECT de lista de
variables en programas de SQL dinmico . 164
Cmo guardar peticiones de SQL
procedentes de usuarios finales . . . . . 165
Marcadores de parmetros en programas de
SQL dinmico . . . . . . . . . . . 166
Cmo proporcionar entrada de variables
a SQL dinmico mediante marcadores de
parmetros . . . . . . . . . . . 166
Ejemplo de marcadores de parmetros en
Comparacin entre Interfaz de nivel de
llamada (CLI) de DB2 y SQL dinmico. . . 169
Interfaz de nivel de llamada de DB2 (CLI)
frente a SQL dinmico incorporado . . . 169
Ventajas de CLI de DB2 sobre SQL
incorporado. . . . . . . . . . . 171
Cundo utilizar CLI de DB2 o SQL
incorporado. . . . . . . . . . . 173
Caractersticas y razones para utilizar SQL dinmico
Las secciones siguientes describen las razones para utilizar SQL dinmico, en
comparacin con SQL esttico.
Razones para utilizar SQL dinmico
Es posible que desee utilizar SQL dinmico si:
v Necesita que toda la sentencia de SQL, o parte de la misma, se genere
durante la ejecucin de la aplicacin.
v Los objetos a los que hace referencia la sentencia de SQL no existen en el
momento de la precompilacin.
v Desea que la sentencia siempre utilice la va de acceso ptima, segn las
estadsticas actuales de la base de datos.
v Desea modificar el entorno de compilacin de la sentencia, es decir,
experimentar con los registros especiales.
v Sentencias de soporte de SQL dinmico en la pgina 140
v SQL dinmico frente a SQL esttico en la pgina 141
Sentencias de soporte de SQL dinmico
Las sentencias de soporte de SQL dinmico aceptan una variable del lenguaje
principal de serie de caracteres y un nombre de sentencia como argumentos.
La variable del lenguaje principal contiene la sentencia de SQL que se va a
procesar de forma dinmica en formato de texto. El texto de la sentencia no se
procesa cuando se precompila una aplicacin. De hecho, el texto de la
sentencia no tiene que existir en el momento en que se precompila la
aplicacin. En su lugar, la sentencia de SQL se trata como una variable del
lenguaje principal con fines de precompilacin y se hace referencia a la
variable durante la ejecucin de la aplicacin. Estas sentencias de SQL se
denominan SQL dinmico.
Se necesitan sentencias de soporte de SQL dinmico para transformar la
variable del lenguaje principal que contiene texto de SQL en un formato
ejecutable y trabajar en el mismo haciendo referencia al nombre de la
sentencia. Estas sentencias son:
EXECUTE IMMEDIATE
Prepara y ejecuta una sentencia que no utiliza ninguna variable del
lenguaje principal. Todas las sentencias EXECUTE IMMEDIATE de
una aplicacin se colocan en antememoria en el mismo lugar en el
tiempo de ejecucin, de modo que slo se conoce la ltima sentencia.
Utilice esta sentencia como alternativa a las sentencias PREPARE y
EXECUTE.
PREPARE
Convierte el formato de serie de caracteres de la sentencia de SQL en
un formato ejecutable de la sentencia, asigna un nombre de sentencia
y opcionalmente coloca informacin sobre la sentencia en una
estructura SQLDA.
EXECUTE
Ejecuta una sentencia de SQL previamente preparada. La sentencia se
puede ejecutar repetidamente dentro de una conexin.
DESCRIBE
Coloca informacin sobre una sentencia preparada en una SQLDA.
Una aplicacin puede ejecutar la mayora de las sentencias de SQL soportadas
de forma dinmica.
Nota: el contenido de las sentencias de SQL dinmico siguen la misma
sintaxis que las sentencias de SQL esttico, con las siguientes
excepciones:
v No se permiten comentarios.
v La sentencia no puede comenzar por EXEC SQL.
v La sentencia no puede finalizar con el terminador de sentencia. Una
excepcin a esta norma es la sentencia CREATE TRIGGER, que
puede contener un signo de punto y coma (;).
SQL dinmico frente a SQL esttico
La pregunta sobre si utilizar SQL esttico o dinmico para optimizar el
rendimiento suele resultar de gran inters para los programadores. La
respuesta depende de la situacin.
Utilice la tabla siguiente para decidir si utilizar SQL esttico o dinmico.
Consideraciones como seguridad indican utilizar SQL esttico, mientras que
consideraciones de entorno (por ejemplo, utilizar CLI de DB2 o el CLP)
indican utilizar SQL dinmico. Cuando tome su decisin, tenga en cuenta las
siguientes recomendaciones sobre si se debe elegir SQL esttico o dinmico en
una determinada situacin. En la tabla siguiente, 'Cualquiera' significa que no
hay ninguna ventaja en utilizar SQL esttico o dinmico.
Nota: esta tabla contiene recomendaciones generales. La aplicacin especfica,
el uso para el que est pensada y el entorno de trabajo dictan la opcin
real. Cuando tenga dudas, el mejor enfoque consiste en hacer
prototipos de sus sentencias como SQL esttico, luego como SQL
dinmico y luego comparar las diferencias.
Tabla 8. Comparacin entre SQL esttico y dinmico
Consideraciones Probablemente
la mejor opcin
Tiempo de ejecucin de la sentencia de SQL:
v Menos de 2 segundos
v Entre 2 y 10 segundos
v Ms de 10 segundos
v Esttico
v Cualquiera
v Dinmico
Uniformidad de datos
v Distribucin de datos uniforme
v Ligera falta de uniformidad
v Distribucin nada uniforme
v Esttico
v Cualquiera
v Dinmico
Captulo 5. Cmo escribir programas de SQL dinmico 141
Tabla 8. Comparacin entre SQL esttico y dinmico (continuacin)
Consideraciones Probablemente
la mejor opcin
Predicados de rango (<,>,BETWEEN,LIKE)
v Muy poco frecuentes
v Ocasionales
v Frecuentes
v Esttico
v Cualquiera
v Dinmico
Ejecucin repetitiva
v Se ejecuta muchas veces (10 o ms)
v Se ejecuta unas cuantas veces (menos de 10)
v Se ejecuta una vez
v Cualquiera
v Cualquiera
v Esttico
Naturaleza de la consulta
v Aleatoria
v Permanente
v Dinmico
v Cualquiera
Entorno de tiempo de ejecucin (DML/DDL)
v Proceso de transacciones (slo DML)
v Mixto (DML y DDL - DDL afecta a los paquetes)
v Mixto (DML y DDL - DDL no afecta a los paquetes)
v Cualquiera
v Dinmico
v Cualquiera
Frecuencia de RUNSTATS
v Muy poco frecuente
v Regular
v Frecuente
v Esttico
v Cualquiera
v Dinmico
En general, una aplicacin que utiliza SQL dinmico tiene un coste de partida
(inicial) superior por sentencia de SQL debido a la necesidad de compilar las
sentencias de SQL antes de utilizarlas. Una vez compiladas, el tiempo de
ejecucin de SQL dinmico comparado con SQL esttico debe ser equivalente
y, en algunos casos, ms rpido debido a que el optimizador elige mejores
planes de acceso. Cada vez que se ejecuta una sentencia dinmica, el coste de
compilacin inicial pierde importancia. Si varios usuarios ejecutan la misma
aplicacin dinmica con las mismas sentencias, el coste de compilacin de la
sentencia slo se aplica a la primera aplicacin que emite la sentencia.
En un entorno DML y DDL mixto, el coste de compilacin correspondiente a
una sentencia de SQL dinmico puede variar puesto que es posible que el
sistema recompile de forma implcita la sentencia mientras se ejecuta la
aplicacin. En un entorno mixto, la opcin entre SQL esttico y dinmico debe
depender tambin de la frecuencia con la que se invalidan paquetes. Si el
DDL no invalida paquetes, es posible que SQL dinmico resulte ms eficiente
puesto que slo las consultas ejecutadas se recompilan cuando se utilizan la
siguiente vez. Las otras no se recompilan. Para SQL esttico, el paquete entero
se revincula cuando se ha invalidado.
Ahora supongamos que su aplicacin particular contiene una combinacin de
las caractersticas anteriores y algunas de estas caractersticas sugieren que
utilice SQL esttico y otras que utilice SQL dinmico. En este caso, no hay
ninguna decisin obvia y probablemente deba utilizar el mtodo con el que
tenga ms experiencia y con el que se sienta ms cmodo. Observe que las
consideraciones de la tabla anterior se listan en lneas generales por orden de
importancia.
Nota: tanto SQL esttico como SQL dinmico vienen en dos tipos que
constituyen una diferencia para el optimizador de DB2. Estos tipos son:
1. SQL esttico que no contiene variables del lenguaje principal
Esta es una situacin poco probable que slo ver para:
v Cdigo de inicializacin
v Ejemplos de formacin para principiantes
Realmente es la mejor combinacin, desde la perspectiva del
rendimiento, puesto que no hay proceso general de rendimiento en
tiempo de ejecucin y se pueden aprovechar por completo las
funciones del optimizador de DB2.
2. SQL esttico que contiene variables del lenguaje principal
Es el estilo antiguo tradicional de las aplicaciones de DB2. Evita el
proceso general en tiempo de ejecucin de una sentencia PREPARE
y bloqueos de catlogo adquiridos durante la compilacin de
sentencias. Desgraciadamente, no se puede utilizar la potencia
completa del optimizador porque este no conoce la sentencia de
SQL completa. Existe un problema particular con distribuciones de
datos nada uniformes.
3. SQL dinmico que no contiene marcadores de parmetros
Es el estilo tpico para interfaces de consultas aleatorias (como el
CLP) y es el estilo de SQL preferido del optimizador. Para consultas
complejas, el proceso general de la sentencia PREPARE queda
compensado por la mejora en el tiempo de ejecucin.
4. SQL dinmico que contiene marcadores de parmetros
Es el tipo ms comn de SQL para aplicaciones CLI. La ventaja
clave es que la presencia de marcadores de parmetros permite
amortizar el coste de la sentencia PREPARE durante ejecuciones
repetidas de la sentencia, normalmente una sentencia select o insert.
Esta amortizacin es real para todas las aplicaciones de SQL
dinmico repetitivas. Desgraciadamente, al igual que SQL esttico
con variables del lenguaje principal, partes del optimizador de DB2
no funcionarn porque no est disponible la informacin completa.
La recomendacin es utilizar SQL esttico con variables del lenguaje
principal o SQL dinmico sin marcadores de parmetros como las
opciones ms eficientes.
v Ejemplo de marcadores de parmetros en un programa de SQL dinmico
en la pgina 167
v Cmo proporcionar entrada de variables a SQL dinmico mediante
marcadores de parmetros en la pgina 166
Cursores en programas de SQL dinmico
Las secciones siguientes describen cmo declarar y utilizar cursores en SQL
dinmico y describen brevemente los programas de ejemplo que utilizan
cursores.
Declaracin y utilizacin de cursores en programas de SQL dinmico
Procesar un cursor de forma dinmica es casi idntico a procesarlo mediante
SQL esttico. Cuando se declara un cursor, se asocia con una consulta.
En SQL esttico, la consulta es una sentencia SELECT en formato de texto,
mientras que en SQL dinmico la consulta se asocia con un nombre de
sentencia asignado en una sentencia PREPARE. Cualquier variable del
lenguaje principal a la que se haga referencia se representa mediante
marcadores de parmetros.
La principal diferencia entre un cursor esttico y uno dinmico es que un
cursor esttico se prepara en el momento de la precompilacin y un cursor
dinmico se prepara en el tiempo de ejecucin. Adems, las variables del
lenguaje principal a las que se hace referencia en la consulta estn
representadas mediante marcadores de parmetros, los cuales se sustituyen
por variables del lenguaje principal de tiempo de ejecucin cuando se abre el
cursor.
Procedimiento:
Utilice los ejemplos que se muestran en la tabla siguiente cuando codifique
cursores para un programa de SQL dinmico:
Tabla 9. Sentencia declare asociada con una sentencia SELECT dinmica
C/C++
strcpy( prep_string, "SELECT tabname FROM syscat.tables"
"WHERE tabschema = ?" );
EXEC SQL PREPARE s1 FROM :prep_string;
EXEC SQL DECLARE c1 CURSOR FOR s1;
EXEC SQL OPEN c1 USING :host_var;
Java (JDBC)
PreparedStatement prep_string = ("SELECT tabname FROM syscat.tables
WHERE tabschema = ?" );
prep_string.setCursor("c1");
prep_string.setString(1, host_var);
ResultSet rs = prep_string.executeQuery();
COBOL
MOVE "SELECT TABNAME FROM SYSCAT.TABLES WHERE TABSCHEMA = ?"
TO PREP-STRING.
EXEC SQL PREPARE S1 FROM :PREP-STRING END-EXEC.
EXEC SQL DECLARE C1 CURSOR FOR S1 END-EXEC.
EXEC SQL OPEN C1 USING :host-var END-EXEC.
FORTRAN
prep_string = SELECT tabname FROM syscat.tables WHERE tabschema = ?
EXEC SQL PREPARE s1 FROM :prep_string
EXEC SQL DECLARE c1 CURSOR FOR s1
EXEC SQL OPEN c1 USING :host_var
v Ejemplo de un cursor en un programa de SQL dinmico en la pgina 145
v Cursores en REXX en la pgina 381
Ejemplo de un cursor en un programa de SQL dinmico
Una sentencia de SQL dinmico se puede preparar para su ejecucin con la
sentencia PREPARE y se puede ejecutar con la sentencia EXECUTE o con la
sentencia DECLARE CURSOR.
PREPARE con EXECUTE
El siguiente ejemplo muestra cmo se puede preparar una sentencia de SQL
dinmico para su ejecucin con la sentencia PREPARE y ejecutar con la
sentencia EXECUTE:
v C/C++ (dbuse.sqc/dbuse.sqC):
El siguiente ejemplo procede del ejemplo dbuse:
char hostVarStmt[50];
strcpy(hostVarStmt, "DELETE FROM org WHERE deptnumb = 15");
EXEC SQL PREPARE Stmt FROM :hostVarStmt;
EXEC SQL EXECUTE Stmt;
PREPARE con DECLARE CURSOR
Los ejemplos siguientes muestran cmo se puede preparar una sentencia de
SQL dinmico para su ejecucin con la sentencia PREPARE y ejecutar con la
sentencia DECLARE CURSOR:
v C
char st[80];
char parm_var[19};
strcpy( st, "SELECT tabname FROM syscat.tables" );
strcat( st, " WHERE tabname <> ? ORDER BY 1" );
EXEC SQL PREPARE s1 FROM :st;
EXEC SQL DECLARE c1 CURSOR FOR s1;
strcpy( parm_var, "STAFF" );
EXEC SQL OPEN c1 USING :parm_var;
v Java
PreparedStatement pstmt1 = con.prepareStatement(
"SELECT tabname FROM syscat.tables " +
"WHERE tabname <> ? ORDER BY 1");
// definir nombre de cursor para la sentencia update posicionada
pstmt1.setCursorName("c1");
pstmt1.setString(1, "STAFF");
ResultSet rs = pstmt1.executeQuery();
v COBOL (dynamic.sqb)
El siguiente ejemplo procede del ejemplo dynamic.sqb:
01 st pic x(80).
01 parm-var pic x(18).
move "SELECT TABNAME FROM SYSCAT.TABLES ORDER BY 1 WHERE TABNAME <> ?" to st.
EXEC SQL PREPARE s1 FROM :st END-EXEC.
EXEC SQL DECLARE c1 CURSOR FOR s1 END-EXEC.
move "STAFF" to parm-var.
EXEC SQL OPEN c1 USING :parm-var END-EXEC.
EXECUTE IMMEDIATE
Tambin puede preparar y ejecutar una sentencia de SQL dinmico con la
sentencia EXECUTE IMMEDIATE (excepto para las sentencias SELECT que
devuelven ms de una fila).
v C/C++ (dbuse.sqc/dbuse.sqC)
El siguiente ejemplo procede de la funcin
DynamicStmtEXECUTE_IMMEDIATE() del ejemplo dbuse:
char stmt1[50];
strcpy(stmt1, "CREATE TABLE table1(col1 INTEGER)");
EXEC SQL EXECUTE IMMEDIATE :stmt1;
v dbuse.out -- HOW TO USE A DATABASE (C)
v dbuse.sqc -- How to use a database (C)
v dbuse.out -- HOW TO USE A DATABASE (C++)
v dbuse.sqC -- How to use a database (C++)
Efectos de DYNAMICRULES en SQL dinmico
La opcin DYNAMICRULES de PRECOMPILE y BIND determina los valores
que se aplicarn en el tiempo de ejecucin para los siguientes atributos de
SQL:
v El ID de autorizacin que se utiliza durante la comprobacin de
autorizacin.
v El calificador que se utiliza para la calificacin de objetos no calificados.
v Si el paquete se puede utilizar para preparar de forma dinmica las
siguientes sentencias: GRANT, REVOKE, ALTER, CREATE, DROP,
COMMENT ON, RENAME, SET INTEGRITY y SET EVENT MONITOR
STATE.
Adems del valor de DYNAMICRULES, el entorno de tiempo de ejecucin de
un paquete controla el modo en que las sentencias de SQL se comportan en el
tiempo de ejecucin. Los dos posibles entornos de tiempo de ejecucin son:
v El paquete se ejecuta como parte de un programa autnomo
v El paquete se ejecuta dentro de un contexto de rutina
La combinacin del valor de DYNAMICRULES y del entorno de tiempo de
ejecucin determina los valores correspondientes a los atributos de SQL
dinmico. Este conjunto de valores de atributos se denomina el
comportamiento de las sentencias de SQL dinmico. Los cuatro
comportamientos son:
Comportamiento de ejecucin
DB2 utiliza el ID de autorizacin del usuario (el ID que
inicialmente se conect a DB2) que ejecuta el paquete como el
valor que se va a utilizar para la comprobacin de
autorizacin de sentencias de SQL dinmico y para el valor
inicial utilizado para la calificacin implcita de referencias a
objetos no calificados dentro de sentencias de SQL dinmico.
Comportamiento de vinculacin
En el tiempo de ejecucin, DB2 utiliza todas las normas que se
aplican a SQL esttico para la autorizacin y calificacin. Es
decir, se toma el ID de autorizacin del propietario del
paquete como el valor que se va a utilizar para la
comprobacin de autorizacin de sentencias de SQL dinmico
y el calificador por omisin del paquete para la calificacin
implcita de referencias a objetos no calificados dentro de
sentencias de SQL dinmico.
Comportamiento de definicin
El comportamiento de definicin slo se aplica si la sentencia
de SQL dinmico est en un paquete que se ejecuta dentro de
un contexto de rutina y el paquete se vincul con
DYNAMICRULES DEFINEBIND o DYNAMICRULES
DEFINERUN. DB2 utiliza el ID de autorizacin del definidor
de la rutina (no el vinculador de paquetes de la rutina) como
el valor que se va a utilizar para la comprobacin de
autorizacin de sentencias de SQL dinmico y para la
calificacin implcita de referencias a objetos no calificados
dentro de sentencias de SQL dinmico contenidas en dicha
rutina.
Comportamiento de invocacin
El comportamiento de invocacin slo se aplica si la sentencia
de SQL dinmico est en un paquete que se ejecuta dentro de
un contexto de rutina y el paquete se vincul con
DYNAMICRULES INVOKEBIND o DYNAMICRULES
INVOKERUN. DB2 utiliza el ID de autorizacin de sentencias
actualmente en vigor cuando se invoca la rutina como el valor
que se va a utilizar para la comprobacin de autorizacin de
SQL dinmico y para la calificacin implcita de referencias a
objetos no calificados dentro de sentencias de SQL dinmico
contenidas en dicha rutina. Esto se resume en la tabla
siguiente:
Entorno de invocacin ID utilizado
Cualquier SQL esttico Valor implcito o explcito del propietario
(OWNER) del paquete del que procede el
SQL que invoca la rutina.
Utilizado en definicin de vista o
activador
Definidor de la vista o activador.
SQL dinmico procedente de un paquete
de comportamiento de ejecucin
ID utilizado para efectuar la conexin
inicial con DB2.
SQL dinmico procedente del paquete de
comportamiento de definicin
Definidor de la rutina que utiliza el
paquete del que procede el SQL que
invoca la rutina.
SQL dinmico procedente de un paquete
de comportamiento de invocacin
ID de autorizacin Current que invoca la
rutina.
La tabla siguiente muestra la combinacin del valor de DYNAMICRULES y el
entorno de tiempo de ejecucin que da lugar a cada comportamiento de SQL
dinmico.
Tabla 10. Cmo DYNAMICRULES y el entorno de tiempo de ejecucin determinan el comportamiento
de las sentencias de SQL dinmico
Valor de DYNAMICRULES Comportamiento de sentencias
de SQL dinmico en un entorno
de programa autnomo
Comportamiento de sentencias de
SQL dinmico en un entorno de
rutina
BIND Comportamiento de vinculacin Comportamiento de vinculacin
RUN Comportamiento de ejecucin Comportamiento de ejecucin
DEFINEBIND Comportamiento de vinculacin Comportamiento de definicin
DEFINERUN Comportamiento de ejecucin Comportamiento de definicin
INVOKEBIND Comportamiento de vinculacin Comportamiento de invocacin
INVOKERUN Comportamiento de ejecucin Comportamiento de invocacin
La tabla siguiente muestra los valores de atributos de SQL dinmico
correspondientes a cada tipo de comportamiento de SQL dinmico.
Tabla 11. Definiciones de comportamientos de sentencias de SQL dinmico
Atributo de
SQL dinmico
Valor
correspondiente a
atributos de SQL
dinmico:
comportamiento
de vinculacin
Valor
correspondiente a
atributos de SQL
dinmico:
comportamiento
de ejecucin
Valor
correspondiente a
atributos de SQL
dinmico:
comportamiento de
definicin
Valor correspondiente
a atributos de SQL
dinmico:
comportamiento de
invocacin
ID de
autorizacin
El valor implcito
o explcito de la
opcin OWNER
BIND
ID de usuario que
ejecuta el paquete
Definidor de la
rutina (no el
propietario del
paquete de la
rutina)
ID de autorizacin de
sentencias actual
cuando se invoca la
rutina.
Calificador por
omisin para
objetos no
calificados
El valor implcito
o explcito de la
opcin
QUALIFIER BIND
Registro especial
CURRENT
SCHEMA
Definidor de la
rutina (no el
propietario del
paquete de la
rutina)
ID de autorizacin de
sentencias actual
cuando se invoca la
rutina.
Puede ejecutar
GRANT,
REVOKE,
ALTER,
CREATE, DROP,
COMMENT
ON, RENAME,
SET INTEGRITY
y SET EVENT
MONITOR
STATE
No S No No
El SQLDA en programas de SQL dinmico
Las secciones siguientes describen las distintas consideraciones a tener en
cuenta cuando se declara el SQLDA para un programa de SQL dinmico.
Variables del lenguaje principal en el SQLDA en programas de SQL
dinmico
Con SQL esttico, las variables del lenguaje principal utilizadas en sentencias
de SQL incorporado se conocen en el momento de compilar la aplicacin. Con
SQL dinmico, las sentencias de SQL incorporado y por lo tanto las variables
del lenguaje principal no se conocen hasta el momento de ejecutar la
aplicacin. Por lo tanto, para aplicaciones de SQL dinmico, tiene que trabajar
con la lista de las variables del lenguaje principal que se utilizan en la
aplicacin. Puede utilizar la sentencia DESCRIBE para obtener informacin
sobre variables del lenguaje principal para cualquier sentencia SELECT que se
haya preparado (mediante PREPARE) y almacenar dicha informacin en el
rea del descriptor de SQL (SQLDA).
Nota: las aplicaciones Java no utilizan la estructura SQLDA y, por lo tanto, no
utilizan las sentencias PREPARE ni DESCRIBE. En aplicaciones JDBC,
puede utilizar un objeto PreparedStatement y el mtodo
executeQuery() para generar un objeto ResultSet, que equivale a un
cursor del lenguaje principal. En aplicaciones SQLj, tambin puede
declarar un objeto iterador de SQLj con un cursor CursorByPos o
CursorByName para que devuelva datos de sentencias FETCH.
Cuando la sentencia DESCRIBE se ejecuta en la aplicacin, el gestor de bases
de datos define las variables del lenguaje principal en una SQLDA. Cuando
las variables del lenguaje principal se han definido en el SQLDA, puede
utilizar la sentencia FETCH para asignar valores a las variables del lenguaje
principal, mediante un cursor.
v Ejemplo de un cursor en un programa de SQL dinmico en la pgina 145
v DESCRIBE sentencia en el manual Consulta de SQL, Volumen 2
v FETCH sentencia en el manual Consulta de SQL, Volumen 2
v PREPARE sentencia en el manual Consulta de SQL, Volumen 2
v SQLDA en el manual Administrative API Reference
Declaracin de la estructura SQLDA en un programa de SQL dinmico
El SQLDA contiene un nmero de ocurrencias de variables de entradas
SQLVAR, cada una de las cuales contiene un grupo de campos que describen
una columna de una fila de datos, tal como se muestra en la siguiente figura.
Hay dos tipos de entradas SQLVAR: SQLVAR base y SQLVAR secundarias.
Procedimiento:
Puesto que el nmero de entradas SQLVAR necesario depende del nmero de
columnas de la tabla de resultados, una aplicacin debe ser capaz de asignar
un nmero adecuado de elementos SQLVAR cuando se necesiten. Utilice uno
de los siguientes mtodos:
v Proporcione el SQLDA de mayor tamao (es decir, la que tenga el mayor
nmero de entradas SQLVAR) que se necesite. El nmero mximo de
columnas que se pueden devolver en una tabla de resultados es 255. Si
cualquiera de las columnas devueltas tiene un tipo LOB o un tipo
diferenciado, el valor en SQLN se dobla y el nmero de SQLVAR necesario
para albergar la informacin se dobla a 510. Sin embargo, puesto que la
mayora de sentencias SELECT no recuperan ni 255 columnas, la mayora
del espacio asignado no se utiliza.
v Proporcione un SQLDA de menor tamao con menos entradas SQLVAR. En
este caso, si hay ms columnas en el resultado que entradas SQLVAR
permitidas en el SQLDA, no se devuelve ninguna descripcin. En su lugar,
el gestor de bases de datos devuelve el nmero de elementos de lista de
seleccin detectado en la sentencia SELECT. La aplicacin asigna un
SQLDA con el nmero de entradas SQLVAR necesario y utiliza la sentencia
DESCRIBE para adquirir las descripciones de columnas.
Para ambos mtodos, la duda es cuntas entradas SQLVAR iniciales se deben
asignar. Cada elemento SQLVAR utiliza un mximo de 44 bytes de
almacenamiento (sin contar el almacenamiento asignado para los campos
CABECERA
sqldaid CHAR
sqln SMALLINT
sqltype SMALLINT
sqldata POINTER
sqlname VARCHAR (30)
sqldabc INTEGER
sqld SMALLINT
sqllen SMALLINT
sqlind POINTER
OTROS SQLVAR
SQLVAR
(1 por campo)
Figura 3. El rea de descriptor de SQL (SQLDA)
SQLDATA y SQLIND). Si hay memoria suficiente, el primer mtodo de
proporcionar un SQLDA de tamao mximo resulta ms fcil de implantar.
El segundo mtodo de asignar un SQLDA de menor tamao slo se aplica a
lenguajes de programacin, como C y C++, que dan soporte a la asignacin
dinmica de memoria. Para lenguajes como COBOL y FORTRAN, que no dan
soporte a la asignacin dinmica de memoria, tiene que utilizar el primer
mtodo.
v Preparacin de una sentencia de SQL dinmico utilizando la estructura
SQLDA mnima en la pgina 153
v Asignacin de un SQLDA con suficientes entradas SQLVAR para un
programa de SQL dinmico en la pgina 155
v Asignacin de una estructura SQLDA para un programa de SQL
dinmico en la pgina 158
Preparacin de una sentencia de SQL dinmico utilizando la estructura
SQLDA mnima
Utilice la informacin de este tema como ejemplo sobre cmo asignar la
estructura SQLDA mnima para una sentencia.
Restricciones:
Slo puede asignar una estructura SQLDA de menor tamao con lenguajes de
programacin, como C y C++, que den soporte a la asignacin dinmica de
memoria.
Procedimiento:
Supongamos que una aplicacin declara una estructura SQLDA denominada
minsqlda que no contiene ninguna entrada SQLVAR. El campo SQLN del
SQLDA describe el nmero de entradas SQLVAR que se asignan. En este caso,
SQLN se debe establecer en 0. A continuacin, para preparar una sentencia
desde la serie de caracteres dstring y para entrar su descripcin en minsqlda,
emita la siguiente sentencia de SQL (suponiendo que se utiliza sintaxis de C y
que minsqlda se declara como un puntero a una estructura SQLDA):
EXEC SQL
PREPARE STMT INTO :*minsqlda FROM :dstring;
Supongamos que la sentencia contenida es dstring es una sentencia SELECT
que devuelve 20 columnas en cada fila. Despus de la sentencia PREPARE (o
de una sentencia DESCRIBE), el campo SQLD del SQLDA contiene el nmero
de columnas de la tabla de resultados correspondiente a la sentencia SELECT
preparada.
Las SQLVAR del SQLDA se establecen en los siguientes casos:
v SQLN >= SQLD y ninguna columna tiene el tipo LOB ni un tipo
diferenciado.
Las primeras entradas SQLVAR de SQLD se establecen y SQLDOUBLED se
establece en blanco.
v SQLN >= 2*SQLD y al menos una columna es de tipo LOB o tiene un tipo
diferenciado.
2* entradas SQLVAR de SQLD se establecen y SQLDOUBLED se establece
en 2.
v SQLD <= SQLN < 2*SQLD y al menos una columna tiene un tipo
diferenciado, pero no hay ninguna columna LOB.
Las primeras entradas SQLVAR de SQLD se establecen y SQLDOUBLED se
establece en blanco. Si la opcin de vinculacin SQLWARN tiene el valor
YES, se emite un aviso SQLCODE +237 (SQLSTATE 01594).
Las SQLVAR del SQLDA no se establecen (se necesita asignacin de espacio
adicional y otra sentencia DESCRIBE) en los siguientes casos:
v SQLN < SQLD y ninguna columna tiene el tipo LOB ni un tipo
diferenciado.
No se establece ninguna entrada SQLVAR y SQLDOUBLED se establece en
blanco. Si la opcin de vinculacin SQLWARN tiene el valor YES, se emite
un aviso SQLCODE +236 (SQLSTATE 01005).
Asigne SQLVAR de SQLD para ejecutar una sentencia DESCRIBE
satisfactoria.
v SQLN < SQLD y al menos una columna tiene un tipo diferenciado, pero no
hay ninguna columna LOB.
blanco. Si la opcin de vinculacin SQLWARN tiene el valor YES, se emite
un aviso SQLCODE +239 (SQLSTATE 01005).
Asigne 2*SQLD SQLVAR para ejecutar una sentencia DESCRIBE
satisfactoria, incluidos los nombres de los tipos diferenciados.
v SQLN < 2*SQLD y al menos una columna es de tipo LOB.
blanco. Se emite un aviso SQLCODE +238 (SQLSTATE 01005)
(independientemente del valor de la opcin de vinculacin SQLWARN).
Asigne 2*SQLD SQLVAR para ejecutar una sentencia DESCRIBE
satisfactoria.
La opcin SQLWARN del mandato BIND sirve para controlar si DESCRIBE (o
PREPARE...INTO) devolver los siguientes avisos:
v SQLCODE +236 (SQLSTATE 01005)
v SQLCODE +237 (SQLSTATE 01594)
v SQLCODE +239 (SQLSTATE 01005).
Se recomienda que el cdigo de la aplicacin siempre tenga en cuenta que se
pueden devolver estos SQLCODE. Siempre se devuelve el aviso SQLCODE
+238 (SQLSTATE 01005) cuando hay columnas LOB en la lista de seleccin y
hay un nmero insuficiente de SQLVAR en el SQLDA. Esta es la nica manera
que tiene la aplicacin para saber que el nmero de SQLVAR se tiene que
doblar debido a una columna LOB en el conjunto de resultados.
v Declaracin de la estructura SQLDA en un programa de SQL dinmico en
la pgina 151
Asignacin de un SQLDA con suficientes entradas SQLVAR para un
programa de SQL dinmico
Despus de determinar el nmero de columnas de la tabla de resultados,
asigne almacenamiento para un segundo SQLDA de tamao completo.
Procedimiento:
Supongamos que la tabla de resultados tiene 20 columnas (ninguna de las
cuales es de tipo LOB). En esta situacin, debe asignar una segunda estructura
SQLDA, fulsqlda, con un mnimo de 20 elementos SQLVAR (o 40 elementos
si la tabla de resultados contiene algn LOB o tipo diferenciado). Para el resto
de este ejemplo, supongamos que no hay ningn LOB ni tipo diferenciado en
la tabla de resultados.
Cuando calcule los requisitos de almacenamiento para estructuras de SQLDA,
incluya lo siguiente:
v Una cabecera de longitud fija, de 16 bytes de longitud, que contiene campos
como SQLN y SQLD
v Una matriz de longitud variable de entradas SQLVAR, de la cual cada
elemento tiene 44 bytes de longitud en plataformas de 32 bits y 56 bytes de
longitud en plataformas de 64 bits.
El nmero de entradas SQLVAR necesarias para fulsqlda se especifica en el
campo SQLD de minsqlda. Supongamos que este valor es 20. Por lo tanto, la
asignacin de almacenamiento necesaria para fulsqlda es:
16 + (20 * sizeof(struct sqlvar))
Nota: en plataformas de 64 bits, sizeof(struct sqlvar) y sizeof(struct
sqlvar2) devuelven 56. En plataformas de 32 bits, sizeof(struct
sqlvar) y sizeof(struct sqlvar2) devuelven 44.
Este valor representa el tamao de la cabecera ms 20 multiplicado por el
tamao de cada entrada SQLVAR, lo que da un total de 896 bytes.
Puede utilizar la macro SQLDASIZE para no tener que realizar sus propios
clculos y para evitar dependencias especficas de cada versin.
la pgina 151
Descripcin de una sentencia SELECT en un programa de SQL dinmico
Despus de asignar espacio suficiente para el segundo SQLDA (en este
ejemplo, denominado fulsqlda), debe codificar la aplicacin para que describa
la sentencia SELECT.
Procedimiento:
Codifique la aplicacin para que lleve a cabo los pasos siguientes:
1. Almacenar el valor 20 en el campo SQLN de fulsqlda (en este ejemplo se
supone que la tabla de resultados contiene 20 columnas y que ninguna de
ellas es una columna LOB).
2. Obtener informacin sobre la sentencia SELECT mediante la segunda
estructura SQLDA, fulsqlda. Hay dos mtodos disponibles:
v Utilizar otra sentencia PREPARE, especificando fulsqlda en lugar de
minsqlda.
v Utilizar la sentencia DESCRIBE especificando fulsqlda.
Es preferible utilizar la sentencia DESCRIBE porque se evita el coste de
preparar la sentencia por segunda vez. La sentencia DESCRIBE simplemente
reutiliza la informacin obtenida previamente durante la operacin de
preparacin para llenar la nueva estructura SQLDA. Se puede emitir la
siguiente sentencia:
EXEC SQL DESCRIBE STMT INTO :fulsqlda
Una vez ejecutada esta sentencia, cada elemento SQLVAR contiene una
descripcin de una columna de la tabla de resultados.
v Adquisicin de almacenamiento para albergar una fila en la pgina 157
Adquisicin de almacenamiento para albergar una fila
Para que una aplicacin pueda captar una fila de la tabla de resultados
utilizando una estructura SQLDA, la aplicacin debe antes asignar
almacenamiento para la fila.
Procedimiento:
Codifique la aplicacin de modo que haga lo siguiente:
1. Analice cada descripcin de SQLVAR para determinar cunto espacio se
necesita para el valor de dicha columna.
Tenga en cuenta que, para valores LOB, cuando se describe la sentencia
SELECT, los datos que se proporcionan en la SQLVAR son
SQL_TYP_xLOB. Este tipo de datos corresponde a una variable del
lenguaje principal LOB plana, es decir, el LOB completo se almacena en
memoria de una sola vez. Esto funciona para LOB pequeos (de un
mximo de unos pocos MB), pero no puede utilizar este tipo de datos para
LOB grandes (por ejemplo, de 1 GB). Ser necesario que la aplicacin
cambie su definicin de columna en la SQLVAR para que sea
SQL_TYP_xLOB_LOCATOR o SQL_TYPE_xLOB_FILE. (Tenga en que
cuenta que, si se cambia el campo SQLTYPE de la SQLVAR, tambin se
tiene que cambiar el campo SQLLEN.) Despus de cambiar la definicin
de columna en la SQLVAR, la aplicacin puede asignar la cantidad
correcta de almacenamiento correspondiente al nuevo tipo.
2. Asigne almacenamiento para el valor de dicha columna.
3. Almacene la direccin del almacenamiento asignado en el campo
SQLDATA de la estructura SQLDA.
Estos pasos se deben llevar a cabo analizando la descripcin de cada columna
y sustituyendo el contenido de cada campo SQLDATA por la direccin de un
rea de almacenamiento lo suficientemente grande como para albergar
cualquier valor procedente de dicha columna. El atributo de longitud se
determina a partir del campo SQLLEN de cada entrada SQLVAR
correspondiente a elementos de datos que no son de tipo LOB. Para elementos
con un tipo BLOB, CLOB o DBCLOB, el atributo de longitud se determina a
partir del campo SQLLONGLEN de la entrada SQLVAR secundaria.
Adems, si la columna especificada permite nulos, la aplicacin debe sustituir
el contenido del campo SQLIND por la direccin de una variable de indicador
correspondiente a la columna.
v Uso de objetos grandes en el manual Gua de desarrollo de aplicaciones:
v Proceso del cursor en un programa de SQL dinmico en la pgina 158
Proceso del cursor en un programa de SQL dinmico
Despus de asignar correctamente la estructura SQLDA, el cursor asociado
con la sentencia SELECT se puede abrir y se pueden captar filas.
Procedimiento:
Para procesar el cursor asociado con una sentencia SELECT, primero abra el
cursor y luego capte filas especificando la clusula USING DESCRIPTOR de la
sentencia FETCH. Por ejemplo, una aplicacin C podra tener lo siguiente:
EXEC SQL OPEN pcurs
EMB_SQL_CHECK( "OPEN" ) ;
EXEC SQL FETCH pcurs USING DESCRIPTOR :*sqldaPointer
EMB_SQL_CHECK( "FETCH" ) ;
Para procesar una operacin FETCH satisfactoriamente, podra escribir la
aplicacin de modo que obtuviera los datos del SQLDA y mostrara las
cabeceras de columna. Por ejemplo:
display_col_titles( sqldaPointer ) ;
Una vez visualizados los datos, debera cerrar el cursor y liberar la memoria
asignada de forma dinmica. Por ejemplo:
EXEC SQL CLOSE pcurs ;
EMB_SQL_CHECK( "CLOSE CURSOR" ) ;
Asignacin de una estructura SQLDA para un programa de SQL dinmico
Asigne una estructura SQLDA correspondiente a la aplicacin de modo que
pueda utilizarla para pasar datos a la aplicacin y para recibir datos de esta.
Procedimiento:
Para crear una estructura SQLDA con C, incorpore la sentencia INCLUDE
SQLDA en el lenguaje principal o incluya el archivo include de SQLDA para
obtener la definicin de estructura. Luego, debido a que el tamao de un
SQLDA no es fijo, la aplicacin debe declarar un puntero a una estructura
SQLDA y asignar almacenamiento para la misma. El tamao real de la
estructura SQLDA depende del nmero de elementos de datos diferenciados
que se pasan mediante el SQLDA.
En el lenguaje de programacin C/C++, se proporciona una macro que facilita
la asignacin de SQLDA. Con la excepcin de la plataforma HP-UX, esta
macro tiene el siguiente formato:
#define SQLDASIZE(n) (offsetof(struct sqlda, sqlvar) \
+ (n) sizeof(struct sqlvar))
En la plataforma HP-UX, la macro tiene el siguiente formato:
#define SQLDASIZE(n) (sizeof(struct sqlda) \
+ (n1) sizeof(struct sqlvar))
El efecto de esta macro es calcular el almacenamiento necesario para un
SQLDA con n elementos SQLVAR.
Para crear una estructura SQLDA con COBOL, puede incorporar una
sentencia INCLUDE SQLDA o utilizar la sentencia COPY. Utilice la sentencia
COPY cuando desee controlar el nmero mximo de SQLVAR y por lo tanto
la cantidad de almacenamiento que utiliza el SQLDA. Por ejemplo, para
cambiar el nmero por omisin de SQLVAR de 1489 a 1, utilice la siguiente
sentencia COPY:
COPY "sqlda.cbl"
replacing --1489--
by --1--.
El lenguaje FORTRAN no da soporte directamente a las estructuras de datos
autodefinidas ni a la asignacin dinmica. No se proporciona ningn archivo
include de SQLDA para FORTRAN porque no es posible dar soporte al
SQLDA como una estructura de datos en FORTRAN. El precompilador pasar
por alto la sentencia INCLUDE SQLDA en un programa FORTRAN.
Sin embargo, puede crear algo parecido a una estructura SQLDA esttica en
un programa FORTRAN y utilizar dicha estructura siempre que se pueda
utilizar un SQLDA. El archivo sqldact.f contiene constantes que ayudan a
declarar una estructura SQLDA en FORTRAN.
Ejecute llamadas a SQLGADDR para asignar valores de puntero a elementos
de SQLDA que los necesiten.
La tabla siguiente muestra la declaracin y uso de una estructura SQLDA con
un elemento SQLVAR.
C/C++
#include <sqlda.h>
struct sqlda *outda = (struct sqlda *)malloc(SQLDASIZE(1));
/* DECLARAR VARIABLES LOCALES PARA ALBERGAR DATOS REALES */
double sal;
double sal = 0;
short salind;
short salind = 0;
/* INICIALIZAR UN ELEMENTO DE SQLDA */
memcpy( outda->sqldaid,"SQLDA ",sizeof(outda->sqldaid));
outda->sqln = outda->sqld = 1;
outda->sqlvar[0].sqltype = SQL_TYP_NFLOAT;
outda->sqlvar[0].sqllen = sizeof( double );.
outda->sqlvar[0].sqldata = (unsigned char *)&sal;
outda->sqlvar[0].sqlind = (short *)&salind;
COBOL
WORKING-STORAGE SECTION.
77 SALARY PIC S99999V99 COMP-3.
77 SAL-IND PIC S9(4) COMP-5.
EXEC SQL INCLUDE SQLDA END-EXEC
* O codificar un modo til para guardar entradas SQLVAR no utilizadas.
* COPY "sqlda.cbl" REPLACING --1489-- BY --1--.
01 decimal-sqllen pic s9(4) comp-5.
01 decimal-parts redefines decimal-sqllen.
05 precision pic x.
05 scale pic x.
* Inicializar un elemento de SQLDA de salida
MOVE 1 TO SQLN
MOVE 1 TO SQLD
MOVE SQL-TYP-NDECIMAL TO SQLTYPE(1)
* Longitud = 7 dgitos de precisin y 2 dgitos de escala
MOVE x"07" TO PRECISION.
MOVE x"02" TO SCALE.
MOVE DECIMAL-SQLLEN TO O-SQLLEN(1).
SET SQLDATA(1) TO ADDRESS OF SALARY
SET SQLIND(1) TO ADDRESS OF SAL-IND
FORTRAN
include sqldact.f
integer*2 sqlvar1
parameter ( sqlvar1 = sqlda_header_sz + 0*sqlvar_struct_sz )
C Declarar un SQLDA de salida -- 1 Variable
character out_sqlda(sqlda_header_sz + 1*sqlvar_struct_sz)
character*8 out_sqldaid ! Cabecera
integer*4 out_sqldabc
integer*2 out_sqln
integer*2 out_sqld
integer*2 out_sqltype1 ! Primera variable
integer*2 out_sqllen1
integer*4 out_sqldata1
integer*4 out_sqlind1
integer*2 out_sqlnamel1
character*30 out_sqlnamec1
equivalence( out_sqlda(sqlda_sqldaid_ofs), out_sqldaid )
equivalence( out_sqlda(sqlda_sqldabc_ofs), out_sqldabc )
equivalence( out_sqlda(sqlda_sqln_ofs), out_sqln )
equivalence( out_sqlda(sqlda_sqld_ofs), out_sqld )
equivalence( out_sqlda(sqlvar1+sqlvar_type_ofs), out_sqltype1 )
equivalence( out_sqlda(sqlvar1+sqlvar_len_ofs), out_sqllen1 )
equivalence( out_sqlda(sqlvar1+sqlvar_data_ofs), out_sqldata1 )
equivalence( out_sqlda(sqlvar1+sqlvar_ind_ofs), out_sqlind1 )
equivalence( out_sqlda(sqlvar1+sqlvar_name_length_ofs),
+ out_sqlnamel1 )
equivalence( out_sqlda(sqlvar1+sqlvar_name_data_ofs),
+ out_sqlnamec1 )
C Declarar variables locales para albergar los datos devueltos.
real*8 salary
integer*2 sal_ind
C Inicializar el SQLDA de salida (cabecera)
out_sqldaid = OUT_SQLDA
out_sqldabc = sqlda_header_sz + 1*sqlvar_struct_sz
out_sqln = 1
out_sqld = 1
C Inicializar VAR1
out_sqltype1 = SQL_TYP_NFLOAT
out_sqllen1 = 8
rc = sqlgaddr( %ref(salary), %ref(out_sqldata1) )
rc = sqlgaddr( %ref(sal_ind), %ref(out_sqlind1) )
En lenguajes que no dan soporte a la asignacin dinmica de memoria, se
debe declarar de forma explcita en el lenguaje principal un SQLDA con el
nmero deseado de elementos SQLVAR. Asegrese de declarar el nmero
suficiente de elementos SQLVAR segn los requisitos de la aplicacin.
v Transferencia de datos en un programa de SQL dinmico mediante una
estructura SQLDA en la pgina 162
Transferencia de datos en un programa de SQL dinmico mediante una
estructura SQLDA
Puede obtener una mayor flexibilidad si transfiere datos mediante un SQLDA
que si utiliza listas de variables del lenguaje principal. Por ejemplo, puede
utilizar un SQLDA para transferir datos que no tienen ningn equivalente en
el lenguaje principal, como datos DECIMAL en lenguaje C.
Procedimiento:
Utilice la siguiente tabla como listado de referencias cruzadas que muestra
cmo se relacionan los valores numricos y los nombres simblicos.
Tabla 12. Tipos de SQL de SQLDA de DB2. Valores numricos y nombres simblicos correspondientes
Tipo de columna SQL Valor numrico
SQLTYPE
Nombre simblico SQLTYPE
1
DATE 384/385 SQL_TYP_DATE / SQL_TYP_NDATE
TIME 388/389 SQL_TYP_TIME / SQL_TYP_NTIME
TIMESTAMP 392/393 SQL_TYP_STAMP / SQL_TYP_NSTAMP
n/d
2
400/401 SQL_TYP_CGSTR / SQL_TYP_NCGSTR
BLOB 404/405 SQL_TYP_BLOB / SQL_TYP_NBLOB
CLOB 408/409 SQL_TYP_CLOB / SQL_TYP_NCLOB
DBCLOB 412/413 SQL_TYP_DBCLOB / SQL_TYP_NDBCLOB
VARCHAR 448/449 SQL_TYP_VARCHAR / SQL_TYP_NVARCHAR
CHAR 452/453 SQL_TYP_CHAR / SQL_TYP_NCHAR
LONG VARCHAR 456/457 SQL_TYP_LONG / SQL_TYP_NLONG
n/d
3
460/461 SQL_TYP_CSTR / SQL_TYP_NCSTR
VARGRAPHIC 464/465 SQL_TYP_VARGRAPH / SQL_TYP_NVARGRAPH
GRAPHIC 468/469 SQL_TYP_GRAPHIC / SQL_TYP_NGRAPHIC
LONG VARGRAPHIC 472/473 SQL_TYP_LONGRAPH / SQL_TYP_NLONGRAPH
Tabla 12. Tipos de SQL de SQLDA de DB2 (continuacin). Valores numricos y nombres simblicos
correspondientes
Tipo de columna SQL Valor numrico
SQLTYPE
Nombre simblico SQLTYPE
1
FLOAT 480/481 SQL_TYP_FLOAT / SQL_TYP_NFLOAT
REAL
4
480/481 SQL_TYP_FLOAT / SQL_TYP_NFLOAT
DECIMAL
5
484/485 SQL_TYP_DECIMAL / SQL_TYP_DECIMAL
INTEGER 496/497 SQL_TYP_INTEGER / SQL_TYP_NINTEGER
SMALLINT 500/501 SQL_TYP_SMALL / SQL_TYP_NSMALL
n/d 804/805 SQL_TYP_BLOB_FILE / SQL_TYPE_NBLOB_FILE
n/d 808/809 SQL_TYP_CLOB_FILE / SQL_TYPE_NCLOB_FILE
n/d 812/813 SQL_TYP_DBCLOB_FILE / SQL_TYPE_NDBCLOB_FILE
n/d 960/961 SQL_TYP_BLOB_LOCATOR / SQL_TYP_NBLOB_LOCATOR
n/d 964/965 SQL_TYP_CLOB_LOCATOR / SQL_TYP_NCLOB_LOCATOR
n/d 968/969 SQL_TYP_DBCLOB_LOCATOR / SQL_TYP_NDBCLOB_LOCATOR
Nota: estos tipos definidos se encuentran en el archivo include sql.h del subdirectorio include del
directorio sqllib. (Por ejemplo, sqllib/include/sql.h para el lenguaje de programacin C.)
1. Para el lenguaje de programacin COBOL, el nombre SQLTYPE no utiliza el signo de subrayado (_)
sino un guin (-).
2. Es una serie grfica terminada en nulo.
3. Es una serie de caracteres terminada en nulo.
4. La diferencia entre REAL y DOUBLE en el SQLDA es el valor de la longitud (4 u 8).
5. La precisin est en el primer byte. La escala est en el segundo byte.
v Descripcin de una sentencia SELECT en un programa de SQL dinmico
en la pgina 156
Proceso de sentencias interactivas de SQL en programas de SQL
dinmico
Una aplicacin que utiliza SQL dinmico se puede escribir de modo que
procese sentencias arbitrarias de SQL. Por ejemplo, si una aplicacin acepta
sentencias de SQL del usuario, la aplicacin debe ser capaz de ejecutar las
sentencias sin conocimiento previo de las mismas.
Procedimiento:
Utilice las sentencias PREPARE y DESCRIBE con una estructura SQLDA de
modo que la aplicacin pueda determinar el tipo de sentencia de SQL que se
ejecutan y actuar consecuentemente.
v Determinacin del tipo se sentencia en programas de SQL dinmico en la
pgina 164
Determinacin del tipo se sentencia en programas de SQL dinmico
Cuando se prepara una sentencia de SQL, la informacin sobre el tipo de
sentencia se puede determinar examinando la estructura SQLDA. Esta
informacin se coloca en la estructura SQLDA en el momento de la
preparacin de la sentencia con la clusula INTO o emitiendo una sentencia
DESCRIBE contra una sentencia preparada anteriormente.
En cualquier caso, el gestor de bases de datos coloca un valor en el campo
SQLD de la estructura SQLDA que indica el nmero de columnas de la tabla
de resultados generada por la sentencia de SQL. Si el campo SQLD contiene
un cero (0), significa que la sentencia no es una sentencia SELECT. Puesto que
la sentencia ya est preparada, se puede ejecutar inmediatamente mediante la
sentencia EXECUTE.
Si la sentencia contiene marcadores de parmetros, se debe especificar la
clusula USING. La clusula USING puede especificar una lista de variables
del lenguaje principal o una estructura SQLDA.
Si el campo SQLD es mayor que cero, significa que la sentencia es una
sentencia SELECT y se debe procesar tal como se describe en las siguientes
secciones.
v EXECUTE sentencia en el manual Consulta de SQL, Volumen 2
Proceso de sentencias SELECT de lista de variables en programas de
SQL dinmico
Una sentencia SELECT de lista de variables es una sentencia en la que el
nmero y los tipos de columnas que se tienen que devolver no se conocen en
el momento de la precompilacin. En este caso, la aplicacin no sabe con
antelacin las variables exactas del lenguaje principal que se tienen que
declarar para albergar una fila de la tabla de resultados.
Procedimiento:
Para procesar una sentencia SELECT de lista de variables, codifique la
aplicacin de modo que haga lo siguiente:
1. Declare un SQLDA.
Se debe utilizar una estructura SQLDA para procesar las sentencias
SELECT de lista de variables.
2. PREPARE la sentencia mediante la clusula INTO.
Luego la aplicacin determina si la estructura SQLDA declarada tiene
suficientes elementos SQLVAR. Si no es as, la aplicacin asigna otra
estructura SQLDA con el nmero necesario de elementos SQLVAR y emite
una sentencia DESCRIBE adicional mediante el nuevo SQLDA.
3. Asigne los elementos SQLVAR.
Asigne almacenamiento para las variables del lenguaje principal e
indicadores necesarios para cada SQLVAR. Este paso incluye la colocacin
de las direcciones asignadas para los datos y variables de indicador en
cada elemento SQLVAR.
4. Procese la sentencia SELECT.
Se asocia un cursor con la sentencia preparada, se abre y las filas se captan
mediante la estructura SQLDA correctamente asignada.
la pgina 151
v Descripcin de una sentencia SELECT en un programa de SQL dinmico
en la pgina 156
Cmo guardar peticiones de SQL procedentes de usuarios finales
Si los usuarios de la aplicacin pueden emitir peticiones de SQL desde la
aplicacin, es posible que desee guardar dichas peticiones.
Procedimiento:
Si la aplicacin permite a los usuarios guardar sentencias arbitrarias de SQL,
las puede guardar en una tabla con una columna que tenga el tipo
VARCHAR, LONG VARCHAR, CLOB, VARGRAPHIC, LONG VARGRAPHIC
o DBCLOB. Tenga en cuenta que los tipos de datos VARGRAPHIC, LONG
VARGRAPHIC y DBCLOB slo estn disponibles en entornos de juego de
caracteres de doble byte (DBCS) y de Extended UNIX Code (EUC).
Debe guardar los elementos SQL fuente, no las versiones preparadas. Esto
significa que debe recuperar y luego preparar cada sentencia antes de ejecutar
la versin almacenada en la tabla. Bsicamente, la aplicacin prepara una
sentencia de SQL a partir de una serie de caracteres y ejecuta esta sentencia de
forma dinmica.
Marcadores de parmetros en programas de SQL dinmico
Las secciones siguientes describen cmo utilizar marcadores de parmetros
para proporcionar entrada de variables a un programa de SQL dinmico y
describen brevemente los programas de ejemplo que utilizan marcadores de
parmetros.
Cmo proporcionar entrada de variables a SQL dinmico mediante
marcadores de parmetros
Una sentencia de SQL dinmico no puede contener variables del lenguaje
principal, porque la informacin de las variables del lenguaje principal (tipo
de datos y longitud) slo est disponible durante la precompilacin de la
aplicacin. En el momento de la ejecucin, la informacin de las variables del
lenguaje principal no est disponible.
En SQL dinmico, se utilizan marcadores de parmetros en lugar de variables
del lenguaje principal. Los marcadores de parmetros se indican mediante un
signo de interrogacin (?) e indican dnde se debe sustituir una variable del
lenguaje principal dentro de una sentencia de SQL.
Procedimiento:
Supongamos que la aplicacin utiliza SQL dinmico y que desea que pueda
realizar una operacin DELETE. Una serie de caracteres que contenga un
marcador de parmetros puede tener un aspecto parecido al siguiente:
DELETE FROM TEMPL WHERE EMPNO = ?
Cuando se ejecuta esta sentencia, se especifica una variable del lenguaje
principal o una estructura SQLDA mediante la clusula USING de la
sentencia EXECUTE. El contenido de la variable del lenguaje principal se
utiliza cuando se ejecuta la sentencia.
El marcador de parmetros adopta un tipo de datos y longitud supuestos que
dependen del contexto de su uso dentro de la sentencia de SQL. Si el tipo de
datos de un marcador de parmetros no resulta obvio a partir del contexto de
la sentencia en la que se utiliza, utilice CAST para especificar el tipo. Dicho
marcador de parmetros se considera un a marcador de parmetros tipificado.
Los marcadores de parmetros tipificados se tratan como una variable del
lenguaje principal del tipo determinado. Por ejemplo, la sentencia SELECT ?
FROM SYSCAT.TABLES no es vlida porque DB2 no conoce el tipo de la columna
de resultados. Sin embargo, la sentencia SELECT CAST(? AS INTEGER) FROM
SYSCAT.TABLES es vlida porque cast indica que el marcador de parmetros
representa un INTEGER, de modo que DB2 conoce el tipo de la columna de
resultados.
Si la sentencia de SQL contiene ms de un marcador de parmetros, la
clusula USING de la sentencia EXECUTE debe especificar una lista de
variables del lenguaje principal (una para cada marcador de parmetros) o
debe identificar un SQLDA que tenga una entrada SQLVAR para cada
marcador de parmetros. (Tenga en cuenta que para LOB hay dos SQLVAR
por marcador de parmetros.) La lista de variables del lenguaje principal o
entradas SQLVAR se comparan de acuerdo con el orden de los marcadores de
parmetros en la sentencia y deben tener tipos de datos compatibles.
Nota: utilizar un marcador de parmetros con SQL dinmico es como utilizar
variables del lenguaje principal con SQL esttico. En cualquier caso, el
optimizador no utiliza estadsticas de distribucin y es posible que no
elija el mejor plan de acceso.
Las normas que se aplican a marcadores de parmetros se describen con la
sentencia PREPARE.
Ejemplo de marcadores de parmetros en un programa de SQL dinmico
Los siguientes ejemplos muestran cmo utilizar marcadores de parmetros en
un programa de SQL dinmico:
v C/C++ (dbuse.sqc/dbuse.sqC)
La funcin DynamicStmtWithMarkersEXECUTEusingHostVars() del ejemplo de
lenguaje C dbuse.sqc muestra cmo realizar una supresin mediante un
marcador de parmetro con una variable del lenguaje principal:
char hostVarStmt1[50];
short hostVarDeptnumb;
/* preparar la sentencia con un marcador de parmetro */
strcpy(hostVarStmt1, "DELETE FROM org WHERE deptnumb = ?");
EXEC SQL PREPARE Stmt1 FROM :hostVarStmt1;
/* ejecutar la sentencia correspondiente a hostVarDeptnumb = 15 */
hostVarDeptnumb = 15;
EXEC SQL EXECUTE Stmt1 USING :hostVarDeptnumb;
v JDBC (DbUse.java)
La funcin execPreparedStatementWithParam() del ejemplo JDBC
DbUse.java muestra cmo realizar una supresin mediante marcadores de
parmetros:
// preparar la sentencia con marcadores de parmetros
PreparedStatement prepStmt = con.prepareStatement(
" DELETE FROM org WHERE deptnumb <= ? AND division = ? ");
// ejecutar la sentencia
prepStmt.setInt(1, 70);
prepStmt.setString(2, "Eastern");
prepStmt.execute();
// cerrar la sentencia
prepStmt.close();
v COBOL (varinp.sqb)
El siguiente ejemplo procede del ejemplo de COBOL varinp.sqb y muestra
cmo utilizar un marcador de parmetro en condiciones de bsqueda y
actualizacin:
01 pname pic x(10).
01 dept pic s9(4) comp-5.
01 st pic x(127).
01 parm-var pic x(5).
move "SELECT name, dept FROM staff
- " WHERE job = ? FOR UPDATE OF job" to st.
EXEC SQL PREPARE s1 FROM :st END-EXEC.
EXEC SQL DECLARE c1 CURSOR FOR s1 END-EXEC.
move "Mgr" to parm-var.
EXEC SQL OPEN c1 USING :parm-var END-EXEC
move "Clerk" to parm-var.
move "UPDATE staff SET job = ? WHERE CURRENT OF c1" to st.
EXEC SQL PREPARE s2 from :st END-EXEC.
* llamar a FETCH y al bucle UPDATE.
v dbuse.out -- HOW TO USE A DATABASE (C)
v dbuse.sqc -- How to use a database (C)
v dbuse.out -- HOW TO USE A DATABASE (C++)
v dbuse.sqC -- How to use a database (C++)
v DbUse.java -- How to use a database (JDBC)
v DbUse.out -- HOW TO USE A DATABASE (JDBC)
Comparacin entre Interfaz de nivel de llamada (CLI) de DB2 y SQL dinmico
Las secciones siguientes describen las diferencias entre CLI de DB2 y SQL
dinmico, las ventajas de CLI de DB2 sobre SQL dinmico y cundo debe
utilizar CLI de DB2 o SQL dinmico.
Interfaz de nivel de llamada de DB2 (CLI) frente a SQL dinmico
incorporado
Una aplicacin que utiliza una interfaz de SQL incorporado necesita un
precompilador para convertir las sentencias de SQL en cdigo, que luego se
puede compilar, vincular a la base de datos y ejecutar. Por el contrario, una
aplicacin CLI de DB2 no se tiene que precompilar ni vincular, pero utiliza un
conjunto estndar de funciones para ejecutar sentencias de SQL y servicios
relacionados en el tiempo de ejecucin.
Esta diferencia es importante porque, tradicionalmente, los precompiladores
han sido especficos para cada producto de base de datos, lo que establece
una relacin entre las aplicaciones y dicho producto. CLI de DB2 le permite
escribir aplicaciones portables que no dependen de un determinado producto
de base de datos. Esta independencia significa que las aplicaciones CLI de
DB2 no se tienen que recompilar y revincular para poder acceder a distintas
bases de datos de DB2, incluidas las bases de datos del sistema principal.
Simplemente se conectan a la base de datos adecuada en el tiempo de
ejecucin.
A continuacin se muestran las diferencias y similitudes entre CLI de DB2 y
SQL incorporado:
v CLI de DB2 no necesita la declaracin explcita de cursores. CLI de DB2
tiene un suministro de cursores que se utilizan cuando hace falta. Luego la
aplicacin puede utilizar el cursor generado en el modelo de captacin de
cursor normal para varias sentencias SELECT de fila y sentencias UPDATE y
DELETE colocadas.
v La sentencia OPEN no se utiliza en CLI de DB2. En su lugar, la ejecucin de
SELECT hace que se abra un cursor de inmediato.
v A diferencia de SQL incorporado, CLI de DB2 permite el uso de marcadores
de parmetros en el equivalente de la sentencia EXECUTE IMMEDIATE (la
funcin SQLExecDirect()).
v Una sentencia COMMIT o ROLLBACK en CLI de DB2 se suele emitir mediante la
funcin SQLEndTran() en lugar de ejecutarse como una sentencia de SQL,
aunque esto ltimo est permitido.
v CLI de DB2 gestiona la informacin relacionada con sentencias en nombre
de la aplicacin y proporciona un objeto abstracto para representar la
informacin que se denomina descriptor de contexto de sentencias. Este
descriptor de contexto elimina la necesidad de que la aplicacin utilice
estructuras de datos especficas del producto.
v Parecidos al descriptor de contexto de sentencias, el descriptor de contexto de
entorno y el descriptor de contexto de conexiones proporcionan mtodos para
hacer referencia a variables globales y a informacin especfica de la
conexin. El descriptor de contexto descriptor describe los parmetros de una
sentencia de SQL o las columnas de un conjunto de resultados.
v Las aplicaciones CLI de DB2 pueden describir parmetros de forma
dinmica en una sentencia de SQL del mismo modo que las aplicaciones
CLI y de SQL incorporado describen los conjuntos de resultados. Esto
permite a las aplicaciones CLI procesar de forma dinmica sentencias de
SQL que contienen marcadores de parmetros sin saber de forma anticipada
el tipo de datos de dichos marcadores de parmetros. Cuando se prepara la
sentencia de SQL, se devuelve informacin de descripcin que detalla los
tipos de datos de los parmetros.
v CLI de DB2 utiliza los valores de SQLSTATE definidos por la especificacin
CAE de SQL de X/Open. Aunque el formato y la mayora de los valores
son coherentes con los valores que utilizan los productos de bases de datos
relacionales de IBM, hay algunas diferencias. (Tambin hay diferencias entre
los SQLSTATES de ODBC y los SQLSTATES definidos por X/Open).
A pesar de estas diferencias, hay un importante concepto comn entre SQL
incorporado y CLI de DB2: CLI de DB2 puede ejecutar cualquier sentencia de SQL
que se puede preparar de forma dinmica en SQL incorporado.
Nota: CLI de DB2 tambin puede aceptar algunas sentencias de SQL que no
se pueden preparar de forma dinmica, como sentencias compuestas de
SQL.
Cada DBMS puede tener sentencias adicionales que el usuario puede preparar
de forma dinmica. En este caso, CLI de DB2 pasa las sentencias directamente
al DBMS. Hay una excepcin: algunos DBMS pueden preparar las sentencias
COMMIT y ROLLBACK de forma dinmica, pero CLI de DB2 las interceptar
y las tratar como una peticin SQLEndTran() adecuada. Sin embargo, se
recomienda utilizar la funcin SQLEndTran() para especificar la sentencia
COMMIT o ROLLBACK.
Ventajas de CLI de DB2 sobre SQL incorporado
La interfaz CLI de DB2 tiene varias ventajas clave sobre SQL incorporado.
v Resulta ideal para un entorno cliente-servidor, en el que la base de datos de
destino no se conoce cuando se crea la aplicacin. Proporciona una interfaz
coherente para ejecutar sentencias de SQL, independientemente del servidor
de base de datos al que se conecte la aplicacin.
v Aumenta la portabilidad de las aplicaciones al eliminar la dependencia de
precompiladores. Las aplicaciones se distribuyen no como cdigo fuente de
SQL incorporado, que se tiene que preprocesar para cada producto de base
de datos, sino como aplicaciones compiladas o bibliotecas en tiempo de
ejecucin.
v Las aplicaciones CLI de DB2 individuales no se tienen que vincular a cada
base de datos; solo los archivos de vinculacin que se suministran con CLI
de DB2 se tienen que vincular una vez para todas las aplicaciones CLI de
DB2. Esto puede reducir significativamente la cantidad de gestin necesaria
para la aplicacin cuando ya est en nivel de uso general.
v Las aplicaciones CLI de DB2 se pueden conectar a varias bases de datos,
incluidas varias conexiones a la misma base de datos, todo desde la misma
aplicacin. Cada conexin tiene su propio mbito de confirmacin. Esto
resulta ms sencillo si se utiliza CLI que si se utiliza SQL incorporado,
donde la aplicacin debe utilizar varias hebras para conseguir el mismo
resultado.
v CLI de DB2 elimina la necesidad de reas de datos controladas por la
aplicacin y a menudo complejas, como SQLDA y SQLCA, que suelen estar
asociadas con aplicaciones de SQL incorporado. En su lugar, CLI de DB2
asigna y controla las estructuras de datos necesarias y proporciona un
descriptor de contexto para que la aplicacin haga referencia a las mismas.
v CLI de DB2 permite el desarrollo de aplicaciones de varias hebras seguras
en las que cada hebra puede tener su propia conexin y un mbito de
confirmacin independiente del resto. CLI de DB2 lo consigue eliminando
las reas de datos descritas anteriormente y asociando todas estas
estructuras de datos a las que puede acceder la aplicacin con un descriptor
de contexto especfico. A diferencia de SQL incorporado, una aplicacin CLI
de varias hebras no tiene que llamar a ninguna de las API de DB2 de
gestin de contexto; el controlador de CLI de DB2 lo maneja
automticamente.
v CLI de DB2 proporciona una funcin mejorada de captacin y entrada de
parmetros que permite especificar matrices de datos como entrada,
recuperar varias filas de un conjunto de resultados directamente en una
matriz y ejecutar sentencias que generan varios conjuntos de resultados.
v CLI de DB2 proporciona una interfaz coherente frente a la informacin de
catlogo de consulta (Tablas, Columnas, Claves forneas, Claves principales,
etc.) contenida en distintas tablas de catlogo de DBMS. Los conjuntos de
resultados devueltos son coherentes entre los DBMS. Esto protege la
aplicacin frente a cambios de catlogo entre releases de servidores de
datos, as como frente a diferencias de catlogo entre distintos servidores de
bases de datos; por lo tanto evita que las aplicaciones tengan que escribir
consultas de catlogo especficas de cada versin y especficas de cada
servidor.
v CLI de DB2 tambin proporciona conversin de datos ampliados, por lo
que se necesita menos cdigo de aplicacin cuando se convierte
informacin entre distintos tipos de datos SQL y C.
v CLI de DB2 incorpora funciones CLI tanto de ODBC como de X/Open
(ambas son especificaciones aceptadas de la industria). CLI de DB2 tambin
cumple con el estndar de CLI de ISO. El conocimiento que los
programadores de aplicaciones adquieran en estas especificaciones se puede
aplicar directamente al desarrollo de CLI de DB2 y viceversa. Esta interfaz
resulta intuitiva para los programadores que estn familiarizados con
bibliotecas de funciones pero tienen pocos conocimientos sobre mtodos
especficos del producto para incorporar sentencias de SQL en un lenguaje
principal.
v CLI de DB2 proporciona la posibilidad de recuperar varias filas y conjuntos
de resultados generados a partir de un procedimiento almacenado que
reside en un servidor DB2 Universal Database (o DB2 Universal Database
para OS/390 y z/OS versin 5 o posterior). Sin embargo, tenga en cuenta
que esta funcin existe para clientes de la Versin 5 de DB2 Universal
Database que utilizan SQL incorporado si el procedimiento almacenado
reside en un servidor al que se puede acceder desde un servidor DataJoiner
Versin 2.
v CLI de DB2 ofrece soporte ms amplio para cursores desplazables. Con
cursores desplazables puede desplazarse por un cursor del siguiente modo:
Hacia adelante, una o ms filas
Hacia atrs, una o ms filas
Desde la primera fila una o ms filas.
Desde la ltima fila una o ms filas.
Los cursores desplazables se pueden utilizar junto con una salida de matriz.
Puede declarar un cursor actualizable como desplazable y luego
desplazarse hacia adelante o hacia atrs a travs del conjunto de resultados
una o ms filas. Tambin puede captar filas especificando un
desplazamiento desde:
La fila actual
El principio o fin del conjunto de resultados
Una fila especfica que ha establecido anteriormente con una marca.
Cundo utilizar CLI de DB2 o SQL incorporado
La interfaz elegida depende de la aplicacin.
CLI de DB2 resulta ideal para aplicaciones de interfaz grfica de usuario
(GUI) basada en consulta que necesitan portabilidad. Las ventajas explicadas
anteriormente pueden hacer parecer que utilizar CLI de DB2 sea la opcin
obvia para cualquier aplicacin. Sin embargo, hay un factor que se debe tener
en cuenta: la comparacin entre SQL esttico y dinmico. Es mucho ms fcil
utilizar SQL esttico en aplicaciones incorporadas.
SQL esttico tiene varias ventajas:
v Rendimiento
SQL dinmico se prepara en el tiempo de ejecucin, SQL esttico se prepara
en el momento de la precompilacin. Adems de necesitar ms proceso, el
paso de preparacin puede originar trfico de red adicional en el tiempo de
ejecucin. El trfico de red adicional se puede evitar si la aplicacin CLI de
DB2 utiliza la preparacin diferida (que es el comportamiento por omisin).
Es importante indicar que SQL esttico no siempre tiene un rendimiento
mejor que SQL dinmico. SQL dinmico se prepara en el tiempo de
ejecucin y utiliza las estadsticas de bases de datos disponibles en ese
momento, mientras que SQL esttico utiliza las estadsticas de bases de
datos disponibles en el momento de realizar la operacin BIND. SQL
dinmico utiliza los cambios realizados en la base de datos, como nuevos
ndices, para elegir el plan de acceso ptimo, lo que potencialmente ofrece
un mejor rendimiento que el mismo SQL ejecutado como SQL esttico.
Adems, se puede evitar la precompilacin de sentencias de SQL dinmico
si se colocan en antememoria.
v Encapsulacin y seguridad
En SQL esttico, las autorizaciones para acceder a objetos (como una tabla o
una vista) estn asociadas a un paquete y se validan en el momento de
vincular el paquete. Esto significa que los administradores de bases de
datos slo tienen que otorgar autorizacin de ejecucin sobre un
determinado paquete a un conjunto de usuarios (encapsulando as sus
privilegios en el paquete) sin tener que otorgarles acceso explcito a cada
objeto de la base de datos. En SQL dinmico, las autorizaciones se validan
en el tiempo de ejecucin sentencia a sentencia; por lo tanto, se tiene que
otorgar a los usuarios acceso explcito a cada objeto de la base de datos.
Esto permite que estos usuarios accedan a partes del objeto a las que no
tienen necesidad de acceder.
v SQL incorporado recibe soporte en otros lenguajes, adems de C o C++.
v Para selecciones fijas de consulta, SQL incorporado resulta ms sencillo.
Si una aplicacin necesita las ventajas de ambas interfaces, se puede utilizar
SQL esttico dentro de una aplicacin CLI de DB2 creando un procedimiento
almacenado que contenga el SQL esttico. Se llama al procedimiento
almacenado desde dentro de una aplicacin CLI de DB2 y se ejecuta en el
servidor. Una vez creado el procedimiento almacenado, cualquier aplicacin
CLI de DB2 o ODBC puede llamarlo.
Tambin se puede escribir una aplicacin mixta que utilice tanto CLI de DB2
como SQL incorporado, aprovechando sus respectivas ventajas. En este caso,
se utiliza CLI de DB2 para proporcionar la aplicacin base, con mdulos clave
escritos utilizando SQL esttico por razones de rendimiento o seguridad. Esto
complica el diseo de la aplicacin y slo se debe utilizar si los
procedimientos almacenados no cumplen con los requisitos de la aplicacin.
Por ltimo, la decisin sobre cundo utilizar cada interfaz se basar en
preferencias individuales y en la experiencia ms que en cualquier otro factor.
v Recurso de rastreo de CLI/ODBC/JDBC en la pgina 313
v Preparing and Executing SQL Statements in CLI Applications en el
manual CLI Guide and Reference, Volume 1
v Issuing SQL Statements in CLI Applications en el manual CLI Guide and
Reference, Volume 1
v Creating Static SQL with CLI/ODBC/JDBC Static Profiling en el manual
CLI Guide and Reference, Volume 1
Captulo 6. Programacin en C y C++
Consideraciones sobre programacin en
C/C++ . . . . . . . . . . . . . 176
Secuencias tri-grafo para C y C++ . . . . 176
Archivos de entrada y de salida para C y
C++ . . . . . . . . . . . . . . 176
Archivos include para C y C++ . . . . 177
Archivos include en C y C++ . . . . . 180
Sentencias de SQL incorporado en C y C++ 182
Variables del lenguaje principal en C y C++ 183
Variables del lenguaje principal en C y
C++ . . . . . . . . . . . . . 183
principal en C y C++ . . . . . . . 185
principal en C y C++ . . . . . . . 186
lenguaje principal en C y C++ . . . . 187
principal de tipo carcter fijas y
terminadas en nulo en C y C++ . . . . 189
principal de tipo carcter de longitud
variable en C o C++ . . . . . . . . 190
Variables de indicador en C y C++ . . . 191
Variables grficas del lenguaje principal
en C y C++ . . . . . . . . . . . 191
Sintaxis de la declaracin grfica de
formatos grficos de un solo grfico y
terminados en nulo en C y C++ . . . . 192
Sintaxis para la declaracin grfica del
formato estructurado VARGRAPHIC en C
o C++. . . . . . . . . . . . . 194
principal de objeto grande (LOB) en C o
C++ . . . . . . . . . . . . . 195
(LOB) en C o C++ . . . . . . . . 198
Sintaxis de declaraciones de variables del
lenguaje principal de referencia de
archivos en C o C++ . . . . . . . . 199
Inicializacin de variables del lenguaje
principal en C y C++ . . . . . . . 200
Expansin de macros en C. . . . . . 200
Soporte de estructuras del lenguaje
principal en C y C++ . . . . . . . 201
Tablas de indicadores en C y C++ . . . 203
Series terminadas en nulo en C y C++ 205
Variables del lenguaje principal utilizadas
como tipos de datos de puntero en C y
C++ . . . . . . . . . . . . . 207
Miembros de datos de clase utilizados
como variables del lenguaje principal en
C y C++ . . . . . . . . . . . . 208
Operadores de calificacin y de miembro
en C y C++ . . . . . . . . . . . 209
Codificacin de caracteres de varios bytes
en C y C++ . . . . . . . . . . . 210
Tipos de datos wchar_t y sqldbchar en C
y C++. . . . . . . . . . . . . 211
Opcin del precompilador WCHARTYPE
en C y C++ . . . . . . . . . . . 211
chino tradicional y UCS-2 en C y C++ . . 215
lenguaje principal para C y C++ . . . . 216
Consideraciones sobre tipos de datos para C
y C++. . . . . . . . . . . . . . 218
Tipos de datos SQL soportados en C y
C++ . . . . . . . . . . . . . 218
FOR BIT DATA en C y C++ . . . . . 222
Tipos de datos de C y C++ para
procedimientos, funciones y mtodos . . 223
Variables SQLSTATE y SQLCODE en C y
C++ . . . . . . . . . . . . . . 224
Consideraciones sobre programacin en C/C++
En los temas siguientes se tratan las consideraciones especiales sobre la
programacin en lenguajes principales. Se incluye informacin sobre las
restricciones de lenguaje, los archivos include especficos del lenguaje
principal, la incorporacin de sentencias de SQL y los tipos de datos
soportados para las variables del lenguaje principal.
v Programas de ejemplo C/C++ en el manual Gua de desarrollo de
Secuencias tri-grafo para C y C++
Algunos caracteres del juego de caracteres de C o C++ no estn disponibles en
todos los teclados. Dichos caracteres se pueden entrar en un programa fuente
C o C++ utilizando una secuencia de tres caracteres denominada tri-grafo. Los
tri-grafos no se reconocen en las sentencias de SQL. El precompilador
reconoce los tri-grafos siguientes dentro de las declaraciones de variables del
lenguaje principal:
Tri-grafo Definicin
??( Corchete izquierdo '['
??) Corchete derecho ']'
??< Llave izquierda '{'
??> Llave derecha '}'
Los tri-grafos restantes que se listan a continuacin se pueden producir en
cualquier lugar de un programa fuente C o C++:
Tri-grafo Definicin
??= Almohadilla '#'
??/ Barra inclinada invertida '\'
?? Signo de intercalacin '^'
??! Barra vertical '|'
?? Tilde '~'
Archivos de entrada y de salida para C y C++
Por omisin, el archivo de entrada puede tener las extensiones siguientes:
.sqc Para los archivos C en todas las plataformas soportadas
.sqC Para archivos C++ en plataformas UNIX
.sqx Para archivos C++ en sistemas operativos Windows
Por omisin, los archivos de salida del precompilador correspondiente tienen
las siguientes extensiones:
.c Para los archivos C en todas las plataformas soportadas
.C Para los archivos C++ en plataformas UNIX
.cxx Para archivos C++ en sistemas operativos Windows
Puede utilizar la opcin de precompilacin OUTPUT para alterar
temporalmente el nombre y la va de acceso del archivo fuente de salida
modificado. Si utiliza las opciones de precompilacin TARGET C o TARGET
CPLUSPLUS, no es necesario que el archivo de entrada tenga ninguna
extensin concreta.
Archivos include
Las siguientes secciones describen los archivos include correspondientes a C y
C++.
Archivos include para C y C++
Los archivos include especficos del lenguaje principal (archivos de cabecera)
para C y C++ tienen la extensin de archivo .h. A continuacin se describen
los archivos include destinados a su uso en las aplicaciones del usuario.
SQL (sql.h)
Este archivo incluye prototipos especficos del lenguaje para el
vinculador, el precompilador y las API de recuperacin de mensajes
de error. Tambin define constantes del sistema.
SQLADEF (sqladef.h)
Este archivo contiene prototipos de funciones utilizados por
aplicaciones C y C++ precompiladas.
SQLAPREP (sqlaprep.h)
Este archivo contiene definiciones necesarias para escribir su propio
precompilador.
SQLCA (sqlca.h)
Este archivo define la estructura del rea de comunicaciones de SQL
(SQLCA). El SQLCA contiene variables que utiliza el gestor de bases
de datos para proporcionar a una aplicacin informacin de error
sobre la ejecucin de sentencias de SQL y llamadas a API.
Captulo 6. Programacin en C y C++ 177
SQLCLI (sqlcli.h)
Este archivo contiene los prototipos y constantes de funciones
necesarios para escribir una aplicacin de Interfaz de nivel de llamada
(CLI de DB2). Las funciones de este archivo son comunes para la
Interfaz de nivel de llamada de X/Open y el Nivel esencial de ODBC.
SQLCLI1 (sqlcli1.h)
Este archivo contiene los prototipos y las constantes de funciones
necesarios para escribir una Interfaz de nivel de llamada (CLI de DB2)
que hace uso de las caractersticas ms avanzadas de la CLI de DB2.
Muchas de las funciones de este archivo son comunes para la Interfaz
de nivel de llamada de X/Open y el Nivel 1 de ODBC. Adems, este
archivo tambin incluye funciones slo de X/Open y funciones
especficas de DB2.
Este archivo incluye tanto sqlcli.h como sqlext.h (que contiene
definiciones de API de Nivel 2 de ODBC).
SQLCODES (sqlcodes.h)
Este archivo define constantes para el campo SQLCODE de la
estructura SQLCA.
SQLDA (sqlda.h)
Este archivo define la estructura del rea de descriptor de SQL
(SQLDA). El SQLDA se utiliza para pasar datos entre una aplicacin y
el gestor de bases de datos.
SQLEAU (sqleau.h)
Este archivo contiene definiciones de constantes y de estructuras
necesarias para las API de auditora de seguridad de DB2. Si utiliza
estas API, tiene que incluir este archivo en el programa. Este archivo
tambin contiene definiciones de constantes y de valores de palabras
clave para los campos del registro de seguimiento de auditora.
Programas externos o de extraccin de seguimiento de auditora de
proveedores pueden utilizar estas definiciones.
SQLENV (sqlenv.h)
Este archivo define llamadas especficas del lenguaje para las API del
entorno de bases de datos y las estructuras, constantes y cdigos de
retorno correspondientes a dichas interfaces.
SQLEXT (sqlext.h)
Este archivo contiene los prototipos y constantes de funciones de
aquellas API de Nivel 1 y Nivel 2 de ODBC que no forman parte de
la especificacin de la Interfaz de nivel de llamada de X/Open y, por
lo tanto, se utiliza con permiso de Microsoft Corporation.
SQLE819A (sqle819a.h)
Si la pgina de cdigos de la base de datos es 819 (ISO Latin-1), esta
secuencia clasifica series de caracteres que no son FOR BIT DATA
segn la clasificacin binaria CCSID 500 (EBCDIC internacional) del
sistema principal. La API CREATE DATABASE utiliza este archivo.
SQLE819B (sqle819b.h)
Si la pgina de cdigos de la base de datos es 819 (ISO Latin-1), esta
secuencia clasifica series de caracteres que no son FOR BIT DATA
segn la clasificacin binaria CCSID 037 (EBCDIC ingls de EE.UU.)
del sistema principal. La API CREATE DATABASE utiliza este
archivo.
Si la pgina de cdigos de la base de datos es 850 (ASCII Latin-1),
esta secuencia clasifica series de caracteres que no son FOR BIT DATA
segn la clasificacin binaria CCSID 500 (EBCDIC internacional) del
Si la pgina de cdigos de la base de datos es 850 (ASCII Latin-1),
segn la clasificacin binaria CCSID 037 (EBCDIC ingls de EE.UU.)
del sistema principal. La API CREATE DATABASE utiliza este
archivo.
Si la pgina de cdigos de la base de datos es 932 (ASCII japons),
segn la clasificacin binaria CCSID 5035 (EBCDIC japons) del
Si la pgina de cdigos de la base de datos es 932 (ASCII japons),
segn la clasificacin binaria CCSID 5026 (EBCDIC japons) del
SQLJACB (sqljacb.h)
Este archivo define constantes, estructuras y bloques de control
correspondientes a la interfaz de DB2 Connect.
SQLMON (sqlmon.h)
Este archivo define llamadas especficas del lenguaje para las API del
supervisor del sistema de bases de datos y las estructuras, constantes
y cdigos de retorno correspondientes a dichas interfaces.
SQLSTATE (sqlstate.h)
Este archivo define constantes correspondientes al campo SQLSTATE
de la estructura SQLCA.
SQLSYSTM (sqlsystm.h)
Este archivo contiene definiciones especficas de la plataforma que
utilizan las API y las estructuras de datos del gestor de bases de
datos.
SQLUDF (sqludf.h)
Este archivo define constantes y estructuras de interfaces para escribir
funciones definidas por el usuario (UDF).
SQLUTIL (sqlutil.h)
Este archivo define las llamadas especficas del lenguaje
correspondientes a las API de programas de utilidad y las estructuras,
constantes y cdigos necesarios para dichas interfaces.
SQLUV (sqluv.h)
Este archivo define estructuras, constantes y prototipos para la API
asncrona de Registro de lecturas y para las API utilizadas por los
proveedores de carga y descarga de tablas.
SQLUVEND (sqluvend.h)
Este archivo define estructuras, constantes y prototipos
correspondientes a las API que utilizarn los proveedores de gestin
de almacenamiento.
SQLXA (sqlxa.h)
Este archivo contiene prototipos y constantes de funciones utilizados
por las aplicaciones que usan la Interfaz XA de X/Open.
v Archivos include en C y C++ en la pgina 180
Archivos include en C y C++
Existen dos mtodos para incluir archivos: la sentencia EXEC SQL INCLUDE
y la macro #include. El precompilador pasar por alto #include y slo
procesar los archivos incluidos mediante la sentencia EXEC SQL INCLUDE.
Para localizar los archivos incluidos mediante EXEC SQL INCLUDE, el
precompilador C de DB2 busca en primer lugar en el directorio actual y, a
continuacin, en los directorios especificados por la variable de entorno
DB2INCLUDE. Considere los ejemplos siguientes:
v EXEC SQL INCLUDE payroll;
Si el archivo especificado en la sentencia INCLUDE no est encerrado entre
comillas, tal como en el ejemplo anterior, el precompilador C busca
payroll.sqc, y luego payroll.h, en cada uno de los directorios que mira.
En los sistemas operativos UNIX, el precompilador C++ busca payroll.sqC,
luego payroll.sqx, luego payroll.hpp y luego payroll.h en cada uno de
los directorios que mira. En los sistemas operativos Windows de 32 bits, el
precompilador C++ busca payroll.sqx, luego payroll.hpp y luego
payroll.h en cada uno de los directorios que mira.
v EXEC SQL INCLUDE pay/payroll.h;
Si el nombre de archivo est encerrado entre comillas, tal como en el caso
anterior, no se aade ninguna extensin al nombre.
Si el nombre del archivo entrecomillado no contiene una va de acceso
absoluta, se utiliza el contenido de DB2INCLUDE para buscar el archivo,
aadindole como prefijo la va de acceso especificada en el nombre del
archivo de INCLUDE. Por ejemplo, en los sistemas basados en UNIX, si
DB2INCLUDE se establece en /disk2:myfiles/c, el precompilador C/C++
busca ./pay/payroll.h, luego /disk2/pay/payroll.h y finalmente
./myfiles/c/pay/payroll.h. En los mensajes del precompilador se
muestra la va de acceso en que se encuentra realmente el archivo. En los
sistemas operativos basados en Windows, sustituya las barras inclinadas
invertidas (\) del ejemplo anterior por barras inclinadas.
Nota: el procesador de lnea de mandatos coloca en antememoria el valor de
DB2INCLUDE. Para cambiar el valor de DB2INCLUDE despus de
haber emitido mandatos del CLP, entre el mandato TERMINATE, luego
vuelva a conectar con la base de datos y realice una precompilacin del
modo habitual.
Como ayuda para relacionar los errores del compilador con la fuente original,
el precompilador genera macros ANSI #line en el archivo de salida. Esto
permite que el compilador informe de los errores utilizando el nombre de
archivo y el nmero de lnea del archivo fuente o fuente incluido, en lugar de
la salida del precompilador.
Sin embargo, si se especifica la opcin PREPROCESSOR, todas las macros
#line generadas por el precompilador hacen referencia al archivo preprocesado
por el preprocesador C externo.
Algunos depuradores y otras herramientas que relacionan cdigo fuente con
cdigo objeto no siempre funcionan bien con la macro #line. Si la herramienta
que desea utilizar se comporta de forma inesperada, utilice la opcin
NOLINEMACRO (usada con DB2 PREP) cuando realice la precompilacin.
Esta opcin evita que se generen macros #line.
v Expansin de macros en C en la pgina 200
v Archivos include para C y C++ en la pgina 177
Sentencias de SQL incorporado en C y C++
Las sentencias de SQL incorporado constan de los tres elementos siguientes:
Elemento Sintaxis correcta
Inicializador de la sentencia EXEC SQL
Serie de la sentencia Cualquier sentencia de SQL vlida
Terminador de la sentencia punto y coma (;)
Por ejemplo:
EXEC SQL SELECT col INTO :hostvar FROM table;
Se aplican las normas siguientes a las sentencias de SQL incorporado:
v Puede empezar la serie de la sentencia de SQL en la misma lnea que el par
de palabras clave o en una lnea separada. La serie de la sentencia puede
tener una longitud de varias lneas. No divida el par de palabras clave
EXEC SQL en distintas lneas.
v Debe utilizar el terminador de sentencias de SQL. De no utilizarlo, el
precompilador seguir hasta el siguiente terminador de la aplicacin. Esto
puede producir errores indeterminados.
Se pueden colocar comentarios de C/C++ delante del inicializador de la
sentencia o detrs del terminador de la sentencia.
v Se pueden poner varias sentencias de SQL y de C/C++ en la misma lnea.
Por ejemplo:
EXEC SQL OPEN c1; if (SQLCODE >= 0) EXEC SQL FETCH c1 INTO :hv;
v El precompilador SQL deja tal cual los retornos de carro, saltos de lnea y
tabulaciones que aparecen en una serie entrecomillada.
v Estn permitidos los comentarios de SQL en cualquier lnea que forme
parte de una sentencia de SQL incorporado. Estos comentarios no estn
permitidos en las sentencias que se ejecutan de forma dinmica. El formato
de un comentario de SQL consiste en un guin doble (--) seguido de una
serie compuesta por cero o ms caracteres y terminado por un fin de lnea.
No coloque comentarios de SQL despus del terminador de sentencia de
SQL. Los comentarios despus del terminador generan errores de
compilacin porque parece que formen parte del lenguaje C/C++.
Puede utilizar comentarios en la serie de una sentencia esttica siempre que
se permitan caracteres en blanco. Utilice los delimitadores de comentarios
de C/C++ /* */ o el smbolo de comentario de SQL (--). Los comentarios
de C++ del estilo // no estn permitidos en las sentencias de SQL esttico,
pero se pueden utilizar en cualquier otro lugar del programa. El
precompilador elimina los comentarios antes de procesar la sentencia de
SQL. No puede utilizar los delimitadores de comentario de C y C++ /* */
ni // en una sentencia de SQL dinmico. Sin embargo, los puede utilizar en
cualquier otro lugar del programa.
v Puede continuar los literales de la serie de SQL y los identificadores
delimitados con divisiones de lnea en las aplicaciones C y C++. Para ello,
utilice una barra inclinada invertida (\) al final de la lnea en que desea que
se produzca la divisin. Por ejemplo:
EXEC SQL SELECT "NA\
ME" INTO :n FROM staff WHERE name=Sa\
nders;
Los caracteres de lnea nueva (como, por ejemplo, el retorno de carro y el
salto de lnea) no se incluyen en la serie ni en el identificador delimitado.
v La sustitucin de caracteres de espacio en blanco, como caracteres de fin de
lnea y de tabulacin, se produce del siguiente modo:
Cuando aparecen fuera de las comillas (pero dentro de sentencias de
SQL), los caracteres de fin de lnea y tabuladores se sustituyen por un
solo espacio.
Si aparecen dentro de las comillas, los caracteres de fin de lnea
desaparecen, siempre que se contine correctamente la serie para un
programa C. Los tabuladores no se modifican.
Observe que los caracteres reales utilizados como fin de lnea y tabulador
varan en funcin de la plataforma. Por ejemplo, los sistemas basados en
UNIX utilizan un salto de lnea.
Variables del lenguaje principal en C y C++
Las secciones siguientes describen cmo declarar y utilizar variables del
lenguaje principal en programas C y C++.
Variables del lenguaje principal en C y C++
Las variables del lenguaje principal son variables de los lenguajes C o C++ a
las que se hace referencia en las sentencias de SQL. Permiten que una
aplicacin pase datos de entrada al gestor de bases de datos y reciba datos de
salida de ste. Una vez que se ha precompilado la aplicacin, el compilador
utiliza las variables del lenguaje principal como cualquier otra variable de
C/C++. Cuando denomine, declare y utilice variables del lenguaje principal,
siga las normas descritas en los apartados siguientes.
En aplicaciones que construyen del SQLDA de forma manual, no se pueden
utilizar variables tipo long cuando sqlvar::sqltype==SQL_TYP_INTEGER. En
su lugar se deben utilizar tipos sqlint32. Este problema es idntico a utilizar
variables long en declaraciones de variables del lenguaje principal, excepto en
que con una SQLDA construida de forma manual el precompilador no
revelar este error y se producirn errores en el tiempo de ejecucin.
Las difusiones de long y unsigned long que se utilizan para acceder a
informacin sqlvar::sqldata se deben cambiar por sqlint32 y sqluint32. Los
miembros val correspondientes a las estructuras sqloptions y sqla_option se
declaran como sqluintptr. Por lo tanto, la asignacin de miembros de puntero
en miembros sqla_option::val o sqloptions::val deben utilizar difusiones
sqluintptr en lugar de difusiones unsigned long. Este cambio no ocasionar
problemas en el tiempo de ejecucin en plataformas UNIX de 64 bits, pero se
debe realizar como preparacin para aplicaciones Windows NT de 64 bits, en
las que el tipo long slo es de 32 bits.
v Nombres de variables del lenguaje principal en C y C++ en la pgina 185
v Declaraciones de variables del lenguaje principal en C y C++ en la pgina
186
v Variables de indicador en C y C++ en la pgina 191
v Variables grficas del lenguaje principal en C y C++ en la pgina 191
v Inicializacin de variables del lenguaje principal en C y C++ en la pgina
200
v Soporte de estructuras del lenguaje principal en C y C++ en la pgina 201
v Seccin declare de SQL con variables del lenguaje principal para C y C++
en la pgina 216
la pgina 187
Nombres de variables del lenguaje principal en C y C++
El precompilador SQL identifica las variables del lenguaje principal por el
nombre declarado para stas. Se aplican las normas siguientes:
v Especifique nombres de variables con una longitud mxima de 255
caracteres.
v Empiece los nombres de variables con prefijos que no sean SQL, sql, DB2 ni
db2, los cuales estn reservados para uso del sistema. Por ejemplo:
char varsql; /* permitido */
char sqlvar; /* no permitido */
char SQL_VAR; /* no permitido */
v El precompilador considera los nombres de variables del lenguaje principal
como globales respecto a un mdulo. Sin embargo, esto no significa que las
variables del lenguaje principal se tengan que definir como variables
globales; es perfectamente aceptable que se declaren variables del lenguaje
principal como variables locales dentro de funciones. Por ejemplo, el cdigo
siguiente funcionar correctamente:
void f1(int i)
{
short host_var_1;
EXEC SQL SELECT COL1 INTO :host_var_1 from TBL1;
}
void f2(int i)
{
short host_var_2;
EXEC SQL INSERT INTO TBL1 VALUES (:host_var_2);
}
Tambin es posible tener varias variables del lenguaje principal locales con
el mismo nombre, siempre que sean del mismo tipo y tamao. Para ello,
declare la primera aparicin de la variable del lenguaje principal, ante el
precompilador, entre sentencias BEGIN DECLARE SECTION y END
DECLARE SECTION, y deje las declaraciones posteriores de la variable
fuente de las secciones de declaracin. El cdigo siguiente muestra un
ejemplo de este caso:
void f3(int i)
{
char host_var_3[25];
EXEC SQL SELECT COL2 INTO :host_var_3 FROM TBL2;
}
void f4(int i)
{
char host_var_3[25];
EXEC SQL INSERT INTO TBL2 VALUES (:host_var_3);
}
Puesto que f3 y f4 estn en el mismo mdulo y host_var_3 tiene el mismo
tipo y longitud en ambas funciones, basta una sola declaracin ante el
precompilador para utilizarla en ambos lugares.
186
Declaraciones de variables del lenguaje principal en C y C++
Se debe utilizar una seccin de declaracin de SQL para identificar las
declaraciones de variables del lenguaje principal. Esto alerta al precompilador
acerca de las variables del lenguaje principal a las que se puede hacer
referencia en sentencias de SQL posteriores.
El precompilador C/C++ slo reconoce un subconjunto de declaraciones de C
o C++ vlidas como declaraciones de variables del lenguaje principal vlidas.
Estas declaraciones definen variables numricas o de tipo carcter. No se
admiten las definiciones de tipo para los tipos de variable del lenguaje
principal. Las variables del lenguaje principal se pueden agrupar en una sola
estructura de lenguaje principal. Puede declarar miembros de datos de clase
C++ como variables del lenguaje principal.
Una variable numrica del lenguaje principal se puede utilizar como variable
de entrada o de salida para cualquier valor numrico de entrada o salida de
SQL. Una variable del lenguaje principal de tipo carcter se puede utilizar
como variable de entrada o de salida para cualquier valor de tipo carcter, de
fecha, de hora o de indicacin horaria, de entrada o salida de SQL. La
aplicacin se tiene que asegurar de que las variables de salida sean lo
suficientemente largas como para contener los valores que reciben.
v Miembros de datos de clase utilizados como variables del lenguaje
principal en C y C++ en la pgina 208
v Declaracin de variables del lenguaje principal de tipo estructurado en el
servidor
la pgina 187
Sintaxis de las variables numricas del lenguaje principal en C y C++
A continuacin se muestra la sintaxis para declarar variables numricas del
lenguaje principal en C o C++.
Sintaxis de las variables numricas del lenguaje principal en C o C++
auto
extern
static
register
const
volatile
(1)
float
(2)
double
(3)
short
int
INTEGER (SQLTYPE 496)
BIGINT (SQLTYPE 492)
,
nombrevar
= valor
*
& const
volatile
;
INTEGER (SQLTYPE 496)
sqlint32
(4)
long
int
BIGINT (SQLTYPE 492)
sqlint64
__int64
long long
int
(5)
long
int
Notas:
1 REAL (SQLTYPE 480), longitud 4
2 DOUBLE (SQLTYPE 480), longitud 8
3 SMALLINT (SQLTYPE 500)
4 Para obtener una portabilidad mxima de las aplicaciones utilice sqlint32
y sqlint64 respectivamente para las variables del lenguaje principal
INTEGER y BIGINT. Por omisin, el uso de variables del lenguaje
principal tipo long tiene como consecuencia el error del precomiplador
SQL0402 en las plataformas en que la longitud es una cantidad de 64
bits, como por ejemplo en UNIX de 64 BITS. Utilice la opcin
LONGERROR NO de PREP para imponer que DB2 acepte variables long
como tipos de variable del lenguaje principal aceptables y las trate como
variables BIGINT.
5 Para obtener una portabilidad mxima de las aplicaciones
utilice, respectivamente, sqlint32 y sqlint64 para las variables del
lenguaje principal INTEGER y BIGINT. Para utilizar el tipo de
datos BIGINT, la plataforma tiene que soportar valores enteros de 64
bits. Por omisin, el uso de variables del lenguaje principal tipo long
tiene como consecuencia el error del precomiplador SQL0402 en las
plataformas en que la longitud es una cantidad de 64 bits, como por
ejemplo en UNIX de 64 BITS. Utilice la opcin LONGERROR NO de
PREP para imponer que DB2 acepte variables long como tipos de
variable del lenguaje principal aceptables y las trate como variables
BIGINT.
Sintaxis de las variables del lenguaje principal de tipo carcter fijas y
terminadas en nulo en C y C++
A continuacin se muestra la sintaxis para declarar variables del lenguaje
principal de tipo carcter fijas y terminadas en nulo en C o C++.
Sintaxis de las variables del lenguaje principal de tipo carcter fijas y terminadas
en nulo en C o C++
auto
extern
static
register
const
volatile
char
unsigned

,
CHAR
Serie C = valor
;
CHAR
(1)
nombrevar
*
& const
volatile
Serie C
(2)
nombrevar [longitud]
( nombrevar )
*
& const
volatile
Notas:
1 CHAR (SQLTYPE 452), length 1
2 Serie C terminada en nulo (SQLTYPE 460); la longitud puede
ser cualquier expresin constante vlida
Sintaxis de las variables del lenguaje principal de tipo carcter de
longitud variable en C o C++
principal de tipo carcter de longitud variable en C o C++.
Sintaxis para variables del lenguaje principal de tipo carcter de longitud variable
en C o C++
auto
extern
static
register
const
volatile
struct
cdigo
(1)
{ short var1 ; char var2 [longitud] ; }
int unsigned
,
nombrevar
Valores
*
& const
volatile
;
Valores
= { valor-1 , valor-2 }
Notas:
1 En el formato 2, la longitud puede ser cualquier expresin
constante vlida. Su valor despus de una evaluacin determina si la
variable del lenguaje principal es VARCHAR (SQLTYPE 448) o LONG
VARCHAR (SQLTYPE 456).
Consideraciones sobre las variables del lenguaje principal de tipo carcter
de longitud variable:
1. Aunque el gestor de bases de datos convierte los datos de tipo carcter al
formato 1 o al formato 2 siempre que es posible, el formato 1 corresponde
a los tipos de columna CHAR o VARCHAR, mientras que el formato 2
corresponde a los tipos de columna VARCHAR y LONG VARCHAR.
2. Si se utiliza el formato 1 con un especificador de longitud [n], el valor
correspondiente al especificador de longitud tras la evaluacin no debe ser
mayor que 32672 y la serie contenida en la variable debe terminar en nulo.
3. Si se utiliza el formato 2, el valor correspondiente al especificador de
longitud tras la evaluacin no debe ser mayor que 32700.
4. En el formato 2, var1 y var2 deben ser simples referencias a variables (y no
operadores) y no se pueden utilizar como variables del lenguaje principal
(nombrevar es la variable del lenguaje principal).
5. nombrevar puede ser un simple nombre de variable o puede incluir
operadores, como por ejemplo *nombrevar. Consulte la descripcin de los
tipos de datos de puntero en C y C++ para obtener ms informacin.
6. El precompilador determina el SQLTYPE y la SQLLEN de todas las
variables del lenguaje principal. Si una variable del lenguaje principal
aparece en una sentencia de SQL con una variable de indicador, mientras
dure esa sentencia se asigna como SQLTYPE el SQLTYPE base ms uno.
7. El precompilador permite algunas declaraciones que no son vlidas
sintcticamente en C ni en C++. Si tiene dudas acerca de la sintaxis de una
declaracin determinada, consulte la documentacin del compilador.
v Variables del lenguaje principal utilizadas como tipos de datos de puntero
en C y C++ en la pgina 207
Variables de indicador en C y C++
Las variables de indicador se deben declarar con tipo de datos short.
v Tablas de indicadores en C y C++ en la pgina 203
Variables grficas del lenguaje principal en C y C++
Para manejar datos grficos en aplicaciones C o C++, utilice variables del
lenguaje principal basadas en el tipo de datos wchar_t de C/C++ o en el tipo
de datos sqldbchar proporcionado por DB2. Puede asignar estos tipos de
variables del lenguaje principal a las columnas de una tabla que sean
GRAPHIC, VARGRAPHIC o DBCLOB. Por ejemplo, puede actualizar o
seleccionar datos DBCS de las columnas GRAPHIC o VARGRAPHIC de una
tabla.
Existen tres formatos vlidos para una variable grfica del lenguaje principal:
v Formato de grfico simple
Las variables de grfico simple del lenguaje principal tienen para SQLTYPE
el valor 468/469, lo que equivale al tipo de datos GRAPHIC(1) de SQL.
v Formato de grfico terminado en nulo
Terminado en nulo hace referencia a una situacin en que todos los bytes
del ltimo carcter de la serie grfica contienen ceros binarios ('\0's). Tienen
para SQLTYPE el valor 400/401.
v Formato estructurado VARGRAPHIC
Las variables de formato estructurado VARGRAPHIC del lenguaje principal
tienen para SQLTYPE el valor 464/465 si su longitud est comprendida
entre 1 y 16.336 bytes. Tienen para SQLTYPE el valor 472/473 si su longitud
est comprendida entre 2.000 y 16.350 bytes.
v Nombres de variables del lenguaje principal en C y C++ en la pgina 185
186
v Inicializacin de variables del lenguaje principal en C y C++ en la pgina
200
v Codificacin de caracteres de varios bytes en C y C++ en la pgina 210
v Tipos de datos wchar_t y sqldbchar en C y C++ en la pgina 211
v Opcin del precompilador WCHARTYPE en C y C++ en la pgina 211
v Sintaxis de la declaracin grfica de formatos grficos de un solo grfico y
terminados en nulo en C y C++ en la pgina 192
v Sintaxis para la declaracin grfica del formato estructurado
VARGRAPHIC en C o C++ en la pgina 194
Sintaxis de la declaracin grfica de formatos grficos de un solo grfico
y terminados en nulo en C y C++
A continuacin se muestra la sintaxis para declarar una variable del lenguaje
principal grfica mediante el formato de un solo grfico y el formato de
grfico terminado en nulo.
Sintaxis para la declaracin grfica de formato de un solo grfico y formato
grfico terminado en nulo
auto
extern
static
register
const
volatile
(1)
sqldbchar
wchar_t
,
CHAR
Serie C = valor
;
CHAR
(2)
nombrevar
*
& const
volatile
Serie C
(3)
nombrevar [longitud]
( nombrevar )
*
& const
volatile
Notas:
1 Para determinar cul de los dos tipos grficos debe utilizar, consulte la
descripcin de los tipos de datos wchar_t y sqldbchar en C y C++.
2 GRAPHIC (SQLTYPE 468), longitud 1
3 Serie grfica terminada en nulo (SQLTYPE 400)
Consideraciones sobre las variables del lenguaje principal de grficos:
1. El formato de grfico simple declara una variable del lenguaje principal de
serie grfica y longitud fija de longitud 1 con un SQLTYPE de 468 469.
2. valor es un inicializador. Se debe utilizar un literal de serie de caracteres
amplios (literal L) si se utiliza la opcin WCHARTYPE CONVERT del
precompilador.
3. longitud puede ser cualquier expresin constante vlida, y su valor
despus de una evaluacin tiene que ser mayor o igual a 1 y no mayor
que la longitud mxima de VARGRAPHIC, que es 16336.
4. Las series grficas terminadas en nulo se manejan de forma distinta en
funcin del valor del establecimiento de opciones de precompilacin de
nivel estndar.
v Series terminadas en nulo en C y C++ en la pgina 205
Sintaxis para la declaracin grfica del formato estructurado
VARGRAPHIC en C o C++
A continuacin se muestra la sintaxis para declarar una variable del lenguaje
principal grfica mediante el formato estructurado VARGRAPHIC.
Sintaxis para la declaracin grfica del formato estructurado VARGRAPHIC
auto
extern
static
register
const
volatile
struct
cdigo
(1) (2)
{ short var-1 ; var-2 [longitud ] ; }
int sqldbchar
wchar_t
,
Variable ;
*
& const
volatile
Variable:
nombre-variable
= { valor-1 , valor-2 }
Notas:
1 Para determinar cul de los dos tipos grficos debe utilizar, consulte la
descripcin de los tipos de datos wchar_t y sqldbchar en C y C++.
2 longitud puede ser cualquier expresin de constante vlida. Su valor
despus de una evaluacin determina si la variable del lenguaje
principal es VARGRAPHIC (SQLTYPE 464) o LONG VARGRAPHIC
(SQLTYPE 472). El valor de longitud debe ser mayor o igual que 1 y
menor o igual que la longitud mxima de LONG VARGRAPHIC, que es
16350.
Consideraciones sobre la declaracin grfica (formato estructurado
VARGRAPHIC):
1. var-1 y var-2 deben ser simples referencias a variables (y no operadores) y
no se pueden utilizar como variables del lenguaje principal.
2. valor-1 y valor-2 son inicializadores de var-1 y var-2.valor-1 debe ser un
entero y valor-2 debe ser un literal de serie de caracteres amplios (literal L)
si se utiliza la opcin WCHARTYPE CONVERT del precompilador.
3. Se puede utilizar el cdigo struct para definir otras reas de datos, pero no
se puede utilizar por s mismo como variable del lenguaje principal.
Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
C o C++
principal de objeto grande (LOB) en C o C++.
Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en C o
C++
auto
extern
static
register
const
volatile
SQL TYPE IS BLOB
CLOB
DBCLOB
(1)
(longitud )
,
nombre-variable Datos LOB
*
& const
volatile
;
Datos LOB
={long-inic,datos-inic}
=SQL_BLOB_INIT(datos-inic)
=SQL_CLOB_INIT(datos-inic)
=SQL_DBCLOB_INIT(datos-inic)
Notas:
1 longitud puede ser cualquier expresin de constante vlida en la que se
pueden utilizar las constantes K, M o G. El valor de la longitud despus
de una evaluacin para BLOB y CLOB debe ser 1 <= longitud <=
2.147.483.647. El valor de longitud tras la evaluacin correspondiente a
DBCLOB debe ser 1 <= longitud <= 1.073.741.823.
Consideraciones sobre las variables del lenguaje principal LOB:
1. Se necesita la clusula SQL TYPE IS para poder distinguir los tres tipos de
LOB entre s, de forma que se puedan llevar a cabo una comprobacin del
tipo y una resolucin de la funcin para las variables del lenguaje
principal de tipo LOB que se pasan a las funciones.
2. SQL TYPE IS, BLOB, CLOB, DBCLOB, K, M, G se pueden especificar en
una mezcla de maysculas y minsculas.
3. La longitud mxima permitida para la serie de inicializacin datos-inic es
32702 bytes, incluidos los delimitadores de la serie (igual al lmite existente
en series C/C++ dentro del precompilador).
4. La longitud de inicializacin, long-inic, tiene que ser una constante
numrica (esto es, no puede incluir K, M ni G).
5. Se debe especificar una longitud para el LOB; es decir, que la declaracin
siguiente no est permitida:
SQL TYPE IS BLOB my_blob;
6. Si el LOB no se inicializa dentro de la declaracin, no se realizar ninguna
inicializacin en el cdigo generado por el precompilador.
7. Si se inicializa un DBCLOB, es responsabilidad del usuario aadirle a la
serie el prefijo L (que indica una serie de caracteres amplios).
Nota: los literales de caracteres amplios, por ejemplo L"Hello", slo se
deben utilizar en un programa precompilado si se selecciona la
opcin WCHARTYPE CONVERT de precompilacin.
8. El precompilador genera un cdigo de estructura que se puede utilizar
para pasarlo al tipo de la variable del lenguaje principal.
Ejemplo de BLOB:
La declaracin:
static Sql Type is Blob(2M) my_blob=SQL_BLOB_INIT("mydata");
Tiene como resultado la generacin de la estructura siguiente:
static struct my_blob_t {
sqluint32 length;
char data[2097152];
} my_blob=SQL_BLOB_INIT("mydata");
Ejemplo de CLOB:
La declaracin:
volatile sql type is clob(125m) *var1, var2 = {10, "data5data5"};
volatile struct var1_t {
sqluint32 length;
char data[131072000];
} * var1, var2 = {10, "data5data5"};
Ejemplo de DBCLOB:
La declaracin:
SQL TYPE IS DBCLOB(30000) my_dbclob1;
Si se precompila con la opcin WCHARTYPE NOCONVERT, tiene como
resultado la generacin de la estructura siguiente:
struct my_dbclob1_t {
sqluint32 length;
sqldbchar data[30000];
} my_dbclob1;
La declaracin:
SQL TYPE IS DBCLOB(30000) my_dbclob2 = SQL_DBCLOB_INIT(L"mydbdata");
Si se precompila con la opcin WCHARTYPE CONVERT, tiene como
resultado la generacin de la estructura siguiente:
struct my_dbclob2_t {
sqluint32 length;
wchar_t data[30000];
} my_dbclob2 = SQL_DBCLOB_INIT(L"mydbdata");
Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en C o C++
principal de localizador de objeto grande (LOB) en C o C++.
Sintaxis de las variables del lenguaje principal de localizador de objeto grande
(LOB) en C o C++
auto
extern
static
register
const
volatile
SQL TYPE IS BLOB_LOCATOR
CLOB_LOCATOR
DBCLOB_LOCATOR

,
Variable
;
Variable
* nombre-variable
& const = valor-inic
volatile
Consideraciones sobre las variables del lenguaje principal de localizador de
LOB:
1. SQL TYPE IS, BLOB_LOCATOR, CLOB_LOCATOR, DBCLOB_LOCATOR
se pueden especificar en una mezcla de maysculas y minsculas.
2. valor-inic permite la inicializacin de variables de localizador de puntero y
referencia. Otros tipos de inicializacin no tendrn ningn significado.
Ejemplo de localizador de CLOB (existen otras declaraciones de tipos de
localizador de LOB parecidas):
La declaracin:
SQL TYPE IS CLOB_LOCATOR my_locator;
Tiene como resultado la generacin de la declaracin siguiente:
sqlint32 my_locator;
Sintaxis de declaraciones de variables del lenguaje principal de referencia
de archivos en C o C++
principal de referencia de archivos en C o C++.
Sintaxis de las variables del lenguaje principal de referencia de archivos en C o
C++
auto
extern
static
register
const
volatile
SQL TYPE IS BLOB_FILE
CLOB_FILE
DBCLOB_FILE
,
Variable
;
Variable
* nombre-variable
& const = valor-inic
volatile
Nota: SQL TYPE IS, BLOB_FILE, CLOB_FILE, DBCLOB_FILE se pueden
especificar en una mezcla de maysculas y minsculas.
Ejemplo de referencia de archivos CLOB (existen otras declaraciones de tipo
de referencia de archivos LOB parecidas):
La declaracin:
static volatile SQL TYPE IS BLOB_FILE my_file;
static volatile struct {
sqluint32 name_length;
sqluint32 data_length;
sqluint32 file_options;
char name[255];
} my_file;
Inicializacin de variables del lenguaje principal en C y C++
En las secciones declare de C++ no se pueden inicializar variables del lenguaje
principal mediante parntesis. El ejemplo siguiente muestra los mtodos
correcto e incorrecto de inicializacin en una seccin de declaracin:
short my_short_2 = 5; /* correcto */
short my_short_1(5); /* incorrecto */
Expansin de macros en C
El precompilador C/C++ no puede procesar directamente ninguna macro de
C utilizada en una declaracin dentro de una seccin de declaracin. En lugar
de esto, en primer lugar se debe preprocesar el archivo fuente mediante un
preprocesador de C externo. Para ello, especifique el mandato exacto para
invocar un preprocesador de C para el precompilador mediante la opcin
PREPROCESSOR.
Cuando se especifica la opcin PREPROCESSOR, el precompilador procesa en
primer lugar todas las sentencias SQL INCLUDE, incorporando al archivo
fuente el contenido de todos los archivos a los que se hace referencia en la
sentencia de SQL INCLUDE. A continuacin, el precompilador invoca al
preprocesador de C externo, utilizando el mandato que se especifique con el
archivo fuente modificado como entrada. El archivo preprocesado, del cual el
precompilador siempre espera que tenga la extensin .i, se utiliza como el
nuevo archivo fuente para el resto del proceso de precompilacin.
Cualquier macro #line generada por el precompilador deja de hacer referencia
al archivo fuente original, pasando a hacerla al archivo preprocesado. Para
relacionar los errores del compilador con el archivo fuente original, mantenga
comentarios en el archivo preprocesado. Le sern de ayuda para localizar
diversas secciones de los archivos fuente originales, incluidos los archivos de
cabecera. La opcin para mantener comentarios suele estar disponible en los
preprocesadores C y la puede incluir en el mandato que especifique mediante
la opcin PREPROCESSOR. No debe hacer que el preprocesador de C
produzca por s mismo como salida ninguna macro #line, puesto que se
podran mezclar incorrectamente con las generadas por el precompilador.
Notas sobre la utilizacin de la expansin de macros:
1. El mandato que especifique mediante la opcin PREPROCESSOR debe
incluir todas las opciones deseadas, pero no el nombre del archivo de
entrada. Por ejemplo, para C de IBM en AIX puede utilizar la opcin:
xlC -P -DMYMACRO=1
2. El precompilador espera que el mandato genere un archivo preprocesado
con la extensin .i. Sin embargo, no se puede utilizar la redireccin para
generar el archivo preprocesado. Por ejemplo, no se puede utilizar la
opcin siguiente para generar un archivo preprocesado:
xlC -E > x.i
3. Los errores que encuentre el preprocesador de C externo se notifican en un
archivo que tiene el nombre correspondiente al archivo fuente original
pero con la extensin .err.
Por ejemplo, puede utilizar la expansin de macros en el cdigo fuente tal
como se indica a continuacin:
#define SIZE 3
char a[SIZE+1];
char b[(SIZE+1)*3];
struct
{
short length;
char data[SIZE*6];
} m;
SQL TYPE IS BLOB(SIZE+1) x;
SQL TYPE IS CLOB((SIZE+2)*3) y;
SQL TYPE IS DBCLOB(SIZE*2K) z;
Las declaraciones anteriores se resuelven de la manera siguiente despus de
utilizar la opcin PREPROCESSOR:
char a[4];
char b[12];
struct
{
short length;
char data[18];
} m;
SQL TYPE IS BLOB(4) x;
SQL TYPE IS CLOB(15) y;
SQL TYPE IS DBCLOB(6144) z;
Soporte de estructuras del lenguaje principal en C y C++
Con el soporte de estructuras del lenguaje principal, el precompilador C/C++
permite agrupar las variables del lenguaje principal en una sola estructura del
lenguaje principal. Esta funcin brinda una nota taquigrfica para hacer
referencia a ese mismo conjunto de variables del lenguaje principal en una
sentencia de SQL. Por ejemplo, se puede utilizar la siguiente estructura del
lenguaje principal para acceder a algunas de las columnas de la tabla STAFF
de la base de datos SAMPLE:
struct tag
{
short id;
struct
{
short length;
char data[10];
} name;
struct
{
short years;
double salary;
} info;
} staff_record;
Los campos de una estructura del lenguaje principal pueden ser de cualquiera
de los tipos de variable del lenguaje principal vlidos. Los tipos vlidos
incluyen todos los tipos numricos, de carcter y de objetos grande. Tambin
se soportan estructuras del lenguaje principal anidadas hasta 25 niveles. En el
ejemplo anterior, el campo info es una subestructura, mientras que el campo
name no lo es, puesto que representa un campo VARCHAR. Se aplica el mismo
principio a LONG VARCHAR, VARGRAPHIC y LONG VARGRAPHIC.
Asimismo, se soportan punteros a las estructuras del lenguaje principal.
Existen dos maneras de hacer referencia a las variables del lenguaje principal
agrupadas en una estructura del lenguaje principal en una sentencia de SQL:
v Se puede hacer referencia al nombre de la estructura del lenguaje principal
en una sentencia de SQL.
EXEC SQL SELECT id, name, years, salary
INTO :staff_record
FROM staff
WHERE id = 10;
El precompilador convierte la referencia a staff_record en una lista de
todos los campos declarados en la estructura del lenguaje principal,
separados por comas. Cada campo se califica con los nombres de estructura
del lenguaje principal de todos los niveles, a fin de evitar conflictos de
denominacin con otras variables del lenguaje principal o campos. Esto es
equivalente al mtodo siguiente.
v Se puede hacer referencia a nombres de estructuras del lenguaje principal
completamente calificadas en una sentencia de SQL.
INTO :staff_record.id, :staff_record.name,
:staff_record.info.years, :staff_record.info.salary
FROM staff
WHERE id = 10;
Las referencias a nombres de campos se deben calificar por completo
aunque no existan otras variables del lenguaje principal que tengan el
mismo nombre. Tambin se puede hacer referencia a subestructuras
calificadas. En el ejemplo anterior, se puede utilizar :staff_record.info
para sustituir a :staff_record.info.years, :staff_record.info.salary.
Puesto que una referencia a una estructura del lenguaje principal (primer
ejemplo) es equivalente a una lista de sus campos, separados por comas,
existen casos en que este tipo de referencia puede conducir a un error. Por
ejemplo:
EXEC SQL DELETE FROM :staff_record;
Aqu, la sentencia DELETE espera una sola variable del lenguaje principal
basada en caracteres. Si en su lugar se proporciona una estructura del lenguaje
principal, la sentencia tiene como resultado un error durante la
precompilacin:
SQL0087N La variable del lenguaje principal "staff_record" es una estructura que se utiliza
donde no se permiten referencias a estructuras.
Otros usos de las estructuras del lenguaje principal que pueden ocasionar que
se produzca un error SQL0087N incluyen: PREPARE, EXECUTE IMMEDIATE,
CALL, variables de indicador y referencias a SQLDA. Las estructuras del
lenguaje principal que tengan exactamente un campo estn permitidas en
estas situaciones, puesto que constituyen referencias a campos individuales
(segundo ejemplo).
Tablas de indicadores en C y C++
Una tabla de indicadores es un conjunto de variables de indicador que se
utilizarn con una estructura del lenguaje principal. Se debe declarar como
matriz de enteros cortos. Por ejemplo:
short ind_tab[10];
El ejemplo anterior declara una tabla de indicadores con 10 elementos. El
siguiente ejemplo muestra la manera en que se puede utilizar en una
sentencia de SQL:
INTO :staff_record INDICATOR :ind_tab
FROM staff
WHERE id = 10;
A continuacin se lista cada campo de la estructura del lenguaje principal con
la variable de indicador correspondiente en la tabla:
staff_record.id ind_tab[0]
staff_record.name ind_tab[1]
staff_record.info.years ind_tab[2]
staff_record.info.salary ind_tab[3]
Nota: en una sentencia de SQL no se puede hacer referencia, de forma
individual, a un elemento de una tabla de indicadores, por ejemplo
ind_tab[1]. La palabra clave INDICATOR es opcional. No es necesario
que el nmero de campos de estructura y de indicadores coincida; los
indicadores de ms no se utilizan ni tampoco los campos de ms que
no tienen indicadores asignados.
En lugar de una tabla de indicadores, tambin se puede utilizar una variable
de indicador escalar para proporcionar un indicador para el primer campo de
la estructura del lenguaje principal. Esto equivale a tener una tabla de
indicadores con un solo elemento. Por ejemplo:
short scalar_ind;
INTO :staff_record INDICATOR :scalar_ind
FROM staff
WHERE id = 10;
Si se especifica una tabla de indicadores junto con una variable del lenguaje
principal en lugar de una estructura del lenguaje principal, slo se utilizar el
primer elemento de la tabla de indicadores, por ejemplo ind_tab[0]:
EXEC SQL SELECT id
INTO :staff_record.id INDICATOR :ind_tab
FROM staff
WHERE id = 10;
Si se declara una matriz de enteros cortos en una estructura del lenguaje
principal:
struct tag
{
short i[2];
} test_record;
La matriz se expandir en sus elementos cuando se haga referencia a
test_record en una sentencia de SQL, haciendo que :test_record sea
equivalente a :test_record.i[0], :test_record.i[1].
Series terminadas en nulo en C y C++
Las series terminadas en nulo de C/C++ tienen su propio SQLTYPE (460/461
para caracteres y 468/469 para grficos).
Las series terminadas en nulo de C/C++ se manejan de forma distinta en
funcin del valor de la opcin LANGLEVEL del precompilador. Si se
especifica una variable del lenguaje principal con uno de estos SQLTYPE y la
longitud declarada n dentro de una sentencia de SQL y el nmero de bytes de
datos (para tipos de carcter) o de caracteres de doble byte (para tipos de
grficos) es k, sucede lo siguiente:
v Si la opcin LANGLEVEL del mandato PREP es SAA1 (valor por omisin):
Para la salida:
Si... Sucede que...
k > n Se mueven n caracteres a la variable del
lenguaje principal de destino, SQLWARN1
se establece en 'W' y SQLCODE es 0
(SQLSTATE 01004). No se coloca ningn
terminador nulo en la serie. Si se ha
especificado una variable de indicador con
la variable del lenguaje principal, el valor
de la variable de indicador se establece en k.
k = n Se mueven k caracteres a la variable del
se establece en 'N' y SQLCODE es 0
(SQLSTATE 01004). No se coloca ningn
terminador nulo en la serie. Si se ha
de la variable de indicador se establece en
0.
k < n Se mueven k caracteres a la variable del
lenguaje principal de destino y se coloca un
carcter nulo en el carcter k + 1. Si se ha
0.
Para la entrada:
Cuando el gestor de bases de datos encuentre una variable
del lenguaje principal de entrada que tiene uno de estos
SQLTYPE y no finaliza por un terminador nulo, supondr
que el carcter n+1 va a contener el carcter terminador
nulo.
v Si la opcin LANGLEVEL del mandato PREP es MIA:
Para la salida:
Si... Sucede que...
k >= n Se mueven n - 1 caracteres a la variable del
se establece en 'W' y SQLCODE es 0
(SQLSTATE 01004). El carcter nmero n se
establece como terminador nulo. Si se ha
de la variable de indicador se establece en k.
k + 1 = n Se mueven k caracteres a la variable del
lenguaje principal de destino y se coloca el
terminador nulo en el carcter n. Si se ha
0.
k + 1 < n Se mueven k caracteres a la variable del
lenguaje principal de destino, se aaden n -
k -1 blancos a la derecha, a partir del
carcter k + 1, y luego se coloca el
terminador nulo en el carcter n. Si se ha
0.
Para la entrada:
Cuando el gestor de bases de datos encuentre una variable
del lenguaje principal de entrada que tenga uno de estos
SQLTYPE y no finalice por un carcter nulo, se devolver
SQLCODE -302 (SQLSTATE 22501).
Si se especifica en cualquier otro contexto de SQL, una variable del lenguaje
principal con SQLTYPE 460 y longitud n se trata como el tipo de datos
VARCHAR con longitud n, tal como se ha definido anteriormente. Si se
especifica en cualquier otro contexto de SQL, una variable del lenguaje
principal con SQLTYPE 468 y longitud n se trata como el tipo de datos
VARGRAPHIC con longitud n, tal como se ha definido anteriormente.
Variables del lenguaje principal utilizadas como tipos de datos de puntero
en C y C++
Las variables del lenguaje principal se pueden declarar como punteros a tipos
de datos especficos, con las restricciones siguientes:
v Si una variable del lenguaje principal se declara como puntero, no se puede
declarar ninguna otra variable del lenguaje principal con el mismo nombre
dentro del mismo archivo fuente. El ejemplo siguiente no est permitido:
char mystring[20];
char (*mystring)[20];
v Cuando declare un puntero a una matriz de caracteres terminada en nulo,
utilice parntesis. En todos los casos restantes, no se permiten parntesis.
Por ejemplo:
char (*arr)[10]; /* correcto */
char *(arr); /* incorrecto */
char *arr[10]; /* incorrecto */
La primera declaracin es un puntero a una matriz de caracteres de 10
bytes. Esta variable del lenguaje principal es vlida. La segunda declaracin
no es vlida. Los parntesis no estn permitidos en un puntero a un
carcter. La tercera declaracin es una matriz de punteros. Este tipo de
datos no se soporta.
La declaracin de variable del lenguaje principal:
char *ptr
se acepta, pero no significa serie de caracteres terminada en nulo de longitud
indeterminada; significa puntero a una variable del lenguaje principal de un solo
carcter y de longitud fija. Es posible que esto no fuera lo que se pretenda.
Para definir una variable del lenguaje principal de puntero que pueda
indicar distintas series de caracteres, utilice el primero de los formatos de
declaracin anteriores.
v Cuando se utilizan variables del lenguaje principal de puntero en sentencias
de SQL, deben tener como prefijo el mismo nmero de asteriscos con que
se han declarado, tal como en el ejemplo siguiente:
char (*mychar)[20]; /* Puntero a matriz de caracteres de 20 bytes */
EXEC SQL SELECT column INTO :*mychar FROM table; /* Correcta */
v Slo se puede utilizar el asterisco como operador en un nombre de variable
del lenguaje principal.
v La longitud mxima de un nombre de variable del lenguaje principal no se
ve afectada por el nmero de asteriscos especificados, puesto que no se
considera que los asteriscos formen parte del nombre.
v Siempre que utilice una variable de puntero en una sentencia de SQL, debe
dejar la opcin de precompilacin del nivel de optimizacin (OPTLEVEL)
en su valor por omisin, que es 0 (sin optimizacin). Esto significa que el
gestor de bases de datos no realizar ninguna optimizacin del SQLDA.
Miembros de datos de clase utilizados como variables del lenguaje
principal en C y C++
Puede declarar miembros de datos de clase como variables del lenguaje
principal (pero no clases u objetos en s mismos). El ejemplo siguiente ilustra
el mtodo a utilizar:
class STAFF
{
private:
char staff_name[20];
short int staff_id;
double staff_salary;
short staff_in_db;
.
.
};
A los miembros de datos slo se puede acceder directamente en sentencias de
SQL mediante el puntero this implcito proporcionado por el compilador C++
en las funciones de miembros de clases. No se puede calificar explcitamente
una instancia de un objeto (como, por ejemplo, SELECT name INTO
:my_obj.staff_name ...) en una sentencia de SQL.
Si se hace una referencia directa a miembros de datos de clase en sentencias
de SQL, el gestor de bases de datos resuelve la referencia utilizando el
puntero this. Por este motivo, debe dejar la opcin de precompilacin del
nivel de optimizacin (OPTLEVEL) en su valor por omisin, que es 0 (sin
optimizacin). Esto significa que el gestor de bases de datos no realizar
ninguna optimizacin del SQLDA. (Esto es as siempre que existan variables
del lenguaje principal de puntero implicadas en las sentencias de SQL.)
El ejemplo siguiente muestra cmo se pueden utilizar directamente los
miembros de datos de clase que ha declarado como variables del lenguaje
principal en una sentencia de SQL.
class STAFF
{
.
.
.
public:
.
.
.
short int hire( void )
{
EXEC SQL INSERT INTO staff ( name,id,salary )
VALUES ( :staff_name, :staff_id, :staff_salary );
staff_in_db = (sqlca.sqlcode == 0);
return sqlca.sqlcode;
}
};
En este ejemplo, los miembros de datos de clase staff_name, staff_id y
staff_salary se utilizan directamente en la sentencia INSERT. Puesto que se
han declarado como variables del lenguaje principal (consulte el primer
ejemplo de esta seccin), estn calificados de forma implcita para el objeto
actual con el puntero this. En sentencias de SQL tambin se puede hacer
referencia a miembros de datos a los que no se pueda acceder mediante el
puntero this. Esto se logra haciendo una referencia indirecta a ellos mediante
variables del lenguaje principal de puntero o de referencia.
El ejemplo siguiente muestra un nuevo mtodo, asWellPaidAs, que toma un
segundo objeto, otherGuy. Este mtodo hace referencia a sus miembros
indirectamente, mediante una variable del lenguaje principal de puntero local
o de referencia, puesto que no se puede hacer una referencia directa a sus
miembros dentro de la sentencia de SQL.
short int STAFF::asWellPaidAs( STAFF otherGuy )
{
short &otherID = otherGuy.staff_id
double otherSalary;
EXEC SQL SELECT SALARY INTO :otherSalary
FROM STAFF WHERE id = :otherID;
if( sqlca.sqlcode == 0 )
return staff_salary >= otherSalary;
else
return 0;
}
Operadores de calificacin y de miembro en C y C++
No se puede utilizar el operador de resolucin de mbito de C++ '::' ni los
operadores de miembros de C/C++ '.' ni '->' en sentencias de SQL
incorporado. Se puede lograr fcilmente lo mismo mediante el uso de
variables de puntero o de referencia locales, que se establecen fuera de la
sentencia de SQL, de forma que apunten a la variable de mbito que se desee
y luego se utilizan dentro de la sentencia de SQL para hacer referencia a sta.
El ejemplo siguiente muestra el mtodo correcto a utilizar:
char (& localName)[20] = ::name;
EXEC SQL
SELECT name INTO :localName FROM STAFF
WHERE name = Sanders;
Codificacin de caracteres de varios bytes en C y C++
Algunos esquemas de codificacin de caracteres, especialmente aqullos que
proceden de los pases del este asitico, necesitan varios bytes para
representar un carcter. Esta representacin externa de los datos se denomina
representacin de un carcter por medio de cdigo de caracteres de varios bytes e
incluye los caracteres de doble byte (caracteres representados por dos bytes).
Los datos grficos en DB2 consisten en caracteres de doble byte.
Para manipular series de caracteres que contienen caracteres de doble byte
puede resultar conveniente que una aplicacin utilice una representacin
interna de los datos. Esta representacin interna se denomina representacin
de caracteres de doble byte por medio de cdigo de caracteres amplios y es el
formato utilizado habitualmente en el tipo de datos wchar_t de C/C++. Se
dispone de subrutinas que se ajustan a C de ANSI y a X/OPEN Portability
Guide 4 (XPG4) para procesar los datos de caracteres amplios y para convertir
los datos que se encuentran en este formato al formato de varios bytes, y
viceversa.
Observe que, aunque una aplicacin puede procesar datos de tipo carcter en
formato de varios bytes o en formato de caracteres amplios, la interaccin con
el gestor de bases de datos slo se realiza con cdigos de caracteres DBCS (de
varios bytes). Es decir, los datos se almacenan y se recuperan de las columnas
GRAPHIC en formato DBCS. Se proporciona la opcin WCHARTYPE del
precompilador para permitir que los datos de una aplicacin que estn en
formato de caracteres amplios se conviertan al formato de varios bytes, y
viceversa, cuando se produce el intercambio de datos con el motor de la base
de datos.
Tipos de datos wchar_t y sqldbchar en C y C++
Mientras que el tamao y la codificacin de datos grficos de DB2 son
constantes en todas las plataformas para una pgina de cdigos determinada,
el tamao y el formato interno del tipo de datos wchar_t de C o de C++ de
ANSI dependen del compilador que se utilice y de la plataforma en que se
encuentre. No obstante, DB2 define el tipo de datos sqldbchar con un tamao
de dos bytes, y se pretende que constituya una manera porttil de manipular
los datos DBCS y UCS-2 en el mismo formato en que estn almacenados en la
base de datos.
Puede definir todos los tipos de variables del lenguaje principal de grficos C
de DB2 mediante wchar_t o sqldbchar. Debe utilizar wchar_t si crea la
aplicacin mediante la opcin de precompilacin WCHARTYPE CONVERT.
Nota: cuando especifique la opcin WCHARTYPE CONVERT en una
plataforma Windows, tenga en cuenta que wchar_t en plataformas
Windows es Unicode. Por lo tanto, si el wchar_t del compilador C/C++
no es Unicode, es posible que la llamada a la funcin wcstombs() falle
con SQLCODE -1421 (SQLSTATE=22504). Si esto sucede, puede
especificar la opcin WCHARTYPE NOCONVERT y llamar a las
funciones wcstombs() y mbstowcs() de forma explcita desde dentro del
programa.
Si crea la aplicacin con la opcin de precompilacin WCHARTYPE
NOCONVERT, debe utilizar sqldbchar para conseguir una portabilidad
mxima entre distintas plataformas de cliente y servidor DB2. Puede utilizar
wchar_t con WCHARTYPE NOCONVERT, pero slo en aquellas plataformas
en que wchar_t est definido con una longitud de dos bytes.
Si utiliza incorrectamente wchar_t o sqldbchar en declaraciones de variables
del lenguaje principal, durante la precompilacin recibir un SQLCODE 15
(sin SQLSTATE).
v Consideraciones sobre los juegos de cdigos EUC y UCS-2 de japons y
chino tradicional en la pgina 444
Opcin del precompilador WCHARTYPE en C y C++
Mediante la opcin WCHARTYPE del precompilador, puede especificar el
formato de caracteres grficos que desea utilizar en la aplicacin C/C++. Esta
opcin proporciona flexibilidad para elegir entre tener los datos grficos en
formato de varios bytes o en formato de caracteres amplios. La opcin
WCHARTYPE tiene dos valores posibles:
CONVERT
Si se selecciona la opcin WCHARTYPE CONVERT, se convierten los
cdigos de caracteres entre la variable de grficos del lenguaje
principal y el gestor de bases de datos. Para las variables del lenguaje
principal de entrada de grficos, la conversin de cdigo de caracteres
del formato de caracteres amplios a formato de caracteres DBCS de
varios bytes se realiza antes de enviar los datos al gestor de bases de
datos, mediante la funcin wcstombs() de C de ANSI. Para las
variables del lenguaje principal de salida de grficos, la conversin de
cdigo de caracteres del formato de caracteres DBCS de varios bytes
al formato de caracteres amplios se realiza antes de que los datos
recibidos del gestor de bases de datos se almacenen en la variable del
lenguaje principal, mediante la funcin mbstowcs() de C de ANSI.
La ventaja de utilizar WCHARTYPE CONVERT es que permite que la
aplicacin aproveche plenamente los mecanismos de C de ANSI para
tratar las series de caracteres amplios (literales L, funciones de serie
wc, etc.) sin tener que convertir los datos de forma explcita al
formato de varios bytes antes de establecer comunicacin con el gestor
de bases de datos. El inconveniente es que las conversiones implcitas
puede tener un impacto sobre el rendimiento de la aplicacin durante
la ejecucin de sta y pueden incrementar los requisitos de memoria.
Si selecciona WCHARTYPE CONVERT, declare todas las variables del
lenguaje principal de grficos mediante wchar_t en lugar de mediante
sqldbchar.
Si desea el comportamiento de WCHARTYPE CONVERT pero no es
necesario precompilar la aplicacin (por ejemplo, una aplicacin CLI),
defina la macro SQL_WCHART_CONVERT del preprocesador de C durante
la compilacin. As se asegurar de que determinadas definiciones de
los archivos de cabecera de DB2 utilicen el tipo de datos wchar_t en
lugar de sqldbchar.
Nota: la opcin de precompilacin WCHARTYPE CONVERT no
recibe soporte actualmente en programas que se ejecutan en el
cliente DB2 Windows 3.1. Para estos programas, utilice el valor
por omisin (WCHARTYPE NOCONVERT).
NOCONVERT (valor por omisin)
Si se elige la opcin WCHARTYPE NOCONVERT o no se especifica
ninguna opcin WCHARTYPE, no se produce ninguna conversin
implcita del cdigo de caracteres entre la aplicacin y el gestor de
bases de datos. Los datos de una variable del lenguaje principal de
grficos se envan al gestor de bases de datos y se reciben del mismo
como caracteres DBCS inalterados. Esto tiene la ventaja de que se
mejora el rendimiento, pero el inconveniente de que la aplicacin debe
abstenerse de utilizar datos de caracteres amplios en las variables del
lenguaje principal wchar_t, o tiene que llamar explcitamente a las
funciones wcstombs() y mbstowcs() para convertir los datos al formato
de varios bytes, o viceversa, cuando interacte con el gestor de bases
de datos.
Si selecciona WCHARTYPE NOCONVERT, declare todas las variables
del lenguaje principal de grficos utilizando el tipo sqldbchar, a fin de
obtener la mxima portabilidad a otras plataformas cliente/servidor
de DB2.
Hay otras directrices que debe tener en cuenta, que son las siguientes:
v Puesto que se utiliza el soporte de wchar_t o sqldbchar para manejar datos
DBCS, su uso requiere que el hardware y el software tengan capacidad de
DBCS o EUC. Este soporte slo est disponible en el entorno DBCS de DB2
Universal Database, o para tratar datos GRAPHIC en cualquier aplicacin
(incluidas las aplicaciones de un solo byte) conectada a una base de datos
UCS-2.
v Los caracteres que no sean DBCS, y los caracteres amplios que se pueden
convertir en caracteres no DBCS, no se deben utilizar en series grficas.
Caracteres que no sean DBCS hace referencia a los caracteres de un solo byte
y a los caracteres que no son de doble byte. Las series grficas no se
validan para asegurar que sus valores nicamente contienen puntos de
cdigo de caracteres de doble byte. Las variables del lenguaje principal de
grficos slo deben contener datos DBCS o, si WCHARTYPE CONVERT
est en vigor, datos de caracteres amplios que se convierten en datos DBCS.
Debe almacenar los datos que contienen una mezcla de caracteres de doble
byte y de un solo byte en variables del lenguaje principal de tipo carcter.
Observe que las variables del lenguaje principal de datos mixtos no se ven
afectadas por el establecimiento de la opcin WCHARTYPE.
v En las aplicaciones en que se utiliza la opcin de precompilacin
WCHARTYPE NOCONVERT, no se deben utilizar literales L junto con
variables del lenguaje principal de grficos, puesto que los literales L estn
en formato de caracteres amplios. Un literal L es una serie de caracteres
amplios C que tiene como prefijo la letra L y como tipo de datos "array of
wchar_t". Por ejemplo, L"dbcs-string" es un literal L.
v En las aplicaciones en que se utiliza la opcin de precompilacin
WCHARTYPE CONVERT, se pueden utilizar literales L para inicializar
variables del lenguaje principal wchar_t, pero no se pueden utilizar en
sentencias de SQL. En lugar de utilizar literales L, las sentencias de SQL
deben usar constantes de serie de grficos, que son independientes del
valor de WCHARTYPE.
v El valor de la opcin WCHARTYPE afecta a los datos de grficos que se
pasan al gestor de bases de datos y que se reciben de ste utilizando la
estructura SQLDA, as como a las variables del lenguaje principal. Si
WCHARTYPE CONVERT est en vigor, se supondr que los datos grficos
recibidos de la aplicacin mediante una SQLDA estn en formato de
caracteres amplios, y se convertirn al formato DBCS a travs de una
llamada implcita a wcstombs(). De forma parecida, los datos de salida de
grficos recibidos por una aplicacin se habrn convertido al formato de
caracteres amplios antes de colocarlos en el almacenamiento de la
aplicacin.
v Los procedimientos almacenados sin barrera se deben precompilar con la
opcin WCHARTYPE NOCONVERT. Los procedimientos almacenados
normales con barrera se pueden precompilar con las opciones CONVERT o
NOCONVERT, lo cual afectar al formato de los datos grficos
manipulados por las sentencias de SQL contenidas en el procedimiento
almacenado. No obstante, y en cualquier caso, los datos grficos que se
pasen al procedimiento almacenado mediante el SQLDA estarn en formato
DBCS. De la misma forma, los datos que se pasen desde el procedimiento
almacenado mediante el SQLDA deben estar en formato DBCS.
v Si una aplicacin llama a un procedimiento almacenado a travs de la
interfaz Database Application Remote Interface (DARI) (la API sqleproc()),
los datos grficos del SQLDA de entrada tienen que estar en formato DBCS,
o en UCS-2 si est conectada a una base de datos UCS-2,
independientemente del estado del valor de WCHARTYPE de la aplicacin
que realiza la llamada. Asimismo, los datos grficos del SQLDA de salida se
devolvern en formato DBCS, o en UCS-2 si est conectada a una base de
datos UCS-2, independientemente del valor de WCHARTYPE.
v Si una aplicacin llama a un procedimiento almacenado mediante la
sentencia CALL de SQL, se producir una conversin de los datos grficos
en el SQLDA, segn el valor de WCHARTYPE de la aplicacin que realiza
la llamada.
v Los datos grficos que se pasen a funciones definidas por el usuario (UDF)
siempre estarn en formato DBCS. De la misma forma, se supondr que los
datos grficos devueltos desde una UDF estn en formato DBCS para las
bases de datos DBCS, y en formato UCS-2 para las bases de datos EUC y
UCS-2.
v Los datos almacenados en archivos DBCLOB mediante el uso de variables
de referencia a archivos DBCLOB se almacenan en formato DBCS o, en el
caso de bases de datos UCS-2, en formato UCS-2. Del mismo modo, los
datos de entrada procedentes de archivos DBCLOB se recuperan en formato
DBCS o, en el caso de bases de datos UCS-2, en formato UCS-2.
Nota: si se precompilan aplicaciones C utilizando la opcin WCHARTYPE
CONVERT, DB2 valida los datos grficos de la aplicacin tanto de
entrada como de salida, puesto que los datos se pasan a travs de las
funciones de conversin. Si no se utiliza la opcin CONVERT, no se
produce ninguna conversin de los datos grficos, por lo que tampoco
se produce ninguna validacin. En un entorno mixto de
CONVERT/NOCONVERT, se pueden ocasionar problemas si una
aplicacin NOCONVERT inserta datos grficos no vlidos que luego
son captados por una aplicacin CONVERT. Estos datos no se pueden
convertir con SQLCODE -1421 (SQLSTATE 22504) en una operacin
FETCH de la aplicacin CONVERT.
Consideraciones sobre EUC en japons o chino tradicional y UCS-2 en C
y C++
Si la pgina de cdigos de la aplicacin es EUC en japons o chino
tradicional, o si la aplicacin conecta con una base de datos UCS-2, puede
acceder a columnas GRAPHIC del servidor de base de datos utilizando las
opciones CONVERT o NOCONVERT y las variables del lenguaje principal de
grficos wchar_t o sqldbchar, o las SQLDA de entrada/salida. En este
apartado, formato DBCS hace referencia al esquema de codificacin de UCS-2
para datos EUC. Considere los casos siguientes:
v Se utiliza la opcin CONVERT
El cliente DB2 convierte los datos grficos del formato de caracteres amplios
a la pgina de cdigos de la aplicacin, y luego a UCS-2, antes de enviar el
SQLDA de entrada al servidor de base de datos. Los datos grficos se
envan al servidor de base de datos identificados por el identificador de
pgina de cdigos de UCS-2. Los datos de tipo carcter mixtos se
identifican con el identificador de pgina de cdigos de la aplicacin.
Cuando un cliente recupera datos grficos de una base de datos, stos se
identifican con el identificador de pgina de cdigos de UCS-2. El cliente
DB2 convierte los datos de UCS-2 a la pgina de cdigos de la aplicacin
cliente y luego al formato de caracteres amplios. Si se utiliza una SQLDA
de entrada en lugar de una variable del lenguaje principal, se requiere al
usuario que se asegure de que los datos grficos se han codificado
utilizando el formato de caracteres amplios. Estos datos se convertirn a
UCS-2 y luego se enviarn al servidor de base de datos. Estas conversiones
tendrn impacto en el rendimiento.
v Se utiliza la opcin NOCONVERT
DB2 supone que los datos se han codificado utilizando UCS-2 y estn
identificados por la pgina de cdigos de UCS-2, y no se produce ninguna
conversin. DB2 supone que la variable del lenguaje principal de grficos se
utiliza simplemente como contenedor. Si no se selecciona la opcin
NOCONVERT, los datos grficos recuperados del servidor de base de datos
se pasan a la aplicacin codificados mediante UCS-2. Las posibles
conversiones de la pgina de cdigos de la aplicacin a UCS-2 y de UCS-2
a la pgina de cdigos de la aplicacin son responsabilidad del usuario. Los
datos identificados como UCS-2 se envan al servidor de base de datos sin
que se produzca ninguna conversin ni alteracin.
Para minimizar las conversiones, puede utilizar la opcin NOCONVERT y
manejar las conversiones en la aplicacin, o bien no utilizar columnas
GRAPHIC. Para los entornos de cliente en que la codificacin wchar_t es en
Unicode de dos bytes, por ejemplo en Windows NT o AIX versin 4.3 y
posteriores, puede utilizar la opcin NOCONVERT y trabajar directamente
con UCS-2. En estos casos, la aplicacin debe manejar la diferencia entre las
arquitecturas big-endian y little-endian. Con la opcin NOCONVERT, DB2
Universal Database utiliza sqldbchar, que es siempre un big-endian de dos
bytes.
No asigne datos IBM-eucJP/IBM-eucTW CS0 (ASCII de 7 bits) e IBM-eucJP
CS2 (Katakana) a variables del lenguaje principal de grficos despus de una
conversin a UCS-2 (si se especifica NOCONVERT) ni mediante una
conversin al formato de caracteres amplios (si se especifica CONVERT). Esto
es as porque los caracteres en estos juegos de cdigos EUC pasan a tener un
solo byte cuando se convierten de UCS-2 a DBCS de PC.
En general, aunque eucJP y eucTW almacenan los datos grficos (GRAPHIC)
como UCS-2, los datos GRAPHIC contenidos en estas bases de datos siguen
siendo datos eucJP o eucTW no ASCII. Concretamente, cualquier espacio
rellenado en estos datos GRAPHIC es espacio DBCS (tambin conocido como
espacio ideogrfico en UCS-2, U+3000). Sin embargo, para una base de datos
UCS-2, los datos GRAPHIC pueden contener cualquier carcter UCS-2 y el
relleno del espacio se realiza con espacio UCS-2, U+0020. Tenga presente esta
diferencia cuando codifique aplicaciones para recuperar datos UCS-2 de una
base de datos UCS-2, en comparacin con la recuperacin de datos UCS-2 de
bases de datos eucJP y eucTW.
Seccin declare de SQL con variables del lenguaje principal para C y C++
A continuacin se muestra una seccin de declaracin de SQL de ejemplo con
variables del lenguaje principal declaradas para tipos de datos SQL
soportados:
.
.
.
short age = 26; /* tipo de SQL 500 */
short year; /* tipo de SQL 500 */
sqlint32 salary; /* tipo de SQL 496 */
sqlint32 deptno; /* tipo de SQL 496 */
float bonus; /* tipo de SQL 480 */
double wage; /* tipo de SQL 480 */
char mi; /* tipo de SQL 452 */
char name[6]; /* tipo de SQL 460 */
struct {
short len;
char data[24];
} address; /* tipo de SQL 448 */
struct {
short len;
char data[32695];
} voice; /* tipo de SQL 456 */
sql type is clob(1m)
chapter; /* tipo de SQL 408 */
sql type is clob_locator
chapter_locator; /* tipo de SQL 964 */
sql type is clob_file
chapter_file_ref; /* tipo de SQL 920 */
sql type is blob(1m)
video; /* tipo de SQL 404 */
sql type is blob_locator
video_locator; /* tipo de SQL 960 */
sql type is blob_file
video_file_ref; /* tipo de SQL 916 */
sql type is dbclob(1m)
tokyo_phone_dir; /* tipo de SQL 412 */
sql type is dbclob_locator
tokyo_phone_dir_lctr; /* tipo de SQL 968 */
sql type is dbclob_file
tokyo_phone_dir_flref; /* tipo de SQL 924 */
struct {
short len;
} vargraphic1; /* tipo de SQL 464 */
/* Precompilado con la
opcin WCHARTYPE NOCONVERT */
struct {
short len;
wchar_t data[100];
} vargraphic2; /* tipo de SQL 464 */
opcin WCHARTYPE CONVERT */
struct {
short len;
} long_vargraphic1; /* tipo de SQL 472 */
struct {
short len;
wchar_t data[10000];
} long_vargraphic2; /* tipo de SQL 472 */
sqldbchar graphic1[100]; /* tipo de SQL 468 */
wchar_t graphic2[100]; /* tipo de SQL 468 */
char date[11]; /* tipo de SQL 384 */
char time[9]; /* tipo de SQL 388 */
char timestamp[27]; /* tipo de SQL 392 */
short wage_ind; /* Indicador de nulo */
.
.
.
Consideraciones sobre tipos de datos para C y C++
Las secciones siguientes describen cmo se correlacionan los tipos de datos de
SQL con tipos de datos de C y C++.
Tipos de datos SQL soportados en C y C++
Ciertos tipos de datos predefinidos de C y C++ corresponden con los tipos de
columna del gestor de bases de datos. Slo se pueden declarar como variables
del lenguaje principal estos tipos de datos de C/C++.
La tabla siguiente muestra el equivalente en C/C++ de cada tipo de columna.
Cuando el precompilador encuentra una declaracin de una variable del
lenguaje principal, determina el valor del tipo de SQL apropiado. El gestor de
bases de datos utiliza este valor para convertir los datos intercambiados entre
la aplicacin y l mismo.
Nota: no existe soporte de variables del lenguaje principal para el tipo de
datos DATALINK en ninguno de los lenguajes principales de DB2.
Tabla 13. Tipos de datos SQL correlacionados con declaraciones C/C++
Tipo de columna SQL
1
Tipo de datos C/C++ Descripcin del tipo de columna SQL
SMALLINT
(500 501)
short
short int
sqlint16
Entero con signo de 16 bits
INTEGER
(496 497)
long
long int
sqlint32
2
BIGINT
(492 493)
long long
long
__int64
sqlint64
3
REAL
4
(480 481)
float Coma flotante de precisin simple
DOUBLE
5
(480 481)
double Coma flotante de precisin doble
Tabla 13. Tipos de datos SQL correlacionados con declaraciones C/C++ (continuacin)
Tipo de columna SQL
1
DECIMAL(p,s)
(484 485)
No existe un equivalente exacto;
utilice double
Decimal empaquetado
(Considere la posibilidad de utilizar las
funciones CHAR y DECIMAL para
manipular los campos decimales
empaquetados como datos de tipo carcter.)
CHAR(1)(452 453) char Carcter simple
CHAR(n)
(452 453)
utilice char[n+1], donde n es
suficientemente grande para
contener los datos
1<=n<=254
Serie de caracteres de longitud fija
VARCHAR(n)
(448 449)
struct tag {
short int;
char[n]
}
1<=n<=32 672
Serie de caracteres de longitud variable no
terminada en nulo con indicador de longitud
de serie de 2 bytes
Como alternativa, utilice
char[n+1], donde n es
contener los datos
1<=n<=32 672
Serie de caracteres de longitud variable
terminada en nulo
Nota: se le asigna un tipo SQL de 460/461.
LONG VARCHAR
(456 457)
struct tag {
short int;
char[n]
}
32 673<=n<=32 700
de serie de 2 bytes
CLOB(n)
(408 409)
sql type is
clob(n)
1<=n<=2 147 483 647
de serie de 4 bytes
Variable de localizador CLOB
6
(964 965)
sql type is
clob_locator
Identifica las entidades CLOB que residen en
el servidor
Variable de referencia de archivo
CLOB
6 en la pgina 221
(920 921)
sql type is
clob_file
Descriptor del archivo que contiene datos
CLOB
BLOB(n)
(404 405)
sql type is
blob(n)
1<=n<=2 147 483 647
Serie binaria variable no terminada en nulo
con indicador de longitud de serie de 4 bytes
Variable de localizador BLOB
6
(960 961)
sql type is
blob_locator
Identifica las entidades BLOB del servidor
BLOB
6
(916 917)
sql type is
blob_file
BLOB
Tipo de columna SQL
1
DATE (384 385) Formato de caracteres terminado
en nulo
Admitir como mnimo 11 caracteres para
acomodar el terminador nulo.
Formato estructurado VARCHAR Admitir como mnimo 10 caracteres.
TIME
(388 389)
Formato de caracteres terminado
en nulo
TIMESTAMP
(392 393)
Formato de caracteres terminado
en nulo
Nota: los tipos de datos siguientes slo estn disponibles en los entornos DBCS o EUC si se compilan previamente
con la opcin WCHARTYPE NOCONVERT.
GRAPHIC(1)
(468 469)
sqldbchar Carcter simple de doble byte
GRAPHIC(n)
(468 469)
utilice sqldbchar[n+1], donde n es
contener los datos
1<=n<=127
Serie de caracteres de doble byte y longitud
fija
VARGRAPHIC(n)
(464 465)
struct tag {
short int;
sqldbchar[n]
}
1<=n<=16 336
variable no terminada en nulo con indicador
de longitud de serie de 2 bytes
sqldbchar[n+1], donde n es
contener los datos
1<=n<=16 336
variable terminada en nulo
LONG VARGRAPHIC
(472 473)
struct tag {
short int;
sqldbchar[n]
}
16 337<=n<=16 350
con la opcin WCHARTYPE CONVERT.
GRAPHIC(1)
(468 469)
wchar_t v Carcter amplio simple (para tipo C)
v Carcter de doble byte simple (para tipo de
columna)
GRAPHIC(n)
(468 469)
utilice wchar_t [n+1], donde n es
contener los datos
1<=n<=127
fija
Tipo de columna SQL
1
VARGRAPHIC(n)
(464 465)
struct tag {
short int;
wchar_t [n]
}
1<=n<=16 336
char[n+1], donde n es
contener los datos
1<=n<=16 336
variable terminada en nulo
LONG VARGRAPHIC
(472 473)
struct tag {
short int;
wchar_t [n]
}
16 337<=n<=16 350
Nota: los tipos de datos siguientes slo estn disponibles en los entornos DBCS o EUC.
DBCLOB(n)
(412 413)
sql type is
dbclob(n)
1<=n<=1 073 741 823
Variable de localizador DBCLOB
6
(968 969)
sql type is
dbclob_locator
Identifica las entidades DBCLOB que residen
en el servidor
Variable de referencia de archivos
DBCLOB
6
(924 925)
sql type is
dbclob_file
DBCLOB
Notas:
1. El primer nmero que se encuentra bajo Tipo de columna SQL indica que no se proporciona una variable de
indicador, y el segundo nmero indica que se proporciona una variable de indicador. Se necesita una variable de
indicador para indicar los valores nulos (NULL) o para contener la longitud de una serie truncada. stos son los
valores que aparecern en el campo SQLTYPE del SQLDA para estos tipos de datos.
2. Por razones de compatibilidad entre plataformas, utilice sqlint32. En las plataformas UNIX de 64 bits, long es un
entero de 64 bits. En los sistemas operativos Windows de 64 bits y en las plataformas UNIX de 32 bits, long es
un entero de 32 bits.
3. Por razones de compatibilidad entre plataformas, utilice sqlint64. El archivo de cabecera sqlsystm.h de DB2
Universal Database definir el tipo sqlint64 como __int64 en la plataforma Windows NT cuando se utilice el
compilador de Microsoft, como long long en las plataformas UNIX de 32 bits y como long en las plataformas
UNIX de 64 bits.
4. FLOAT(n) donde 0 < n < 25 es un sinnimo de REAL. La diferencia entre REAL y DOUBLE en el SQLDA es el
valor de la longitud (4 8).
5. Los tipos SQL siguientes son sinnimos de DOUBLE:
v FLOAT
v FLOAT(n) donde 24 < n < 54 es
v DOUBLE PRECISION
6. ste no es un tipo de columna, sino un tipo de variable del lenguaje principal.
A continuacin mostramos normas adicionales para los tipos de datos C/C++
soportados:
v El tipo de datos char se puede declarar como char o unsigned char.
v El gestor de bases de datos procesa los datos de serie de caracteres de
longitud variable y terminados en nulo del tipo char[n] (tipo de datos 460)
como VARCHAR(m).
Si LANGLEVEL es SAA1, la longitud de la variable del lenguaje
principal m es igual a la longitud de la serie de caracteres n en char[n] o
al nmero de bytes que preceden al primer terminador nulo (\0), el
valor ms pequeo de ambos.
Si LANGLEVEL es MIA, la longitud de la variable del lenguaje principal
m es igual al nmero de bytes que preceden al primer terminador nulo
(\0).
v El gestor de bases de datos procesa el tipo de datos de serie de caracteres
de grficos y longitud variable terminados en nulo, wchar_t[n] o
sqldbchar[n] (tipo de datos 400), como VARGRAPHIC(m).
Si LANGLEVEL es SAA1, la longitud de la variable del lenguaje
principal m es igual a la longitud de la serie de caracteres n en
wchar_t[n] o sqldbchar[n], o al nmero de caracteres que preceden al
primer terminador nulo de grficos, el valor ms pequeo de ambos.
Si LANGLEVEL es MIA, la longitud de la variable del lenguaje principal
m es igual al nmero de caracteres que preceden al primer terminador
nulo de grficos.
v No se soportan los tipos de datos numricos sin signo.
v El tipo de datos int de C/C++ no est permitido, puesto que su
representacin interna depende de la mquina.
en la pgina 216
FOR BIT DATA en C y C++
No se debe utilizar el tipo de serie estndar de C o C++, 460, para las
columnas designadas como FOR BIT DATA. El gestor de bases de datos
trunca este tipo de datos cuando se encuentra un carcter nulo. Utilice las
estructuras VARCHAR (tipo de SQL 448) o CLOB (tipo de SQL 408).
en la pgina 216
Tipos de datos de C y C++ para procedimientos, funciones y mtodos
La tabla siguiente lista las correlaciones soportadas entre tipos de datos SQL y
tipos de datos C para procedimientos, UDF y mtodos.
Tabla 14. Tipos de datos SQL correlacionados con declaraciones C/C++
Tipo de columna SQL Tipo de datos C/C++ Descripcin del tipo de columna SQL
SMALLINT (500 501) short Entero con signo de 16 bits
INTEGER
(496 497)
sqlint32 Entero con signo de 32 bits
BIGINT
(492 493)
sqlint64 Entero con signo de 64 bits
REAL
(480 481)
DOUBLE
(480 481)
DECIMAL(p,s)
(484 485)
No soportado. Para pasar un valor decimal, defina el
parmetro como de tipo de datos moldeable
DECIMAL (por ejemplo, CHAR o DOUBLE)
y moldee explcitamente el argumento para
este tipo.
CHAR(n)
(452 453)
char[n+1] donde n es
contener los datos
1<=n<=254
Serie de caracteres de longitud fija terminada
en nulo
CHAR(n) FOR BIT DATA
(452 453)
contener los datos
1<=n<=254
VARCHAR(n)
(448 449) (460 461)
contener los datos
1<=n<=32 672
Serie de longitud variable terminada en nulo
VARCHAR(n) FOR BIT DATA
(448 449)
struct {
sqluint16 length;
char[n]
}
1<=n<=32 672
terminada en nulo
LONG VARCHAR
(456 457)
struct {
sqluint16 length;
char[n]
}
32 673<=n<=32 700
terminada en nulo
Tipo de columna SQL Tipo de datos C/C++ Descripcin del tipo de columna SQL
CLOB(n)
(408 409)
struct {
sqluint32 length;
char data[n];
}
1<=n<=2 147 483 647
de serie de 4 bytes
BLOB(n)
(404 405)
struct {
sqluint32 length;
char data[n];
}
1<=n<=2 147 483 647
Serie binaria de longitud variable no
de serie de 4 bytes
DATE (384 385) char[11] Formato de caracteres terminado en nulo
TIME (388 389) char[9] Formato de caracteres terminado en nulo
TIMESTAMP (392 393) char[27] Formato de caracteres terminado en nulo
con la opcin WCHARTYPE NOCONVERT.
GRAPHIC(n)
(468 469)
sqldbchar[n+1] donde n es
contener los datos
1<=n<=127
fija terminada en nulo
VARGRAPHIC(n)
(400 401)
sqldbchar[n+1] donde n es
contener los datos
1<=n<=16 336
variable no terminada en nulo
LONG VARGRAPHIC
(472 473)
struct {
sqluint16 length;
sqldbchar[n]
}
16 337<=n<=16 350
variable no terminada en nulo
DBCLOB(n)
(412 413)
struct {
sqluint32 length;
sqldbchar data[n];
}
1<=n<=1 073 741 823
de serie de 4 bytes
Variables SQLSTATE y SQLCODE en C y C++
Cuando se utiliza la opcin de precompilacin LANGLEVEL con un valor de
SQL92E, se pueden incluir las dos declaraciones siguientes como variables del
lenguaje principal:
char SQLSTATE[6]
sqlint32 SQLCODE;
.
.
.
Si no se especifica ninguna de ellas, se supone la declaracin SQLCODE
durante el paso de precompilacin. Observe que, si se utiliza esta opcin, no
se debe especificar la sentencia INCLUDE SQLCA.
En una aplicacin formada por varios archivos fuente, las variables SQLCODE
y SQLSTATE se pueden definir en el primer archivo fuente, tal como en el
ejemplo anterior. Los archivos fuente posteriores deben modificar las
definiciones del modo siguiente:
extern sqlint32 SQLCODE;
extern char SQLSTATE[6];
Captulo 7. Acceso a bases de datos de varias hebras en
aplicaciones C y C++
Objetivo del acceso a base de datos de varias
hebras . . . . . . . . . . . . . 227
Recomendaciones para utilizar varias hebras 229
Consideraciones sobre pgina de cdigos y
cdigo de pas/regin para aplicaciones
UNIX de varias hebras . . . . . . . . 229
Resolucin de problemas de aplicaciones de
varias hebras . . . . . . . . . . . 230
Problemas potenciales con varias hebras 230
Cmo evitar puntos muertos para varios
contextos. . . . . . . . . . . . 231
Objetivo del acceso a base de datos de varias hebras
Una caracterstica de algunos sistemas operativos es la posibilidad de ejecutar
varias hebras de ejecucin en un solo proceso. Las diversas hebras permiten
que una aplicacin maneje sucesos asncronos y facilitan la creacin de
aplicaciones dirigidas por sucesos sin recurrir a esquemas de tramas. La
siguiente informacin explica cmo trabaja el gestor de bases de datos con
varias hebras y se relacionan algunas directrices de diseo que conviene
recordar.
Si no est familiarizado con los trminos relacionados con el desarrollo de
aplicaciones de varias hebras (como seccin crtica y semforo), consulte la
documentacin sobre programacin correspondiente al sistema operativo.
Una aplicacin DB2 puede ejecutar sentencias de SQL para varias hebras
utilizando contextos. Un contexto es el entorno desde el que una aplicacin
ejecuta todas las sentencias de SQL y las llamadas a las API. Todas las
conexiones, unidades de trabajo y otros recursos de base de datos estn
asociados a un contexto especfico. Cada contexto est asociado a una o ms
hebras de una aplicacin.
Para cada sentencia de SQL ejecutable en un contexto, la primera llamada a
los servicios de tiempo de ejecucin siempre intenta obtener un enganche. Si
esta operacin resulta satisfactoria, prosigue el proceso. Si no lo es (porque
una sentencia de SQL de otra hebra del mismo contexto ya tiene el enganche),
se bloquea la llamada en un semforo de sealizacin hasta que entra en
funciones dicho semforo, en cuyo momento la llamada obtiene el enganche y
prosigue el proceso. Se mantiene en enganche hasta que se ha completado el
proceso, momento en que lo libera la ltima llamada a los servicios de tiempo
de ejecucin que se ha generado para esa sentencia de SQL en particular.
El resultado neto es que cada sentencia de SQL de un contexto se ejecuta
como una unidad atmica, aunque puede que haya otras hebras que estn
intentando ejecutar sentencias de SQL al mismo tiempo. Esta accin asegura
que las distintas hebras que puedan actuar a la vez no alteran las estructuras
internas de los datos. Las API tambin utilizan el enganche utilizado por los
servicios de tiempo de ejecucin; por consiguiente, las API tienen las mismas
restricciones que las rutinas de los servicios de tiempo de ejecucin dentro de
cada contexto.
Por omisin, todas las aplicaciones tienen un solo contexto que se utiliza para
todos los accesos a bases de datos. Aunque que esto resulta perfecto para una
aplicacin de una nica hebra, la colocacin en serie de las sentencias de SQL
hace que un solo contexto resulte inadecuado para una aplicacin de varias
hebras. Utilizando las siguientes API de DB2, la aplicacin puede conectar un
contexto separado a cada hebra y permitir que se pasen contextos entre
hebras:
v sqleSetTypeCtx()
v sqleBeginCtx()
v sqleEndCtx()
v sqleAttachToCtx()
v sqleDetachFromCtx()
v sqleGetCurrentCtx()
v sqleInterruptCtx()
En un proceso, se pueden intercambiar contextos entre hebras, pero no se
pueden intercambiar entre procesos. Un uso de varios contextos consiste en
proporcionar soporte de transacciones simultneas.
v Transacciones simultneas en la pgina 469
v sqleAttachToCtx - Attach to Context en el manual Administrative API
Reference
v sqleBeginCtx - Create and Attach to an Application Context en el manual
Administrative API Reference
v sqleDetachFromCtx - Detach From Context en el manual Administrative
API Reference
v sqleEndCtx - Detach and Destroy Application Context en el manual
v sqleGetCurrentCtx - Get Current Context en el manual Administrative API
Reference
v sqleInterruptCtx - Interrupt Context en el manual Administrative API
Reference
v sqleSetTypeCtx - Set Application Context Type en el manual
v dbthrds.sqc -- How to use multiple context APIs on UNIX (C)
v dbthrds.sqC -- How to use multiple context APIs on UNIX (C++)
Recomendaciones para utilizar varias hebras
Cuando acceda a una base de datos desde aplicaciones de varias hebras, siga
estas directrices:
v Coloque en serie la alteracin de estructuras de datos.
Las aplicaciones se deben asegurar de que las estructuras de datos,
definidas por el usuario y utilizadas por las sentencias de SQL y por las
rutinas del gestor de bases de datos, no se vean alteradas por una hebra
mientras se est procesando una sentencia de SQL o una rutina del gestor
de bases de datos en otra hebra. Por ejemplo, no permita que una hebra
reasigne una SQLDA mientras la est utilizando una sentencia de SQL en
otra hebra.
v Considere la posibilidad de utilizar estructuras de datos separadas.
Puede resultar ms fcil asignar a cada hebra sus propias estructuras de
datos definidas por el usuario, a fin de evitar que se coloque en serie su
uso. Esta directriz es especialmente cierta para la SQLCA, la cual utilizan
no slo todas las sentencias de SQL ejecutables, sino tambin todas las
rutinas del gestor de bases de datos. Existen tres alternativas para evitar
este problema con la SQLCA:
Utilice EXEC SQL INCLUDE SQLCA, pero aada struct sqlca sqlca al
comienzo de cualquier rutina que utilice cualquier hebra que no sea la
primera.
Coloque EXEC SQL INCLUDE SQLCA dentro de cada rutina que
contenga SQL, en lugar de hacerlo en el mbito global.
Sustituya EXEC SQL INCLUDE SQLCA por #include "sqlca.h" y luego
aada "struct sqlca sqlca" al comienzo de cualquier rutina que utilice
SQL.
Consideraciones sobre pgina de cdigos y cdigo de pas/regin para
aplicaciones UNIX de varias hebras
En AIX, Solaris Operating Environment, HP-UX y Silicon Graphics IRIX, se
han efectuado cambios en las funciones que se utilizan para ejecutar consultas
en tiempo de ejecucin de la pgina de cdigos y del cdigo de pas/regin, a
fin de utilizarlas para conectar con una base de datos. Ahora estas funciones
estn a salvo de las hebras, pero pueden crear alguna contencin de bloqueos
Captulo 7. Acceso a bases de datos de varias hebras en aplicaciones C y C++ 229
(dando como resultado una degradacin del rendimiento) en una aplicacin
de varias hebras que utilice un gran nmero de conexiones de base de datos
simultneas.
Puede utilizar la variable de entorno DB2_FORCE_NLS_CACHE para eliminar
la posibilidad de contencin de bloqueos en las aplicaciones de varias hebras.
Si DB2_FORCE_NLS_CACHE tiene el valor TRUE, la primera vez que una
hebra accede a la informacin de pgina de cdigos y cdigo de pas/regin,
sta se guarda. A partir de este punto, cualquier otra hebra que solicite esta
informacin utilizar la que se encuentra en la antememoria. Guardando esta
informacin, se suprime la contencin de bloqueos y, en determinadas
situaciones, se obtiene una mejora en el rendimiento.
No debe asignar a DB2_FORCE_NLS_CACHE el valor TRUE si la aplicacin
cambia los valores de entorno nacional entre conexiones. Si se produce esta
situacin, se devolver la informacin del entorno nacional original aunque se
hayan cambiado estos valores. En general, las aplicaciones de varias hebras no
cambiarn los valores de entorno nacional, lo cual asegura que la aplicacin
sigue estando a salvo de hebras.
v DB2 registry and environment variables en el manual Administration
Guide: Performance
Resolucin de problemas de aplicaciones de varias hebras
Las secciones siguientes describen problemas que se pueden producir con una
aplicacin de varias hebras y cmo evitarlos.
Problemas potenciales con varias hebras
Una aplicacin que utiliza varias hebras es, comprensiblemente, ms compleja
que una aplicacin de una sola hebra. Esta complejidad adicional puede
conducir potencialmente a algunos problemas inesperados. Cuando escriba
una aplicacin de varias hebras, tenga precaucin con lo siguiente:
v Dependencias de base de datos entre dos o ms contextos.
Cada contexto de una aplicacin tiene sus propios recursos de base de
datos, incluidos los bloqueos sobre objetos de base de datos. Esta
caracterstica posibilita que dos contextos, si estn accediendo al mismo
objeto de base de datos, lleguen a un punto muerto. El gestor de bases de
datos detectar el punto muerto. Uno de los contextos recibir SQLCODE
-911 y se retrotraer la unidad de trabajo del mismo.
v Dependencias de aplicaciones entre dos o ms contextos.
Tenga cuidado con las tcnicas de programacin que establecen
dependencias entre contextos. Los enganches, los semforos y las secciones
crticas son ejemplos de tcnicas de programacin que pueden establecer
dichas dependencias. Si una aplicacin tiene dos contextos que tienen
dependencias, tanto de aplicacin como de base de datos, entre los
contextos, es posible que la aplicacin llegue a un punto muerto. Si algunas
de las dependencias estn fuera del gestor de bases de datos, no se detecta
el punto muerto, por lo que la aplicacin se suspende o se cuelga.
v Cmo evitar puntos muertos para varios contextos en la pgina 231
Cmo evitar puntos muertos para varios contextos
Puesto que el gestor de bases de datos no detecta puntos muertos entre
hebras, disee y codifique la aplicacin de modo que impida (o al menos
evite) puntos muertos.
Como ejemplo de un punto muerto que el gestor de bases de datos no
detectara piense en una aplicacin que tiene dos contextos y ambos acceden a
una estructura de datos comn. Para evitar problemas en que ambos
contextos cambien simultneamente la estructura de datos, la estructura de
datos se protege mediante un semforo. Los contextos tienen el aspecto
siguiente:
contexto 1
SELECT * FROM TAB1 FOR UPDATE....
UPDATE TAB1 SET....
get semaphore
access data structure
release semaphore
COMMIT
contexto 2
get semaphore
access data structure
SELECT * FROM TAB1...
release semaphore
COMMIT
Suponga que el primer contexto ejecuta satisfactoriamente las sentencias
SELECT y UPDATE, mientras que el segundo contexto obtiene el semforo y
accede a la estructura de datos. Ahora, el primer contexto intenta obtener el
semforo, pero no puede porque el segundo contexto lo est reteniendo. A
continuacin, el segundo contexto intenta leer una fila de la tabla TAB1, pero
se detiene en un bloqueo de la base de datos mantenido por el primer
contexto. La aplicacin se encuentra ahora en un estado en que el contexto 1
no puede terminar antes de que lo haga el contexto 2, y el contexto 2 est
esperando a que el contexto 1 termine. La aplicacin est en un punto muerto
Captulo 7. Acceso a bases de datos de varias hebras en aplicaciones C y C++ 231
pero, puesto que el gestor de bases de datos no sabe nada de la dependencia
del semforo, no se retrotraer ninguno de los contextos. La dependencia no
resuelta deja la aplicacin suspendida.
Puede evitar el punto muerto que se producira en el ejemplo anterior de
varias formas.
v Libere todos los bloqueos mantenidos antes de obtener el semforo.
Cambie el cdigo del contexto 1 de forma que realice una confirmacin
antes de obtener el semforo.
v No codifique sentencias de SQL en una seccin protegida por semforos.
Cambie el cdigo del contexto 2 de forma que libere el semforo antes de
ejecutar SELECT.
v Codifique todas las sentencias de SQL dentro de semforos.
Cambie el cdigo del contexto 1 de forma que obtenga el semforo antes de
ejecutar la sentencia SELECT. Aunque esta tcnica funcionar, no es muy
recomendable, puesto que los semforos colocarn en serie el acceso al
gestor de bases de datos, lo cual invalidar potencialmente las ventajas de
utilizar varias hebras.
v Establezca el parmetro de configuracin de la base de datos locktimeout en
un valor distinto de -1.
Aunque un valor distinto de -1 no impedir el punto muerto, permitir que
se reanude la ejecucin. Eventualmente, se retrotraer el contexto 2, puesto
que no puede obtener el bloqueo solicitado. Cuando maneje el error de
retrotraccin, el contexto 2 debe liberar el semforo. Una vez que se haya
liberado el semforo, el contexto 1 podr continuar y el contexto 2 ser libre
de reintentar su trabajo.
Las tcnicas para evitar puntos muertos se describen en trminos del ejemplo,
pero las puede aplicar a todas las aplicaciones de varias hebras. En general,
trate el gestor de bases de datos tal como tratara cualquier recurso protegido
y no experimentar problemas con las aplicaciones de varias hebras.
v Problemas potenciales con varias hebras en la pgina 230
Captulo 8. Programacin en COBOL
COBOL . . . . . . . . . . . . . 233
Restricciones de lenguaje en COBOL . . . 234
COBOL . . . . . . . . . . . . . 234
Archivos de entrada y salida para COBOL 234
Archivos include para COBOL . . . . . 234
Sentencias de SQL incorporado en COBOL 237
Variables del lenguaje principal en COBOL 240
COBOL . . . . . . . . . . . . 240
lenguaje principal en COBOL . . . . . 242
principal de tipo carcter de longitud fija
en COBOL . . . . . . . . . . . 243
Sintaxis de las variables grficas del
lenguaje principal de longitud fija en
COBOL . . . . . . . . . . . . 245
Variables de indicador en COBOL . . . 246
principal LOB en COBOL . . . . . . 246
principal de localizador de LOB en
COBOL . . . . . . . . . . . . 248
COBOL . . . . . . . . . . . . 248
Soporte de estructura del lenguaje
Tablas de indicadores en COBOL . . . 251
REDEFINES en elementos de datos de
grupos COBOL . . . . . . . . . 252
lenguaje principal para COBOL . . . . 253
Consideraciones sobre tipos de datos para
COBOL . . . . . . . . . . . . . 254
Tipos de datos de SQL soportados en
COBOL . . . . . . . . . . . . 254
Tipos de datos BINARY/COMP-4 de
COBOL . . . . . . . . . . . . 257
FOR BIT DATA en COBOL . . . . . 257
COBOL . . . . . . . . . . . . . 257
chino tradicional y UCS-2 para COBOL . . 258
COBOL orientado a objetos . . . . . . 259
Consideraciones sobre la programacin en COBOL
En las secciones siguientes se explican las consideraciones especiales sobre la
programacin en el lenguaje principal. Se incluye informacin sobre las
principal, la incorporacin de sentencias de SQL, las variables del lenguaje
principal y los tipos de datos soportados para las variables del lenguaje
principal. Para obtener informacin sobre cmo incorporar sentencias de SQL,
las restricciones del lenguaje y los tipos de datos soportados para las variables
del lenguaje principal, consulte la documentacin de Micro Focus COBOL.
v Programas de ejemplo COBOL en el manual Gua de desarrollo de
Restricciones de lenguaje en COBOL
Todos los punteros de API tienen una longitud de 4 bytes. Todas las variables
enteras utilizadas como parmetros de valor en las llamadas a las API se
deben declarar con una clusula USAGE COMP-5.
Acceso a bases de datos de varias hebras en COBOL
COBOL no da soporte al acceso a bases de datos de varias hebras.
Archivos de entrada y salida para COBOL
Por omisin, el archivo de entrada tiene la extensin .sqb, pero si se utiliza la
opcin de precompilacin TARGET (TARGET ANSI_COBOL, TARGET
IBMCOB, TARGET MFCOB o TARGET MFCOB16), el archivo de entrada
puede tener la extensin que elija el usuario.
Por omisin, el archivo de salida tiene la extensin .cbl, pero se puede
utilizar la opcin de precompilacin OUTPUT para especificar un nombre y
una va de acceso nuevos para el archivo fuente de salida modificado.
Archivos include para COBOL
Los archivos include especficos del lenguaje principal para COBOL tienen la
extensin de archivo .cbl. Si se utiliza la caracterstica Soporte para tipo de
datos de sistema principal System/390 del compilador COBOL de IBM, los
archivos include de DB2 para las aplicaciones se encuentran en el directorio
siguiente:
$HOME/sqllib/include/cobol_i
Si crea los programas de ejemplo de DB2 con los archivos de script
suministrados, deben cambiar la va de acceso de archivos include
especificada en los archivos de script por el directorio cobol_i, y no por el
directorio cobol_a.
Si no utiliza la caracterstica Soporte para tipo de datos de sistema principal
System/390 del compilador COBOL de IBM, o si utiliza una versin anterior
de este compilador, los archivos include de DB2 para las aplicaciones se
encuentran en el directorio siguiente:
$HOME/sqllib/include/cobol_a
A continuacin se describen los archivos include destinados a su uso en las
aplicaciones del usuario.
SQL (sql.cbl) Este archivo incluye prototipos especficos del lenguaje para el
vinculador, el precompilador y las API de recuperacin de
mensajes de error. Tambin define constantes del sistema.
SQLAPREP (sqlaprep.cbl)
Este archivo contiene definiciones necesarias para escribir su
propio precompilador.
SQLCA (sqlca.cbl)
Este archivo define la estructura del rea de comunicaciones
de SQL (SQLCA). El SQLCA contiene variables que utiliza el
gestor de bases de datos para proporcionar a una aplicacin
informacin de error sobre la ejecucin de sentencias de SQL
y llamadas a API.
SQLCA_92 (sqlca_92.cbl)
Este archivo contiene una versin que se ajusta a FIPS SQL92
Entry Level de la estructura rea de comunicaciones de SQL
(SQL Communications Area (SQLCA)). Debe incluir este
archivo en lugar del archivo sqlca.cbl cuando escriba
aplicaciones DB2 que se ajusten al estndar FIPS SQL92 Entry
Level. El precompilador de DB2 incluye automticamente el
archivo sqlca_92.cbl cuando la opcin LANGLEVEL del
precompilador se establece en SQL92E.
SQLCODES (sqlcodes.cbl)
estructura SQLCA.
SQLDA (sqlda.cbl)
Este archivo define la estructura del rea de descriptor de
SQL (SQLDA). El SQLDA se utiliza para pasar datos entre una
aplicacin y el gestor de bases de datos.
SQLEAU (sqleau.cbl)
Este archivo contiene definiciones de constantes y de
estructuras necesarias para las API de auditora de seguridad
de DB2. Si utiliza estas API, tiene que incluir este archivo en
el programa. Este archivo tambin contiene definiciones de
constantes y de valores de palabras clave para los campos del
registro de seguimiento de auditora. Programas externos o de
extraccin de seguimiento de auditora de proveedores
pueden utilizar estas definiciones.
SQLENV (sqlenv.cbl)
Este archivo define llamadas especficas del lenguaje para las
API del entorno de bases de datos y las estructuras,
constantes y cdigos de retorno correspondientes a dichas
interfaces.
Captulo 8. Programacin en COBOL 235
SQLETSD (sqletsd.cbl)
Este archivo define la estructura Descriptor de espacio de
tablas (Table Space Descriptor), SQLETSDESC, que se pasa a
la API para Crear base de datos, sqlgcrea.
SQLE819A (sqle819a.cbl)
Si la pgina de cdigos de la base de datos es 819 (ISO
Latin-1), esta secuencia clasifica series de caracteres que no
son FOR BIT DATA segn la clasificacin binaria CCSID 500
(EBCDIC internacional) del sistema principal. La API CREATE
DATABASE utiliza este archivo.
SQLE819B (sqle819b.cbl)
(EBCDIC ingls de EE.UU.) del sistema principal. La API
CREATE DATABASE utiliza este archivo.
Si la pgina de cdigos de la base de datos es 850 (ASCII
japons), esta secuencia clasifica series de caracteres que no
(EBCDIC japons) del sistema principal. La API CREATE
SQL1252A (sql1252a.cbl)
Si la pgina de cdigos de la base de datos es 1252 (Windows
SQL1252B (sql1252b.cbl)
SQLMON (sqlmon.cbl)
API del supervisor del sistema de bases de datos y las
estructuras, constantes y cdigos de retorno correspondientes
a dichas interfaces.
SQLMONCT (sqlmonct.cbl)
Este archivo contiene definiciones de constantes y definiciones
de estructuras de datos locales necesarias para llamar a las
API del Supervisor del sistema de bases de datos.
SQLSTATE (sqlstate.cbl)
Este archivo define constantes correspondientes al campo
SQLSTATE de la estructura SQLCA.
SQLUTBCQ (sqlutbcq.cbl)
Este archivo define la estructura de datos (Consulta de
contenedor de espacio de tablas (Table Space Container
Query), SQLB-TBSCONTQRY-DATA, que se utiliza con las
API de consulta del contenedor del espacio de tablas, sqlgstsc,
sqlgftcq y sqlgtcq.
SQLUTBSQ (sqlutbsq.cbl)
Este archivo define la estructura de datos Consulta de espacio
de tablas (Table Space Query), SQLB-TBSTQRY-DATA, que se
utiliza con las API de consulta del espacio de tablas, sqlgstsq,
sqlgftsq y sqlgtsq.
SQLUTIL (sqlutil.cbl)
correspondientes a las API de programas de utilidad y las
estructuras, constantes y cdigos necesarios para dichas
interfaces.
Sentencias de SQL incorporado en COBOL
Elemento Sintaxis correcta en COBOL
Par de palabras clave EXEC SQL
Serie de la sentencia Cualquier sentencia de SQL vlida
Terminador de la sentencia END-EXEC.
Por ejemplo:
EXEC SQL SELECT col INTO :hostvar FROM table END-EXEC.
v Las sentencias de SQL ejecutables se deben colocar en PROCEDURE
DIVISION. Las sentencias de SQL pueden ir precedidas de un nombre de
prrafo, al igual que una sentencia de COBOL.
v Las sentencias de SQL puede empezar en el rea A (columnas 8 a 11) o en
el rea B (columnas 12 a 72).
v Inicie cada sentencia de SQL con EXEC SQL y termnela con END-EXEC. El
precompilador SQL incluye cada una de las sentencias de SQL como
comentarios en el archivo fuente modificado.
v Debe utilizar el terminador de sentencias de SQL. De no utilizarlo, el
precompilador seguir hasta el siguiente terminador de la aplicacin. Esto
puede producir errores indeterminados.
de un comentario de SQL consiste en un guin doble (--), seguido de una
serie compuesta por cero o ms caracteres y terminada por un fin de lnea.
No coloque comentarios de SQL detrs del terminador de la sentencia de
SQL, puesto que ocasionaran errores de compilacin debido a que
parecera que forman parte del lenguaje COBOL.
v Los comentarios COBOL estn permitidos casi en cualquier lugar de una
sentencia de SQL incorporado. Las excepciones son:
No se permiten comentarios entre EXEC y SQL.
No se permiten comentarios en las sentencias que se ejecutan
dinmicamente.
v Las sentencias de SQL siguen las mismas normas de continuacin de lnea
que el lenguaje COBOL. No obstante, no divida el par de palabras clave
EXEC SQL en distintas lneas.
v No utilice la sentencia COPY de COBOL para incluir archivos que
contengan sentencias de SQL. Las sentencias de SQL se precompilan antes
de que se compile el mdulo. El precompilador pasar por alto la sentencia
COPY de COBOL. En su lugar, utilice la sentencia INCLUDE de SQL para
incluir dichos archivos.
Para localizar el archivo INCLUDE, el precompilador COBOL de DB2 busca
en primer lugar en el directorio actual y, a continuacin, en los directorios
especificados por la variable de entorno DB2INCLUDE. Considere los
ejemplos siguientes:
EXEC SQL INCLUDE payroll END-EXEC.
Si el archivo especificado en la sentencia INCLUDE no est encerrado
entre comillas, como en el ejemplo anterior, el precompilador C busca
payroll.sqb, luego payroll.cpy y luego payroll.cbl en cada uno de los
directorios que mira.
EXEC SQL INCLUDE pay/payroll.cbl END-EXEC.
Si el nombre de archivo est encerrado entre comillas, como en el caso
anterior, no se aade ninguna extensin al nombre.
Si el nombre del archivo entrecomillado no contiene una va de acceso
archivo INCLUDE. Por ejemplo, con DB2 para AIX, si DB2INCLUDE se
establece en /disk2:myfiles/cobol, el precompilador busca
./pay/payroll.cbl, luego /disk2/pay/payroll.cbl y finalmente
./myfiles/cobol/pay/payroll.cbl. En los mensajes del precompilador
se muestra la va de acceso en la que se encuentra realmente el archivo.
En las plataformas Windows, sustituya las barras inclinadas invertidas
(\) del ejemplo anterior por barras inclinadas.
Nota: el procesador de lnea de mandatos de DB2 coloca en antememoria el
valor de DB2INCLUDE. Para cambiar el valor de DB2INCLUDE
despus de haber emitido mandatos del CLP, entre el mandato
TERMINATE, luego vuelva a conectar con la base de datos y realice
una precompilacin del modo habitual.
v Para continuar una constante de serie en la lnea siguiente, en la columna 7
de la lnea de continuacin debe aparecer un '-' y en la columna 12 o
posteriores debe aparecer un delimitador de serie.
v Los operadores aritmticos de SQL se deben delimitar mediante espacios en
blanco.
v Pueden aparecer comentarios de COBOL de lnea completa en cualquier
lugar del programa, incluso dentro de sentencias de SQL.
v Cuando haga referencia a variables del lenguaje principal en una sentencia
de SQL, utilcelas exactamente tal como se han declarado.
solo espacio.
programa COBOL. Los tabuladores no se modifican.
varan en funcin de la plataforma. Por ejemplo, las plataformas basadas en
Windows utilizan Retorno de carro/Salto de lnea como fin de lnea,
mientras que los sistemas basados en UNIX slo utilizan un Salto de lnea.
Variables del lenguaje principal en COBOL
lenguaje principal en programas COBOL.
Variables del lenguaje principal en COBOL
Las variables del lenguaje principal son variables del lenguaje COBOL a las
que se hace referencia en las sentencias de SQL. Permiten que una aplicacin
pase datos de entrada al gestor de bases de datos y reciba datos de salida de
ste. Una vez que se ha precompilado la aplicacin, el compilador utiliza las
variables del lenguaje principal como cualquier otra variable de COBOL.
v Nombres de variables del lenguaje principal en COBOL en la pgina 241
v Declaraciones de variables del lenguaje principal en COBOL en la pgina
242
la pgina 242
pgina 246
Nombres de variables del lenguaje principal en COBOL
nombre declarado para stas. Se aplican las normas siguientes:
caracteres.
db2, que estn reservados para uso del sistema.
v Los elementos FILLER que utilizan las sintaxis de declaracin descritas a
continuacin estn permitidos en las declaraciones de variables del lenguaje
principal de grupos y el precompilador los pasar por alto. Sin embargo, si
se utiliza FILLER ms de una vez dentro de una seccin DECLARE de SQL,
el precompilador fallar. No se pueden incluir elementos FILLER en
declaraciones VARCHAR, LONG VARCHAR, VARGRAPHIC ni LONG
VARGRAPHIC.
v Puede utilizar guiones en los nombres de variables del lenguaje principal.
SQL interpreta un guin encerrado entre espacios como un operador de
resta. Utilice guiones sin espacios en los nombres de variables del lenguaje
principal.
v La clusula REDEFINES est permitida en las declaraciones de variables del
lenguaje principal.
v Las declaraciones de nivel 88 estn permitidas en la seccin de declaracin
de variables del lenguaje principal, pero se pasan por alto.
v Declaraciones de variables del lenguaje principal en COBOL en la pgina
242
la pgina 242
pgina 246
Declaraciones de variables del lenguaje principal en COBOL
declaraciones de variables del lenguaje principal. Esta seccin alerta al
precompilador acerca de las variables del lenguaje principal a las que se
puede hacer referencia en sentencias de SQL posteriores.
El precompilador COBOL slo reconoce un subconjunto de las declaraciones
vlidas de COBOL.
servidor
la pgina 242
pgina 246
Sintaxis de las variables numricas del lenguaje principal en COBOL
A continuacin se muestra la sintaxis de las variables numricas del lenguaje
principal.
Sintaxis de las variables numricas del lenguaje principal en COBOL
01
77
nombre-variable PICTURE
PIC
IS
serie-imagen
(1)
COMP-3
IS COMPUTATIONAL-3
USAGE COMP-5
COMPUTATIONAL-5
.
IS
VALUE valor
Notas:
1 Una alternativa de COMP-3 es PACKED-DECIMAL.
Coma flotante
01
77
nombre-variable
IS
USAGE
(1)
COMPUTATIONAL-1
COMP-1
(2)
COMPUTATIONAL-2
COMP-2
IS
VALUE valor
.
Notas:
1 REAL (SQLTYPE 480), Longitud 4
2 DOUBLE (SQLTYPE 480), Longitud 8
Consideraciones sobre las variables numricas del lenguaje principal:
1. Serie-imagen debe tener uno de los formatos siguientes:
v S9(m)V9(n)
v S9(m)V
v S9(m)
2. Los nueves se pueden expandir (por ejemplo, S999 en lugar de S9(3))
3. m y n deben ser enteros positivos.
Sintaxis de las variables del lenguaje principal de tipo carcter de
longitud fija en COBOL
A continuacin se muestra la sintaxis de las variables de tipo carcter del
lenguaje principal.
Sintaxis de las variables del lenguaje principal de tipo carcter en COBOL:
Longitud fija
01
77
PIC
IS
serie-imagen
IS
VALUE valor
.
Longitud variable
01 nombre-variable .
49 identificador-1 PICTURE
PIC
IS
S9(4)
COMP-5
IS COMPUTATIONAL-5
USAGE
IS
VALUE valor
.
PIC
IS
serie-imagen
IS
VALUE valor
.
Consideraciones sobre las variables del lenguaje principal de tipo carcter:
1. Serie-imagen debe tener el formato X(m). Como alternativa, se pueden
expandir las X (por ejemplo, XXX en lugar de X(3)).
2. m va de 1 a 254 para las series de longitud fija.
3. m va de 1 a 32 700 para las series de longitud variable.
4. Si m es mayor que 32 672, la variable del lenguaje principal se tratar
como una serie LONG VARCHAR y su uso puede estar restringido.
5. Utilice X y 9 como caracteres de imagen en cualquier clusula PICTURE.
No estn permitidos otros caracteres.
6. Las series de longitud variable constan de un elemento de longitud y un
elemento de valor. Puede utilizar nombres aceptables de COBOL para el
elemento de longitud y para el elemento de serie. No obstante, haga
referencia a las series de longitud variable por el nombres colectivo en las
sentencias de SQL.
7. En una sentencia CONNECT, como por ejemplo la que se muestra a
continuacin, a las variables del lenguaje principal de serie de caracteres
en COBOL dbname y userid se les eliminarn los blancos de cola antes del
proceso:
EXEC SQL CONNECT TO :dbname USER :userid USING :p-word
END-EXEC.
Sin embargo, y puesto que los espacios en blanco pueden ser significativos
en las contraseas, la variable del lenguaje principal p-word se debe
declarar como un elemento de datos VARCHAR, de forma que la
aplicacin pueda indicar explcitamente la longitud significativa de la
contrasea para la sentencia CONNECT, del modo siguiente:
01 dbname PIC X(8).
01 userid PIC X(8).
01 p-word.
49 L PIC S9(4) COMP-5.
49 D PIC X(18).
PROCEDURE DIVISION.
MOVE "sample" TO dbname.
MOVE "userid" TO userid.
MOVE "password" TO D OF p-word.
MOVE 8 TO L of p-word.
EXEC SQL CONNECT TO :dbname USER :userid USING :p-word
END-EXEC.
Sintaxis de las variables grficas del lenguaje principal de longitud fija en
COBOL
A continuacin se muestra la sintaxis de las variables grficas del lenguaje
principal.
Sintaxis de las variables grficas del lenguaje principal en COBOL: Longitud fija
01
77
PIC
IS
serie-imagen USAGE
IS
DISPLAY-1
IS
VALUE valor
.
Longitud variable
01 nombre-variable .
PIC
IS
S9(4)
COMP-5
IS COMPUTATIONAL-5
USAGE
IS
VALUE valor
.
PIC
IS
serie-imagen USAGE
IS
DISPLAY-1
IS
VALUE valor
.
Consideraciones sobre las variables grficas del lenguaje principal:
1. Serie-imagen debe tener el formato G(m). Como alternativa, se pueden
expandir las G (por ejemplo, GGG en lugar de G(3)).
2. m va de 1 a 127 para las series de longitud fija.
3. m va de 1 a 16 350 para las series de longitud variable.
4. Si m es mayor que 16 336, la variable del lenguaje principal se tratar
como una serie LONG VARGRAPHIC y su uso puede estar restringido.
Variables de indicador en COBOL
Las variables de indicador se deben declarar con tipo de datos PIC S9(4)
COMP-5.
v Tablas de indicadores en COBOL en la pgina 251
Sintaxis de las variables del lenguaje principal LOB en COBOL
principal de objeto grande (LOB) en COBOL.
Sintaxis de las variables del lenguaje principal LOB en COBOL
01 nombre-variable
USAGE
IS
SQL TYPE IS BLOB
CLOB
DBCLOB

( longitud ) .
K
M
G

1. Para BLOB y CLOB 1 <= longitud-lob <= 2 147 483 647.
2. Para DBCLOB 1 <= longitud-lob <= 1 073 741 823.
3. SQL TYPE IS, BLOB, CLOB, DBCLOB, K, M, G se pueden especificar en
maysculas, en minsculas o en una mezcla de ambas.
4. No se permite la inicializacin dentro de la declaracin LOB.
5. El nombre de la variable del lenguaje principal es el prefijo de LENGTH y
DATA en el cdigo generado por el precompilador.
Ejemplo de BLOB:
La declaracin:
01 MY-BLOB USAGE IS SQL TYPE IS BLOB(2M).
01 MY-BLOB.
49 MY-BLOB-LENGTH PIC S9(9) COMP-5.
49 MY-BLOB-DATA PIC X(2097152).
Ejemplo de CLOB:
La declaracin:
01 MY-CLOB USAGE IS SQL TYPE IS CLOB(125M).
01 MY-CLOB.
49 MY-CLOB-LENGTH PIC S9(9) COMP-5.
49 MY-CLOB-DATA PIC X(131072000).
Ejemplo de DBCLOB:
La declaracin:
01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(30000).
01 MY-DBCLOB.
49 MY-DBCLOB-LENGTH PIC S9(9) COMP-5.
49 MY-DBCLOB-DATA PIC G(30000) DISPLAY-1.
Sintaxis de las variables del lenguaje principal de localizador de LOB en
COBOL
principal de localizador de objeto grande (LOB) en COBOL.
Sintaxis de las variables del lenguaje principal de localizador de LOB en COBOL
01 nombre-variable
USAGE
IS
SQL TYPE IS BLOB-LOCATOR
CLOB-LOCATOR
DBCLOB-LOCATOR
.
LOB:
1. SQL TYPE IS, BLOB-LOCATOR, CLOB-LOCATOR, DBCLOB-LOCATOR se
pueden especificar en maysculas, en minsculas o en una mezcla de
ambas.
2. No se permite la inicializacin de localizadores.
Ejemplo de localizador de BLOB (existen otros tipos de localizadores de LOB
parecidos):
La declaracin:
01 MY-LOCATOR USAGE SQL TYPE IS BLOB-LOCATOR.
01 MY-LOCATOR PIC S9(9) COMP-5.
Sintaxis de las variables del lenguaje principal de referencia de archivos
en COBOL
principal de referencia de archivos en COBOL.
Sintaxis de las variables del lenguaje principal de referencia de archivos en
COBOL
01 nombre-variable
USAGE
IS
SQL TYPE IS BLOB-FILE
CLOB-FILE
DBCLOB-FILE
.
v SQL TYPE IS, BLOB-FILE, CLOB-FILE, DBCLOB-FILE se pueden especificar
en maysculas, en minsculas o en una mezcla de ambas.
Ejemplo de referencia de archivos BLOB (existen otros tipos de LOB
parecidos):
La declaracin:
01 MY-FILE USAGE IS SQL TYPE IS BLOB-FILE.
01 MY-FILE.
49 MY-FILE-NAME-LENGTH PIC S9(9) COMP-5.
49 MY-FILE-DATA-LENGTH PIC S9(9) COMP-5.
49 MY-FILE-FILE-OPTIONS PIC S9(9) COMP-5.
49 MY-FILE-NAME PIC X(255).
Soporte de estructura del lenguaje principal en COBOL
El precompilador COBOL soporta declaraciones de elementos de datos de
grupos en la seccin de declaracin de variables del lenguaje principal. Entre
otras cosas, esto proporciona un sistema taquigrfico para hacer referencia a
un conjunto de elementos de datos elementales en una sentencia de SQL. Por
ejemplo, se puede utilizar el siguiente elemento de datos de grupo para
acceder a algunas de las columnas de la tabla STAFF de la base de datos
SAMPLE:
01 staff-record.
05 staff-id pic s9(4) comp-5.
05 staff-name.
49 l pic s9(4) comp-5.
49 d pic x(9).
05 staff-info.
10 staff-dept pic s9(4) comp-5.
10 staff-job pic x(5).
Los elementos de datos de grupos de la seccin de declaracin pueden tener,
como elementos de datos subordinados, cualquiera de los tipos vlidos de
variable del lenguaje principal descritos anteriormente. Esto incluye todos los
tipos de datos numricos y de tipo carcter, as como los tipos de objeto
grande. Los elementos de datos de grupos se pueden anidar hasta un mximo
de 10 niveles. Observe que debe declarar los tipos de caracteres VARCHAR
con los elementos subordinados al nivel 49, tal como en el ejemplo anterior. Si
no estn al nivel 49, VARCHAR se trata como elemento de datos de grupos
con dos subordinados y est sujeto a las normas de declaracin y utilizacin
de elementos de datos de grupos. En el ejemplo anterior, staff-info es un
elemento de datos de grupos, mientras que staff-name es VARCHAR. Se
aplica el mismo principio a LONG VARCHAR, VARGRAPHIC y LONG
VARGRAPHIC. Puede declarar elementos de datos de grupos a cualquier
nivel entre 02 y 49.
Puede utilizar elementos de datos de grupos y los subordinados de los
mismos de cuatro maneras:
Mtodo 1.
Se puede hacer referencia al grupo entero como una sola variable del lenguaje
principal en una sentencia de SQL:
EXEC SQL SELECT id, name, dept, job
INTO :staff-record
FROM staff WHERE id = 10 END-EXEC.
El precompilador convierte la referencia a staff-record en una lista de todos
los elementos subordinados declarados dentro de staff-record, separados por
comas. Cada elemento elemental se califica con los nombres de grupo de
todos los niveles, a fin de evitar conflictos de denominacin con otros
elementos. Esto es equivalente al siguiente mtodo.
Mtodo 2.
La segunda manera de utilizar elementos de datos de grupos:
INTO
:staff-record.staff-id,
:staff-record.staff-name,
:staff-record.staff-info.staff-dept,
:staff-record.staff-info.staff-job
Nota: la referencia a staff-id se califica con su nombre de grupo utilizando
el prefijo staff-record., y no staff-id de staff-record como se hace
en COBOL puro.
Suponiendo que no existen otras variables del lenguaje principal que tengan
los mismos nombres que los subordinados de staff-record, la sentencia
anterior tambin se puede codificar como en el mtodo 3, eliminando la
calificacin explcita de grupo.
Mtodo 3.
Aqu, se hace referencia a los elementos subordinados de la forma tpica de
COBOL, sin calificarlos con su elemento de grupo concreto:
INTO
:staff-id,
:staff-name,
:staff-dept,
:staff-job
Como en COBOL puro, este mtodo resulta aceptable para el precompilador
siempre que un elemento subordinado determinado se pueda calificar de
forma exclusiva. Por ejemplo, si staff-job aparece ms de una vez en un
grupo, el precompilador emite un error indicando que se ha producido una
referencia ambigua:
SQL0088N La variable del lenguaje principal "staff-job" es ambigua.
Mtodo 4.
Para resolver la referencia ambigua, puede utilizar una calificacin parcial del
elemento subordinado, por ejemplo:
INTO
:staff-id,
:staff-name,
:staff-info.staff-dept,
:staff-info.staff-job
Puesto que una referencia a un solo elemento de grupo, como en el mtodo 1,
es equivalente a una lista de sus subordinados, separados por comas, existen
casos en que este tipo de referencia conduce a un error. Por ejemplo:
EXEC SQL CONNECT TO :staff-record END-EXEC.
Aqu, la sentencia CONNECT espera una sola variable del lenguaje principal
basada en caracteres. Proporcionando en su lugar el elemento de datos de
grupos staff-record, la variable del lenguaje principal tiene como resultado
el error de precompilacin siguiente:
SQL0087N La variable del lenguaje principal "staff-record" es una estructura
que se utiliza donde no se permiten referencias a estructuras.
Otros usos de los elementos de grupos que pueden ocasionar que se produzca
un error SQL0087N incluyen: PREPARE, EXECUTE IMMEDIATE, CALL,
variables de indicador y referencias a SQLDA. Los grupos que slo tienen un
subordinado estn permitidos en ambas situaciones, puesto que se trata de
referencias a subordinados individuales, como en los mtodos 2, 3 y 4
anteriores.
Tablas de indicadores en COBOL
El precompilador COBOL da soporte a la declaracin de tablas de variables de
indicador, que es conveniente utilizar con elementos de datos de grupos. Se
declaran del modo siguiente:
01 <indicator-table-name>.
05 <indicator-name> pic s9(4) comp-5
occurs <table-size> times.
Por ejemplo:
01 staff-indicator-table.
05 staff-indicator pic s9(4) comp-5
occurs 7 times.
Esta tabla de indicadores se puede utilizar eficazmente con el primer formato
de referencia de elementos de grupos indicado anteriormente:
INTO :staff-record :staff-indicator
Aqu, el precompilador detecta que staff-indicator se ha declarado como
tabla de indicadores y la expande en referencias a indicadores individuales
cuando procesa la sentencia de SQL. staff-indicator(1) se asocia a staff-id
de staff-record, staff-indicator(2) se asocia a staff-name de staff-record,
y as sucesivamente.
Nota: si en la tabla de indicadores existen k entradas de indicador ms que
subordinados tiene el elemento de datos (por ejemplo, si
staff-indicator tiene 10 entradas, haciendo que k=6), se pasan por
alto las k entradas de ms que se encuentran al final de la tabla de
indicadores. Del mismo modo, si hay k entradas de indicador menos
que subordinados, los k ltimos subordinados del elemento de grupo
no tienen asociado ningn indicador. Tenga en cuenta que puede hacer
referencia a elementos individuales en una tabla de indicadores en una
sentencia de SQL.
v Variables de indicador en COBOL en la pgina 246
REDEFINES en elementos de datos de grupos COBOL
Cuando declare variables del lenguaje principal, puede utilizar la clusula
REDEFINES. Si declara un miembro de un elemento de datos de grupo con la
clusula REDEFINES y se hace referencia a ese elemento de datos de grupo
como un todo en una sentencia de SQL, los elementos subordinados que
contienen la clusula REDEFINES no se expanden. Por ejemplo:
01 foo.
10 a pic s9(4) comp-5.
10 a1 redefines a pic x(2).
10 b pic x(10).
La referencia a foo en una sentencia de SQL es como sigue:
... INTO :foo ...
La sentencia anterior es equivalente a:
... INTO :foo.a, :foo.b ...
Es decir, el elemento subordinado a1, que se declara con la clusula
REDEFINES, no se expande automticamente en estas situaciones. Si a1 es
inequvoco, se puede hacer una referencia explcita a un subordinado que
tenga una clusula REDEFINES en una sentencia de SQL, del modo siguiente:
... INTO :foo.a1 ...
o
... INTO :a1 ...
Seccin declare de SQL con variables del lenguaje principal para COBOL
A continuacin se muestra un ejemplo de seccin de declaracin de SQL con
una variable del lenguaje principal declarada para los tipos de datos SQL
soportados.
*
01 age PIC S9(4) COMP-5.
01 divis PIC S9(9) COMP-5.
01 salary PIC S9(6)V9(3) COMP-3.
01 bonus USAGE IS COMP-1.
01 wage USAGE IS COMP-2.
01 nm PIC X(5).
01 varchar.
49 leng PIC S9(4) COMP-5.
49 strg PIC X(14).
01 longvchar.
49 len PIC S9(4) COMP-5.
49 str PIC X(6027).
01 MY-CLOB USAGE IS SQL TYPE IS CLOB(1M).
01 MY-CLOB-LOCATOR USAGE IS SQL TYPE IS CLOB-LOCATOR.
01 MY-CLOB-FILE USAGE IS SQL TYPE IS CLOB-FILE.
01 MY-BLOB USAGE IS SQL TYPE IS BLOB(1M).
01 MY-BLOB-LOCATOR USAGE IS SQL TYPE IS BLOB-LOCATOR.
01 MY-BLOB-FILE USAGE IS SQL TYPE IS BLOB-FILE.
01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(1M).
01 MY-DBCLOB-LOCATOR USAGE IS SQL TYPE IS DBCLOB-LOCATOR.
01 MY-DBCLOB-FILE USAGE IS SQL TYPE IS DBCLOB-FILE.
01 MY-PICTURE PIC G(16000) USAGE IS DISPLAY-1.
01 dt PIC X(10).
01 tm PIC X(8).
01 tmstmp PIC X(26).
01 wage-ind PIC S9(4) COMP-5.
*
Consideraciones sobre tipos de datos para COBOL
Las secciones siguientes describen cmo se correlacionan los tipos de datos de
SQL con tipos de datos de COBOL.
Tipos de datos de SQL soportados en COBOL
Determinados tipos de datos de COBOL predefinidos corresponden a tipos de
columna. Slo se pueden declarar como variables del lenguaje principal estos
tipos de datos de COBOL.
La tabla siguiente muestra el equivalente en COBOL de cada tipo de columna.
Cuando el precompilador encuentra una declaracin de una variable del
lenguaje principal, determina el valor del tipo de SQL apropiado. El gestor de
bases de datos utiliza este valor para convertir los datos intercambiados entre
la aplicacin y l mismo.
No se reconocen todas las descripciones de datos posibles para las variables
del lenguaje principal. Los elementos de datos COBOL deben ser coherentes
con los descritos en la tabla siguiente. Si utiliza otros elementos de datos, se
puede producir un error.
Tabla 15. Tipos de datos SQL correlacionados con declaraciones COBOL
Tipo de columna SQL
1
Tipo de datos de COBOL Descripcin del tipo de
columna SQL
SMALLINT (500 501) 01 name PIC S9(4) COMP-5. Entero con signo de 16 bits
INTEGER
(496 497)
01 name PIC S9(9) COMP-5. Entero con signo de 32 bits
BIGINT
(492 493)
01 name PIC S9(18) COMP-5. Entero con signo de 64 bits
DECIMAL(p,s)(484 485) 01 name PIC S9(m)V9(n) COMP-3. Decimal empaquetado
REAL
2
(480 481)
01 name USAGE IS COMP-1. Coma flotante de precisin
simple
DOUBLE
3
(480 481)
01 name USAGE IS COMP-2. Coma flotante de precisin
doble
CHAR(n)
(452 453)
01 name PIC X(n). Serie de caracteres de
longitud fija
VARCHAR(n)
(448 449)
01 name.
49 length PIC S9(4) COMP-5.
49 name PIC X(n).
1<=n<=32 672
Serie de caracteres de
longitud variable
Tabla 15. Tipos de datos SQL correlacionados con declaraciones COBOL (continuacin)
Tipo de columna SQL
1
columna SQL
LONG VARCHAR
(456 457)
01 name.
49 data PIC X(n).
32 673<=n<=32 700
longitud variable larga
CLOB(n)
(408 409)
01 MY-CLOB USAGE IS SQL TYPE IS CLOB(n).
1<=n<=2 147 483 647
longitud variable y objeto
grande
4
(964 965)
01 MY-CLOB-LOCATOR USAGE IS SQL TYPE IS
CLOB-LOCATOR.
Identifica las entidades
CLOB que residen en el
servidor
Variable de referencia de
archivo CLOB
4
(920 921)
01 MY-CLOB-FILE USAGE IS SQL TYPE IS
CLOB-FILE.
Descriptor de archivo que
contiene datos CLOB
BLOB(n)
(404 405)
01 MY-BLOB USAGE IS SQL TYPE IS BLOB(n).
1<=n<=2 147 483 647
Serie binaria de longitud
variable y objeto grande
4
(960 961)
01 MY-BLOB-LOCATOR USAGE IS SQL TYPE IS
BLOB-LOCATOR.
BLOB que residen en el
servidor
BLOB
4
(916 917)
01 MY-CLOB-FILE USAGE IS SQL TYPE IS
CLOB-FILE.
contiene datos CLOB
DATE (384 385) 01 identifier PIC X(10). Serie de caracteres de 10
bytes
TIME (388 389) 01 identifier PIC X(8). Serie de caracteres de 8
bytes
TIMESTAMP (392 393) 01 identifier PIC X(26). Serie de caracteres de 26
bytes
Nota: los tipos de datos siguientes slo estn disponibles en el entorno DBCS.
GRAPHIC(n)
(468 469)
01 name PIC G(n) DISPLAY-1. Serie de caracteres de
doble byte y longitud fija
VARGRAPHIC(n)
(464 465)
01 name.
49 name PIC G(n) DISPLAY-1.
1<=n<=16 336
doble byte y longitud
variable con indicador de
longitud de serie de 2
bytes
LONG VARGRAPHIC
(472 473)
01 name.
49 name PIC G(n) DISPLAY-1.
16 337<=n<=16 350
doble byte y longitud
variable con indicador de
longitud de serie de 2
bytes
Tabla 15. Tipos de datos SQL correlacionados con declaraciones COBOL (continuacin)
Tipo de columna SQL
1
columna SQL
DBCLOB(n)
(412 413)
01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(n).
1<=n<=1 073 741 823
doble byte, longitud
variable y objeto grande
con indicador de longitud
de serie de 4 bytes
4
(968 969)
01 MY-DBCLOB-LOCATOR USAGE IS SQL TYPE IS
DBCLOB-LOCATOR.
DBCLOB que residen en el
servidor
archivos DBCLOB
4
(924 925)
01 MY-DBCLOB-FILE USAGE IS SQL TYPE IS
DBCLOB-FILE.
contiene datos DBCLOB
Notas:
v FLOAT
v DOUBLE PRECISION
A continuacin mostramos normas adicionales para los tipos de datos COBOL
soportados:
v PIC S9 y COMP-3/COMP-5 son necesarios cuando aparecen.
v Puede utilizar el nmero de nivel 77 en lugar de 01 para todos los tipos de
columna, a excepcin de VARCHAR, LONG VARCHAR, VARGRAPHIC,
LONG VARGRAPHIC y todos los tipos de variable LOB.
v Cuando declare variables del lenguaje principal para tipos de columna
DECIMAL(p,s), siga las normas siguientes. Consulte el ejemplo siguiente:
01 identifier PIC S9(m)V9(n) COMP-3
Utilice V para indicar la coma decimal.
Los valores para n y m deben ser mayores o iguales a 1.
El valor para n + m no puede exceder de 31.
El valor para s es igual al valor de n.
El valor para p es igual al valor de n + m.
Los factores de repeticin (n) y (m) son opcionales. Todos los ejemplos
siguientes son vlidos:
01 identifier PIC S9(3)V COMP-3
01 identifier PIC SV9(3) COMP-3
01 identifier PIC S9V COMP-3
01 identifier PIC SV9 COMP-3
Se puede utilizar PACKED-DECIMAL en lugar de COMP-3.
v El precompilador de COBOL no da soporte a matrices.
v Seccin declare de SQL con variables del lenguaje principal para COBOL
en la pgina 253
Tipos de datos BINARY/COMP-4 de COBOL
El precompilador COBOL de DB2 da soporte al uso de los tipos de datos
BINARY, COMP y COMP-4 dondequiera que estn permitidas las variables
del lenguaje principal y los indicadores, siempre que el compilador COBOL de
destino vea (o se pueda hacer que vea) los tipos de datos BINARY, COMP o
COMP-4 como equivalentes al tipo de datos COMP-5. En esta publicacin,
estas variables del lenguaje principal e indicadores se muestran con el tipo
COMP-5. Los compiladores de destino soportados por DB2 que tratan COMP,
COMP-4, BINARY COMP y COMP-5 como equivalentes son:
v IBM COBOL Set para AIX
v Micro Focus COBOL para AIX
FOR BIT DATA en COBOL
Determinadas columnas de bases de datos se pueden declarar FOR BIT
DATA. Estas columnas, que generalmente contienen caracteres, se utilizan
para contener informacin binaria. Los tipos de datos CHAR(n), VARCHAR,
LONG VARCHAR y BLOB son los tipos de variable del lenguaje principal de
COBOL que pueden contener datos binarios. Utilice estos tipos de datos
cuando trabaje con columnas que tengan el atributo FOR BIT DATA.
Variables SQLSTATE y SQLCODE en COBOL
Cuando se utiliza la opcin de precompilacin LANGLEVEL con el valor
lenguaje principal:
01 SQLSTATE PICTURE X(5).
01 SQLCODE PICTURE S9(9) USAGE COMP.
.
.
.
Si no se especifica ninguna de ellas, se supone la declaracin SQLCODE
durante el paso de precompilacin. 01 tambin puede ser 77 y PICTURE puede
ser PIC. Observe que, si se utiliza esta opcin, no se debe especificar la
sentencia INCLUDE SQLCA.
Para las aplicaciones formadas por varios archivos fuente, las declaraciones
SQLCODE y SQLSTATE se pueden incluir en cada uno de los archivos fuente,
tal como en el ejemplo anterior.
Consideraciones sobre EUC en japons o chino tradicional y UCS-2 para
COBOL
Los datos grficos enviados desde una aplicacin que se ejecuta bajo un juego
de cdigos eucJp o eucTW, o se conecta a una base de datos UCS-2, se
identifican con el identificador de la pgina de cdigos UCS-2. La aplicacin
debe convertir una serie de caracteres grficos a UCS-2 antes de enviarla al
servidor de base de datos. Del mismo modo, los datos grficos recuperados
de una base de datos UCS-2 por una aplicacin, o de cualquier base de datos
por una aplicacin que se ejecute bajo una pgina de cdigos EUC eucJP o
eucTW, se codifican utilizando UCS-2. Esto requiere que la aplicacin realice
internamente una conversin de UCS-2 a la pgina de cdigos de la
aplicacin, a menos que se vayan a presentar datos UCS-2 al usuario.
La aplicacin es responsable de convertir a UCS-2 y desde UCS-2, puesto que
esta conversin se debe llevar a cabo antes de copiar los datos al SQLDA o
desde esta. DB2 Universal Database no suministra ninguna rutina de
conversin que resulte accesible para la aplicacin. En cambio, se deben
utilizar las llamadas del sistema disponibles desde el sistema operativo. En el
caso de una base de datos UCS-2, tambin puede considerar la posibilidad de
utilizar las funciones escalares VARCHAR y VARGRAPHIC.
v Funcin escalar VARCHAR en el manual Consulta de SQL, Volumen 1
v Funcin escalar VARGRAPHIC en el manual Consulta de SQL, Volumen 1
COBOL orientado a objetos
Si utiliza COBOL orientado a objetos, debe tener en cuenta lo siguiente:
v Slo pueden aparecer sentencias de SQL en el primer programa o clase de
una unidad de compilacin. Esta restriccin se debe a que el precompilador
inserta datos de trabajo temporales en la primera seccin Working-Storage
que encuentra.
v En un programa en COBOL orientado a objetos, cada clase que contenga
sentencias de SQL debe tener una seccin Working-Storage a nivel de clase,
aunque est vaca. Esta seccin se utiliza para almacenar definiciones de
datos generadas por el precompilador.
Captulo 9. Programacin en FORTRAN
FORTRAN . . . . . . . . . . . . 261
Restricciones del lenguaje en FORTRAN . . 262
Llamada por referencia en FORTRAN . . 262
Lneas de depuracin y de comentario en
FORTRAN . . . . . . . . . . . 262
Consideraciones sobre la precompilacin
en FORTRAN . . . . . . . . . . 262
en FORTRAN . . . . . . . . . . 262
Archivos de entrada y salida para
FORTRAN . . . . . . . . . . . . 262
Archivos include para FORTRAN . . . 263
Archivos include en aplicaciones
FORTRAN . . . . . . . . . . . 266
Sentencias de SQL incorporado en
FORTRAN . . . . . . . . . . . . 267
FORTRAN . . . . . . . . . . . . 268
FORTRAN . . . . . . . . . . . 269
lenguaje principal en FORTRAN . . . . 271
Sintaxis de las variables de tipo carcter
del lenguaje principal en FORTRAN . . 271
Variables de indicador en FORTRAN . . 273
principal de objeto grande (LOB) en
FORTRAN . . . . . . . . . . . 273
(LOB) en FORTRAN . . . . . . . . 274
FORTRAN . . . . . . . . . . . 275
lenguaje principal para FORTRAN . . . 276
Tipos de datos SQL soportados en
FORTRAN . . . . . . . . . . . . 276
Consideraciones sobre juegos de caracteres
de varios bytes en FORTRAN. . . . . . 278
chino tradicional y UCS-2 para FORTRAN . 278
FORTRAN . . . . . . . . . . . . 279
Consideraciones sobre la programacin en FORTRAN
programacin en el lenguaje principal. Se incluye informacin sobre las
principal, la incorporacin de sentencias de SQL y los tipos de datos
soportados para las variables del lenguaje principal.
Nota: soporte de FORTRAN estabilizado en DB2 Versin 5, y no hay ninguna
mejora de FORTRAN planificada para el futuro. Por ejemplo, el
precompilador FORTRAN no puede manejar identificadores de objetos
SQL, como por ejemplo nombres de tabla, que tengan una longitud
superior a 18 bytes. Para utilizar las caractersticas incorporadas en DB2
despus de la Versin 5, como por ejemplo los nombres de tabla de
longitud entre 19 y 128 bytes, debe escribir sus aplicaciones en un
lenguaje que no sea FORTRAN.
Restricciones del lenguaje en FORTRAN
Las siguientes secciones describen las restricciones del lenguaje
correspondientes a FORTRAN.
Llamada por referencia en FORTRAN
Algunos parmetros de las API requieren direcciones en lugar de valores en
las variables de llamada. El gestor de bases de datos proporciona las API GET
ADDRESS, DEREFERENCE ADDRESS y COPY MEMORY, que simplifican la
posibilidad de que el usuario proporcione estos parmetros.
v sqlgdref - Dereference Address en el manual Administrative API Reference
v sqlgaddr - Get Address en el manual Administrative API Reference
v sqlgmcpy - Copy Memory en el manual Administrative API Reference
Lneas de depuracin y de comentario en FORTRAN
Algunos compiladores de FORTRAN tratan las lneas que contienen una 'D' o
una 'd' en la columna 1 como lneas condicionales. Estas lneas se pueden
compilar para su depuracin o se pueden tratar como comentarios. El
precompilador siempre tratar las lneas que contienen una 'D' o una 'd' en la
columna 1 como comentarios.
Consideraciones sobre la precompilacin en FORTRAN
Los elementos siguientes afectan al proceso de precompilacin:
v El precompilador slo admite dgitos, blancos y caracteres de tabulacin en
las columnas 1-5 de las lneas de continuacin.
v Las constantes Hollerith no se reciben soporte en archivos fuente .sqf.
Acceso a bases de datos de varias hebras en FORTRAN
FORTRAN no da soporte al acceso a bases de datos de varias hebras.
Archivos de entrada y salida para FORTRAN
Por omisin, el archivo de entrada tiene la extensin .sqf, pero si se utiliza la
opcin de precompilacin TARGET, el archivo de entrada puede tener la
extensin que desee el usuario.
Por omisin, el archivo de salida tiene la extensin .f en plataformas basadas
en UNIX y la extensin .for en plataformas basadas en Windows; sin
embargo, puede utilizar la opcin de precompilacin OUTPUT para
especificar un nuevo nombre y va de acceso para el archivo fuente de salida
modificado.
Archivos include
Las siguientes secciones describen los archivos include correspondientes a
FORTRAN.
Archivos include para FORTRAN
Los archivos include especficos del lenguaje principal para FORTRAN tienen
la extensin .f en plataformas basadas en UNIX y la extensin .for en
plataformas basadas en Windows. Puede utilizar los siguientes archivos
include de FORTRAN en las aplicaciones.
SQL (sql.f) Este archivo incluye prototipos especficos del lenguaje para el
vinculador, el precompilador y las API de recuperacin de
mensajes de error. Tambin define constantes del sistema.
SQLAPREP (sqlaprep.f)
Este archivo contiene definiciones necesarias para escribir su
propio precompilador.
SQLCA (sqlca_cn.f, sqlca_cs.f)
Este archivo define la estructura del rea de comunicaciones
de SQL (SQLCA). El SQLCA contiene variables que utiliza el
gestor de bases de datos para proporcionar a una aplicacin
informacin de error sobre la ejecucin de sentencias de SQL
y llamadas a API.
Se proporcionan dos archivos SQLCA para las aplicaciones
FORTRAN. El valor por omisin, sqlca_cs.f, define la
estructura SQLCA en un formato compatible con SQL de IBM.
El archivo sqlca_cn.f, precompilado con la opcin SQLCA
NONE, define la estructura SQLCA para un mejor rendimiento.
SQLCA_92 (sqlca_92.f)
Este archivo contiene una versin que se ajusta a FIPS SQL92
Entry Level de la estructura rea de comunicaciones de SQL
(SQL Communications Area (SQLCA)). Se debe incluir este
archivo en lugar de los archivos sqlca_cn.f o sqlca_cs.f
cuando se escriban aplicaciones DB2 que se ajusten al
estndar FIPS SQL92 Entry Level. El precompilador de DB2
incluye automticamente el archivo sqlca_92.f cuando la
opcin LANGLEVEL del precompilador se establece en
SQL92E.
SQLCODES (sqlcodes.f)
estructura SQLCA.
SQLDA (sqldact.f)
Este archivo define la estructura del rea de descriptor de
SQL (SQLDA). El SQLDA se utiliza para pasar datos entre una
aplicacin y el gestor de bases de datos.
SQLEAU (sqleau.f)
Este archivo contiene definiciones de constantes y de
estructuras necesarias para las API de auditora de seguridad
de DB2. Si utiliza estas API, tiene que incluir este archivo en
el programa. Este archivo tambin contiene definiciones de
constantes y de valores de palabras clave para los campos del
registro de seguimiento de auditora. Programas externos o de
extraccin de seguimiento de auditora de proveedores
pueden utilizar estas definiciones.
SQLENV (sqlenv.f)
API del entorno de bases de datos y las estructuras,
constantes y cdigos de retorno correspondientes a dichas
interfaces.
SQLE819A (sqle819a.f)
SQLE819B (sqle819b.f)
SQL1252A (sql1252a.f)
SQL1252B (sql1252b.f)
SQLMON (sqlmon.f)
API del supervisor del sistema de bases de datos y las
estructuras, constantes y cdigos de retorno correspondientes
a dichas interfaces.
SQLSTATE (sqlstate.f)
Este archivo define constantes correspondientes al campo
SQLSTATE de la estructura SQLCA.
SQLUTIL (sqlutil.f)
correspondientes a las API de programas de utilidad y las
estructuras, constantes y cdigos necesarios para dichas
interfaces.
v Archivos include en aplicaciones FORTRAN en la pgina 266
Archivos include en aplicaciones FORTRAN
Existen dos mtodos para incluir archivos: la sentencia EXEC SQL INCLUDE
y la sentencia INCLUDE de FORTRAN. El precompilador pasar por alto las
sentencias INCLUDE de FORTRAN y slo procesar los archivos incluidos
mediante la sentencia EXEC SQL.
Para localizar el archivo INCLUDE, el precompilador FORTRAN de DB2
busca en primer lugar en el directorio actual y, a continuacin, en los
directorios especificados por la variable de entorno DB2INCLUDE. Considere
los ejemplos siguientes:
v EXEC SQL INCLUDE payroll
Si el archivo especificado en la sentencia INCLUDE no est encerrado entre
comillas, tal como en el ejemplo anterior, el precompilador busca
payroll.sqf y luego payroll.f (payroll.for en plataformas basadas en
Windows), en cada uno de los directorios que mira.
v EXEC SQL INCLUDE pay/payroll.f
Si el nombre de archivo est encerrado entre comillas, tal como en el caso
anterior, no se aade ninguna extensin al nombre. (Para plataformas
basadas en Windows, el archivo se especificara como pay\payroll.for.)
Si el nombre de archivo entrecomillado no contiene una va de acceso
archivo de INCLUDE. Por ejemplo, con DB2 para plataformas basadas en
AIX, si DB2INCLUDE se establece en /disk2:myfiles/fortran, el
precompilador busca ./pay/payroll.f, luego /disk2/pay/payroll.f y
finalmente ./myfiles/cobol/pay/payroll.f. En los mensajes del
precompilador se muestra la va de acceso en que se encuentra realmente el
archivo. En plataformas basadas en Windows, sustituya las barras
inclinadas invertidas (\) por barras inclinadas y sustituya for por la
extensin f en el ejemplo anterior.
Nota: el procesador de lnea de mandatos de DB2 coloca en antememoria el
valor de DB2INCLUDE. Para cambiar el valor de DB2INCLUDE
despus de haber emitido mandatos del CLP, entre el mandato
TERMINATE, luego vuelva a conectar con la base de datos y realice
una precompilacin del modo habitual.
v DB2 registry and environment variables en el manual Administration
Guide: Performance
v Archivos include para FORTRAN en la pgina 263
Sentencias de SQL incorporado en FORTRAN
Elemento Sintaxis correcta en FORTRAN
Palabra clave EXEC SQL
Serie de la sentencia Cualquier sentencia de SQL vlida con blancos
como delimitadores
Terminador de la sentencia Fin de la lnea fuente.
El fin de la lnea fuente sirve como terminador de sentencia. Si se contina la
lnea, el terminador de sentencia es el fin de la ltima lnea de continuacin.
Por ejemplo:
EXEC SQL SELECT COL INTO :hostvar FROM TABLE
v Codifique las sentencias de SQL nicamente entre las columnas 7 y 72.
v Utilice comentarios de FORTRAN de lnea completa, o comentarios de SQL,
pero no utilice el carcter '!' de comentario de fin de lnea de FORTRAN en
las sentencias de SQL. Este carcter de comentario se puede utilizar en
cualquier otra parte, incluso en las declaraciones de variables del lenguaje
principal.
v Utilice blancos como delimitadores cuando codifique sentencias de SQL
incorporado, aunque las sentencias de FORTRAN no requieren blancos
como delimitadores.
v Utilice nicamente una sentencia de SQL para cada lnea fuente en
FORTRAN. Para las sentencias que necesitan ms de una lnea fuente, se
aplican las normas habituales de continuacin de FORTRAN. No divida el
par de palabras clave EXEC SQL en distintas lneas.
de un comentario de SQL consiste en un guin doble (--) seguido de una
serie compuesta por cero o ms caracteres y terminada por un fin de lnea.
v Los comentarios FORTRAN estn permitidos casi en cualquier lugar de una
sentencia de SQL incorporada. Las excepciones son:
No se permiten comentarios entre EXEC y SQL.
No se permiten comentarios en las sentencias que se ejecutan
dinmicamente.
La ampliacin de utilizar ! para codificar un comentario FORTRAN al
final de una lnea no recibe soporte dentro de una sentencia de SQL
incorporado.
v Utilice una notacin exponencial cuando especifique una constante real en
las sentencias de SQL. El gestor de bases de datos interpreta una serie de
dgitos con una coma decimal en una sentencia de SQL como una constante
decimal, no como una constante real.
v Los nmeros de sentencia no son vlidos en las sentencias de SQL que
preceden a la primera sentencia FORTRAN ejecutable. Si una sentencia de
SQL tiene asociado un nmero de sentencia, el precompilador genera una
sentencia CONTINUE etiquetada que precede directamente a la sentencia
de SQL.
v Cuando haga referencia a variables del lenguaje principal dentro de una
sentencia de SQL, utilcelas exactamente tal como se han declarado.
solo espacio.
programa FORTRAN. Los tabuladores no se modifican.
varan en funcin de la plataforma. Por ejemplo, las plataformas basadas en
Windows utilizan Retorno de carro/Salto de lnea como fin de lnea,
mientras que las plataformas basadas en UNIX slo utilizan un Salto de
lnea.
Variables del lenguaje principal en FORTRAN
lenguaje principal en programas FORTRAN.
Variables del lenguaje principal en FORTRAN
Las variables del lenguaje principal son variables del lenguaje FORTRAN a las
que se hace referencia en sentencias de SQL. Permiten que una aplicacin pase
datos de entrada al gestor de bases de datos y reciba datos de salida de ste.
Una vez que se ha precompilado la aplicacin, el compilador utiliza las
variables del lenguaje principal como cualquier otra variable de FORTRAN.
v Nombres de variables del lenguaje principal en FORTRAN en la pgina
269
v Declaraciones de variables del lenguaje principal en FORTRAN en la
pgina 270
v Variables de indicador en FORTRAN en la pgina 273
en la pgina 271
Nombres de variables del lenguaje principal en FORTRAN
nombre declarado para stas. Se aplican las sugerencias siguientes:
caracteres.
db2, que estn reservados para uso del sistema.
v Declaraciones de variables del lenguaje principal en FORTRAN en la
pgina 270
en la pgina 271
Declaraciones de variables del lenguaje principal en FORTRAN
declaraciones de variables del lenguaje principal. Esto alerta al precompilador
acerca de las variables del lenguaje principal a las que se puede hacer
referencia en sentencias de SQL posteriores.
El precompilador FORTRAN slo reconoce un subconjunto de declaraciones
de FORTRAN vlidas como declaraciones de variables del lenguaje principal
vlidas. Estas declaraciones definen variables numricas o de tipo carcter.
Una variable numrica del lenguaje principal se puede utilizar como variable
de entrada o de salida para cualquier valor numrico de entrada o salida de
SQL. Una variable del lenguaje principal de tipo carcter se puede utilizar
como variable de entrada o de salida para cualquier valor de tipo carcter, de
fecha, de hora o de indicacin de la hora, de entrada o salida de SQL. El
programador se tiene que asegurar de que las variables de salida sean lo
suficientemente largas como para contener los valores que van a recibir.
servidor
en la pgina 271
Sintaxis de las variables numricas del lenguaje principal en FORTRAN
A continuacin se muestra la sintaxis de las variables numricas del lenguaje
principal en FORTRAN.
Sintaxis de las variables numricas del lenguaje principal en FORTRAN
INTEGER*2
INTEGER*4
REAL*4
REAL *8
DOUBLE PRECISION
,
nombrevar
/ valor-inicial /
Consideraciones sobre las variables numricas del lenguaje principal:

1. REAL*8 y DOUBLE PRECISION son equivalentes.
2. Utilice una E en lugar de una D como indicador de exponente para las
constantes REAL*8.
Sintaxis de las variables de tipo carcter del lenguaje principal en
FORTRAN
A continuacin se muestra la sintaxis de las variables de tipo carcter de
longitud fija del lenguaje principal.
Sintaxis de las variables del lenguaje principal de tipo carcter en FORTRAN:
Longitud fija

,
CHARACTER nombrevar
*n / valor-inicial /
A continuacin se muestra la sintaxis de las variables de tipo carcter de

longitud variable del lenguaje principal.
Longitud variable

,
SQL TYPE IS VARCHAR (longitud) nombrevar
Consideraciones sobre las variables del lenguaje principal de tipo carcter:
1. *n tiene un valor mximo de 254.
2. Si la longitud est entre 1 y 32 672, ambos inclusive, la variable del
lenguaje principal es de tipo VARCHAR(SQLTYPE 448).
3. Si la longitud est entre 32 673 y 32 700, ambos inclusive, la variable del
lenguaje principal es de tipo LONG VARCHAR(SQLTYPE 456).
4. No est permitida la inicializacin de variables del lenguaje principal
VARCHAR y LONG VARCHAR dentro de la declaracin.
Ejemplo de VARCHAR:
La declaracin:
sql type is varchar(1000) my_varchar
character my_varchar(1000+2)
integer*2 my_varchar_length
character my_varchar_data(1000)
equivalence( my_varchar(1),
+ my_varchar_length )
equivalence( my_varchar(3),
+ my_varchar_data )
La aplicacin puede manipular tanto my_varchar_length como
my_varchar_data; por ejemplo, para establecer o examinar el contenido de la
variable del lenguaje principal. El nombre base (en este caso, my_varchar), se
utiliza en las sentencias de SQL para hacer referencia a la VARCHAR como un
todo.
Ejemplo de LONG VARCHAR:
La declaracin:
sql type is varchar(10000) my_lvarchar
character my_lvarchar(10000+2)
integer*2 my_lvarchar_length
character my_lvarchar_data(10000)
equivalence( my_lvarchar(1),
+ my_lvarchar_length )
equivalence( my_lvarchar(3),
+ my_lvarchar_data )
La aplicacin puede manipular tanto my_lvarchar_length como
my_lvarchar_data; por ejemplo, para establecer o examinar el contenido de la
variable del lenguaje principal. El nombre base (en este caso, my_lvarchar) se
utiliza en las sentencias de SQL para hacer referencia a la LONG VARCHAR
como un todo.
Nota: en una sentencia CONNECT, como por ejemplo la que se muestra a
continuacin, a las variables del lenguaje principal de serie de
caracteres en FORTRAN dbname y userid se les eliminarn los blancos
de cola antes del proceso.
EXEC SQL CONNECT TO :dbname USER :userid USING :passwd
No obstante, puesto que los blancos pueden ser significativos en las
contraseas, debe declarar las variables del lenguaje principal para
contraseas como VARCHAR, y hacer que el campo de longitud
establecido refleje la longitud real de la contrasea:
character*8 dbname, userid
sql type is varchar(18) passwd
character*18 passwd_string
equivalence(passwd_data,passwd_string)
dbname = sample
userid = userid
passwd_length= 8
passwd_string = password
EXEC SQL CONNECT TO :dbname USER :userid USING :passwd
Variables de indicador en FORTRAN
Las variables de indicador se deben declarar con tipo de datos INTEGER*2.
FORTRAN
principal de objeto grande (LOB) en FORTRAN.
FORTRAN

,
SQL TYPE IS BLOB (longitud ) nombre-variable
CLOB K
M
G

1. Los tipos GRAPHIC no se soportan en FORTRAN.
2. SQL TYPE IS, BLOB, CLOB, K, M, G se pueden especificar en maysculas,
en minsculas o en una mezcla de ambas.
3. Para BLOB y CLOB 1 <= longitud-lob <= 2 147 483 647.
4. No se permite la inicializacin de un LOB dentro de una declaracin LOB.
5. El nombre de la variable del lenguaje principal es el prefijo de longitud? y
datos en el cdigo generado por el precompilador.
Ejemplo de BLOB:
La declaracin:
sql type is blob(2m) my_blob
character my_blob(2097152+4)
integer*4 my_blob_length
character my_blob_data(2097152)
equivalence( my_blob(1),
+ my_blob_length )
equivalence( my_blob(5),
+ my_blob_data )
Ejemplo de CLOB:
La declaracin:
sql type is clob(125m) my_clob
character my_clob(131072000+4)
integer*4 my_clob_length
character my_clob_data(131072000)
equivalence( my_clob(1),
+ my_clob_length )
equivalence( my_clob(5),
+ my_clob_data )
Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en FORTRAN
principal de localizador de objeto grande (LOB) en FORTRAN.
Sintaxis de las variables del lenguaje principal de localizador de objeto grande
(LOB) en FORTRAN

,
SQL TYPE IS BLOB_LOCATOR nombre-variable
CLOB_LOCATOR

LOB:
2. SQL TYPE IS, BLOB_LOCATOR, CLOB_LOCATOR se pueden especificar
en maysculas, en minsculas o en una mezcla de ambas.
3. No se permite la inicializacin de localizadores.
Ejemplo de localizador de CLOB (El localizador de BLOB es parecido):
La declaracin:
SQL TYPE IS CLOB_LOCATOR my_locator
integer*4 my_locator
Sintaxis de las variables del lenguaje principal de referencia de archivos
en FORTRAN
principal de referencia de archivos en FORTRAN.
Sintaxis de las variables del lenguaje principal de referencia de archivos en
FORTRAN

,
SQL TYPE IS BLOB_FILE nombre-variable
CLOB_FILE
Consideraciones sobre las variables del lenguaje principal de referencia de

archivos:
2. SQL TYPE IS, BLOB-FILE, CLOB-FILE se pueden especificar en
maysculas, en minsculas o en una mezcla de ambas.
Ejemplo de una variable de referencia de archivos BLOB (La variable de
referencia de archivos CLOB es parecida):
SQL TYPE IS BLOB_FILE my_file
character my_file(267)
integer*4 my_file_name_length
integer*4 my_file_data_length
integer*4 my_file_file_options
character*255 my_file_name
equivalence( my_file(1),
+ my_file_name_length )
+ my_file_data_length )
+ my_file_file_options )
+ my_file_name )
Seccin declare de SQL con variables del lenguaje principal para
FORTRAN
A continuacin se muestra un ejemplo de seccin de declaracin de SQL con
una variable del lenguaje principal declarada para cada tipo de datos
soportado:
INTEGER*2 AGE /26/
INTEGER*4 DEPT
REAL*4 BONUS
REAL*8 SALARY
CHARACTER MI
CHARACTER*112 ADDRESS
SQL TYPE IS VARCHAR (512) DESCRIPTION
SQL TYPE IS VARCHAR (32000) COMMENTS
SQL TYPE IS CLOB (1M) CHAPTER
SQL TYPE IS CLOB_LOCATOR CHAPLOC
SQL TYPE IS CLOB_FILE CHAPFL
SQL TYPE IS BLOB (1M) VIDEO
SQL TYPE IS BLOB_LOCATOR VIDLOC
SQL TYPE IS BLOB_FILE VIDFL
CHARACTER*10 DATE
CHARACTER*8 TIME
CHARACTER*26 TIMESTAMP
INTEGER*2 WAGE_IND
Tipos de datos SQL soportados en FORTRAN
Determinados tipos de datos de FORTRAN predefinidos corresponden a tipos
de columna del gestor de bases de datos. Slo se pueden declarar como
variables del lenguaje principal estos tipos de datos de FORTRAN.
La tabla siguiente muestra el equivalente en FORTRAN de cada tipo de
columna. Cuando el precompilador encuentra una declaracin de una variable
del lenguaje principal, determina el valor del tipo de SQL apropiado. El gestor
de bases de datos utiliza este valor para convertir los datos intercambiados
entre la aplicacin y l mismo.
Tabla 16. Tipos de datos SQL correlacionados con declaraciones FORTRAN
Tipo de columna SQL
1
Tipo de datos FORTRAN Descripcin del tipo de columna SQL
SMALLINT (500 501) INTEGER*2 Entero con signo de 16 bits
INTEGER
(496 497)
INTEGER*4 Entero con signo de 32 bits
REAL
2
(480 481)
REAL*4 Coma flotante de precisin simple
DOUBLE
3
(480 481)
REAL*8 Coma flotante de precisin doble
DECIMAL(p,s)(484 485) No existe un equivalente exacto;
utilice REAL*8
Decimal empaquetado
CHAR(n)
(452 453)
CHARACTER*n Serie de caracteres de longitud fija con
longitud n, donde n va de 1 a 254
VARCHAR(n)
(448 449)
SQL TYPE IS VARCHAR(n),
donde n va de 1 a 32 672
Serie de caracteres de longitud variable
LONG VARCHAR
(456 457)
SQL TYPE IS VARCHAR(n),
donde n va de 32 673 a 32 700
Serie de caracteres de longitud variable larga
CLOB(n)
(408 409)
SQL TYPE IS CLOB (n) donde n
va de 1 a 2 147 483 647
Serie de caracteres de longitud variable y
objeto grande
4
(964 965)
SQL TYPE IS CLOB_LOCATOR Identifica las entidades CLOB que residen en
el servidor
CLOB
4
(920 921)
SQL TYPE IS CLOB_FILE Descriptor de archivo que contiene datos
CLOB
BLOB(n)
(404 405)
SQL TYPE IS BLOB (n) donde n
va de 1 a 2 147 483 647
Serie binaria de longitud variable y objeto
grande
Variable de
localizador BLOB
4
(960 961)
SQL TYPE IS BLOB_LOCATOR Identifica las entidades BLOB del servidor
archivo BLOB
4
(916 917)
SQL TYPE IS BLOB_FILE Descriptor del archivo que contiene datos
BLOB
DATE (384 385) CHARACTER*10 Serie de caracteres de 10 bytes
TIME (388 389) CHARACTER*8 Serie de caracteres de 8 bytes
TIMESTAMP (392 393) CHARACTER*26 Serie de caracteres de 26 bytes
Tabla 16. Tipos de datos SQL correlacionados con declaraciones FORTRAN (continuacin)
Tipo de columna SQL
1
Tipo de datos FORTRAN Descripcin del tipo de columna SQL
Notas:
v FLOAT
v DOUBLE PRECISION
A continuacin mostramos una norma adicional para los tipos de datos
FORTRAN soportados:
v Puede definir sentencias de SQL dinmicas que contengan ms de 254
caracteres utilizando las variables del lenguaje principal VARCHAR, LONG
VARCHAR o CLOB.
v Seccin declare de SQL con variables del lenguaje principal para
Consideraciones sobre juegos de caracteres de varios bytes en FORTRAN
En FORTRAN no se da soporte a ningn tipo de datos de variables del
lenguaje principal de grficos (de varios bytes). Slo se da soporte a variables
del lenguaje principal de tipo carcter mixtas mediante el tipo de datos
character. Es posible crear una SQLDA de usuario que contenga datos
grficos.
Consideraciones sobre EUC en japons o chino tradicional y UCS-2 para
FORTRAN
Los datos grficos enviados desde una aplicacin que se ejecuta bajo un juego
de cdigos eucJp o eucTW, o se conecta a una base de datos UCS-2, se
identifican con el identificador de la pgina de cdigos UCS-2. La aplicacin
debe convertir una serie de caracteres grficos a UCS-2 antes de enviarla al
servidor de base de datos. Del mismo modo, los datos grficos recuperados
de una base de datos UCS-2 por una aplicacin, o de cualquier base de datos
por una aplicacin que se ejecute bajo una pgina de cdigos EUC eucJP o
eucTW, se codifican utilizando UCS-2. Esto requiere que la aplicacin realice
internamente una conversin de UCS-2 a la pgina de cdigos de la
aplicacin, a menos que se vayan a presentar datos UCS-2 al usuario.
La aplicacin es responsable de convertir a UCS-2 y desde UCS-2, puesto que
esta conversin se debe llevar a cabo antes de copiar los datos al SQLDA o
desde esta. DB2 Universal Database no suministra ninguna rutina de
conversin que resulte accesible para la aplicacin. En cambio, se deben
utilizar las llamadas del sistema disponibles desde el sistema operativo. En el
caso de una base de datos UCS-2, tambin puede considerar la posibilidad de
utilizar las funciones escalares VARCHAR y VARGRAPHIC.
v Funcin escalar VARCHAR en el manual Consulta de SQL, Volumen 1
v Funcin escalar VARGRAPHIC en el manual Consulta de SQL, Volumen 1
Variables SQLSTATE y SQLCODE en FORTRAN
Cuando se utiliza la opcin de precompilacin LANGLEVEL con el valor
lenguaje principal:
CHARACTER*5 SQLSTATE
INTEGER SQLCOD
.
.
.
Si no es especifica ninguna de ellas, se supone la declaracin SQLCOD durante
el paso de precompilacin. La variable denominada SQLSTATE tambin puede
ser SQLSTA. Observe que, si se utiliza esta opcin, no se debe especificar la
sentencia INCLUDE SQLCA.
Para aplicaciones que contienen varios archivos fuente, se pueden incluir las
declaraciones de SQLCOD y SQLSTATE en cada archivo fuente, tal como se ha
mostrado anteriormente.
Parte 3. Java
Captulo 10. Programacin en Java
Java . . . . . . . . . . . . . . 284
JDBC y SQLj . . . . . . . . . . . 284
Comparacin entre SQLj y JDBC. . . . 284
Interoperatividad entre JDBC y SQLj . . 284
Sesiones compartidas entre JDBC y SQLj 285
Ventajas de Java sobre otros lenguajes . . . 285
Seguridad de SQL en Java . . . . . . . 286
Gestin de recursos de conexin en Java . . 286
Archivos fuente y de salida para Java . . . 287
Bibliotecas de clases Java . . . . . . . 288
Dnde colocar clases Java . . . . . . . 288
Actualizacin de clases Java para tiempo de
ejecucin. . . . . . . . . . . . . 289
Paquetes de Java . . . . . . . . . . 290
Variables del lenguaje principal en Java . . 290
Tipos de datos SQL soportados en Java . . 291
Componentes de habilitacin de Java . . . 292
Soporte de aplicaciones y applets . . . . 292
Soporte de aplicaciones en Java con el
Soporte de aplicaciones y applets en Java
con el controlador de tipo 4 . . . . . 293
Soporte de applets en Java mediante el
Programacin en JDBC . . . . . . . . 294
Codificacin de aplicaciones y applets
JDBC . . . . . . . . . . . . . 294
Especificacin JDBC . . . . . . . . 295
Ejemplo de un programa JDBC . . . . 296
Distribucin de aplicaciones JDBC
mediante el controlador de tipo 2 . . . 297
Distribucin y ejecucin de applets JDBC
del controlador de tipo 4 . . . . . . 297
Excepciones ocasionadas por una falta de
correspondencia de archivos db2java.zip
cuando se utiliza el controlador JDBC de
tipo 3 . . . . . . . . . . . . . 298
JDBC 2.1 . . . . . . . . . . . . 299
Restricciones de la API central de JDBC
2.1 por parte del controlador JDBC de
DB2 de tipo 2 . . . . . . . . . . 299
Restricciones de la API central JDBC 2.1
impuestas por el controlador JDBC de
DB2 de tipo 4 . . . . . . . . . . 300
Soporte de la API de paquete opcional de
JDBC 2.1 por parte del controlador de
JDBC de DB2 de tipo 2 . . . . . . . 300
Soporte de la API Paquete opcional de
JDBC 2.1 por parte del controlador JDBC
de DB2 de tipo 4 . . . . . . . . . 302
Programacin en SQLj . . . . . . . . 302
Programacin en SQLj . . . . . . . 302
Soporte de DB2 para SQLj . . . . . . 303
Restricciones de DB2 en SQLj . . . . . 304
Sentencias de SQL incorporado en Java 306
Declaraciones y comportamiento del
iterador en SQLj . . . . . . . . . 307
Ejemplo de iteradores en un programa
SQLj . . . . . . . . . . . . . 308
Llamadas a rutinas en SQLj . . . . . 309
Ejemplo de compilacin y ejecucin de un
programa SQLj. . . . . . . . . . 310
Opciones del conversor SQLj . . . . . 312
Resolucin de problemas de aplicaciones
Java . . . . . . . . . . . . . . 313
Recursos de rastreo en Java . . . . . 313
Recurso de rastreo de CLI/ODBC/JDBC 313
Archivos de rastreo de CLI y JDBC . . . 324
Valores de SQLSTATE y SQLCODE en
Java . . . . . . . . . . . . . 335
Consideraciones sobre la programacin en Java
DB2 Universal Database implanta dos API de programacin en Java basadas
en estndares: Java Database Connectivity (JDBC) y SQL incorporado para
Java (SQLj). Este captulo contiene una visin general de la programacin
JDBC y SQLj, pero se centra en los aspectos especficos de DB2. Consulte el
sitio Web de Java de DB2 Universal Database para ver enlaces con las
especificaciones JDBC y SQLj.
v Programas de ejemplo JDBC en el manual Gua de desarrollo de aplicaciones:
v Programas de ejemplo SQLJ en el manual Gua de desarrollo de aplicaciones:
JDBC y SQLj
Las secciones siguientes comparan JDBC y SQLj y describen la
interoperatividad y las sesiones compartidas entre JDBC y SQLj.
Comparacin entre SQLj y JDBC
La API JDBC le permite escribir programas Java que realizan llamadas de SQL
dinmico a bases de datos. Las aplicaciones SQLj utilizan JDBC como base
para tareas como conectar con las bases de datos y manejar errores de SQL,
pero tambin pueden contener sentencias de SQL esttico incorporado en los
archivos fuente SQLj. Debe convertir un archivo fuente SQLj con el conversor
de SQLj antes de compilar el cdigo fuente Java resultante.
Interoperatividad entre JDBC y SQLj
El lenguaje SQLj proporciona soporte directo para operaciones de SQL esttico
conocidas en el momento en que se escribe el programa. Si parte de una
determinada sentencia de SQL, o toda ella, no se puede determinar hasta el
tiempo de ejecucin, se trata de una operacin dinmica. Para realizar
operaciones de SQL dinmico desde un programa SQLj, utilice JDBC. Un
objeto ConnectionContext contiene un objeto Conexin JDBC, que se puede
utilizar para crear objetos de Sentencia de JDBC necesarios para operaciones
de SQL dinmico.
Cada clase de SQLj ConnectionContext incluye un constructor que toma como
argumento una Conexin JDBC. Este constructor se utiliza para crear una
instancia de contexto de conexin SQLj que comparte su conexin a la base de
datos subyacente con la de la conexin JDBC.
Cada instancia de SQLj ConnectionContext contiene un mtodo
getConnection() que devuelve una instancia Conexin JDBC. La Conexin
JDBC devuelta comparte la conexin a la base de datos subyacente con el
contexto de conexin SQLj. Se puede utilizar para realizar operaciones de SQL
dinmico tal como se describe en la API de JDBC.
v Sesiones compartidas entre JDBC y SQLj en la pgina 285
v Gestin de recursos de conexin en Java en la pgina 286
Sesiones compartidas entre JDBC y SQLj
Los mtodos de interoperatividad entre JDBC y SQLj proporcionan una
conversin entre las abstracciones de conexin que se utilizan en SQLj y las
que se utilizan en JDBC. Ambas abstracciones comparten la misma sesin de
base de datos, es decir, la conexin a la base de datos subyacente. Por lo
tanto, las llamadas a mtodos que afectan al estado de la sesin en un objeto
tambin se vern reflejadas en el otro objeto, puesto que es realmente la
sesin compartida subyacente la que se ve afectada.
JDBC define los valores por omisin para el estado de sesin de conexiones
recin creadas. En la mayora de los casos, SQLj adopta estos valores por
omisin. Sin embargo, mientras que una conexin JDBC recin creada tiene la
modalidad de confirmacin automtica activada por omisin, un contexto de
conexin SQLj requiere que la modalidad de confirmacin automtica se
especifique de forma explcita durante la construccin.
v Interoperatividad entre JDBC y SQLj en la pgina 284
v Gestin de recursos de conexin en Java en la pgina 286
Ventajas de Java sobre otros lenguajes
Los lenguajes de programacin que contienen SQL incorporado se denominan
lenguajes principales. Java difiere de los lenguajes principales tradicionales C,
COBOL y FORTRAN en formas que afectan significativamente al modo en
que incorpora SQL:
v SQLj y JDBC son estndares abiertos que le permiten transportar fcilmente
aplicaciones SQLj o JDBC desde otros sistemas de bases de datos
compatibles con los estndares a DB2 Universal Database.
v Todos los tipos Java que representan datos compuestos y datos de tamaos
variables tienen un valor distintivo, null, que se puede utilizar para
Captulo 10. Programacin en Java 285
representar el estado NULL de SQL, lo que ofrece a los programas Java una
alternativa a los indicadores NULL que constituyen un elemento fijo de
otros lenguajes principales.
v Java est diseado para dar soporte a programas que son portables de
forma automtica y heterognea (tambin denominados super portables o
simplemente descargables). Junto con el sistema de clases e interfaces de
tipo de Java, esta funcin habilita software de componentes. En particular,
un conversor SQLj escrito en Java puede llamar a componentes
especializados de proveedores de bases de datos para aprovechar las
funciones de bases de datos existentes como autorizacin, comprobacin de
esquema, comprobacin de tipo, funciones de transaccin y recuperacin, y
para generar cdigo optimizado para bases de datos especficas.
v Java est diseado para su portabilidad binaria en redes heterogneas, lo
que permite la portabilidad binaria para aplicaciones de bases de datos que
utilizan SQL esttico.
Seguridad de SQL en Java
Por omisin, un programa JDBC ejecuta sentencias de SQL con privilegios
asignados a la persona que ejecuta el programa. Por el contrario, un programa
SQLj ejecuta sentencias de SQL con los privilegios asignados a la persona que
ha creado el paquete de bases de datos.
Gestin de recursos de conexin en Java
Cuando se llama al mtodo close() de una instancia del contexto de
conexin, la instancia de conexin JDBC asociada y la conexin a la base de
datos subyacente se cierran. Puesto que los contextos de conexin pueden
compartir la conexin a la base de datos subyacente con otros contextos de
conexin y/o con otras conexiones JDBC, es posible que no desee cerrar la
conexin a la base de datos subyacente cuando se cierra un contexto de
conexin. Puede que un programador desee liberar los recursos que mantiene
el contexto de conexin (por ejemplo, descriptores de contexto de sentencias),
sin cerrar realmente la conexin a la base de datos subyacente. Para ello, las
clases de contexto de conexin tambin dan soporte a un mtodo close(), que
toma un argumento Booleano que indica si se debe o no cerrar la conexin a
base de datos subyacente: la constante CLOSE_CONNECTION si se debe cerrar la
conexin a base de datos y KEEP_CONNECTION si se debe mantener. La variante
de close() que no toma ningn argumento es un sistema taquigrfico para
llamar a close(CLOSE_CONNECTION).
Si una instancia de contexto de conexin no se cierra de forma explcita antes
de que se recopile como elemento desechable, el mtodo finalice de este
contexto de conexin llama a close(KEEP_CONNECTION). Esto permite que el
proceso normal de recopilacin de basura reclame recursos relacionados con la
conexin mientras se mantiene la conexin a la base de datos subyacente para
otros objetos JDBC y SQLj que la puedan estar utilizando. Observe que si
ningn otro objeto JDBC o SQLj est utilizando la conexin, la conexin a
base de datos se cierra y el proceso de recopilacin de basura la reclama.
Tanto los objetos de contexto de conexin SQLj como los objetos de conexin
JDBC responden al mtodo close(). Cuando se escribe un programa SQLj,
resulta suficiente llamar al mtodo close() slo en el objeto de contexto de
conexin; al cerrar el contexto de conexin tambin se cierra la conexin JDBC
asociada al mismo. Sin embargo, no es suficiente cerrar slo la conexin JDBC
que devuelve el mtodo getConnection() de un contexto de conexin: el
mtodo close() de una conexin JDBC no hace que se cierre el contexto de
conexin que la contiene, y por lo tanto los recursos que mantiene el contexto
de conexin no se liberan hasta que se recopilan como basura.
El mtodo isClosed() de un contexto de conexin devuelve true si se ha
llamado a cualquier variante del mtodo close() en la instancia del contexto
de conexin. Si isClosed() devuelve true, el hecho de llamar al mtodo
close() no tiene ningn efecto y el efecto de llamar a cualquier otro mtodo
es indefinido.
v Interoperatividad entre JDBC y SQLj en la pgina 284
v Sesiones compartidas entre JDBC y SQLj en la pgina 285
Archivos fuente y de salida para Java
Los archivos fuente tienen las siguientes extensiones:
.java Archivos fuente Java, que no necesitan precompilacin. Puede
compilar estos archivos con el compilador Java javac que se incluye
con el entorno de desarrollo de Java.
.sqlj Archivos fuente SQLj, que necesitan conversin con el conversor sqlj.
El conversor crea:
v Uno o ms archivos de cdigos de bytes .class
v Un archivo de perfil .ser por contexto de conexin
Los archivos de salida correspondientes tienen las siguientes extensiones:
.class Archivos compilados de cdigos de bytes JDBC y SQLj.
.ser Archivos de perfil SQLj colocados en serie. El usuario crea paquetes
en la base de datos para cada archivo de perfil con el programa de
utilidad db2profc.
Bibliotecas de clases Java
DB2 Universal Database proporciona bibliotecas de clases para el soporte de
JDBC y SQLj, que el usuario debe proporcionar en CLASSPATH o incluir en
los applets del siguiente modo:
db2jcc.jar
Proporciona el controlador JDBC Tipo 4.
db2java.zip
Proporciona el controlador JDBC y clases de soporte de JDBC y SQLj,
incluido soporte para procedimientos almacenados y UDF.
sqlj.zip
Proporciona los archivos de clases del conversor SQLj.
runtime.zip
Proporciona soporte en tiempo de ejecucin de Java para aplicaciones
y applets SQLj.
Dnde colocar clases Java
Puede utilizar archivos de clases Java individuales para procedimientos
almacenados y UDF o recopilar los archivos de clases en archivos JAR e
instalar el archivo JAR en la base de datos. Si decide utilizar archivos JAR,
consulte la descripcin sobre cmo registrar funciones y procedimientos
almacenados Java para obtener ms informacin.
Nota: si actualiza o sustituye archivos de clases de rutinas Java, debe emitir
una sentencia CALL SQLJ.REFRESH_CLASSES() para permitir que DB2
cargue las clases actualizadas. Para obtener ms informacin sobre la
sentencia CALL SQLJ.REFRESH_CLASSES(), consulte la descripcin
sobre cmo actualizar clases Java para rutinas.
Para permitir que DB2 encuentre y utilice los procedimientos almacenados y
las UDF, debe almacenar los archivos de clases correspondientes en el
directorio de funciones, que es un directorio definido para el sistema operativo
del siguiente modo:
Sistemas operativos Unix
sqllib/function
nombre_instancia\function, donde nombre_instancia representa el
valor del valor de registro especfico de la instancia DB2INSTPROF.
Por ejemplo, el directorio de funciones correspondiente a un servidor
Windows NT con DB2 instalado en el directorio C:\sqllib y sin valor
de registro DB2INSTPROF especificado es:
C:\sqllib\function
Si decide utilizar archivos de clases individuales, debe almacenar los archivos
de clases en el directorio adecuado para su sistema operativo. Si declara una
clase de modo que forme parte de un paquete Java, cree los subdirectorios
correspondientes en el directorio de funciones y coloque los archivos en el
subdirectorio correspondiente. Por ejemplo, si crea una clase ibm.tests.test1
para un sistema Linux, almacene el archivo de cdigos de bytes de Java
correspondiente (denominado test1.class) en sqllib/function/ibm/tests.
El JVM que DB2 invoca utiliza la variable de entorno CLASSPATH para
localizar archivos Java. DB2 aade el directorio de funciones y
sqllib/java/db2java.zip frente al valor CLASSPATH.
Para establecer el entorno de modo que la JVM pueda encontrar los archivos
de clases Java, es posible que tenga que definir el parmetro de configuracin
jdk_path o utilizar el valor por omisin. Adems, es posible que tenga que
definir el parmetro de configuracin java_heap_sz para aumentar el tamao
del almacenamiento dinmico correspondiente a la aplicacin.
v Actualizacin de clases Java para tiempo de ejecucin en la pgina 289
v Maximum Java Interpreter Heap Size configuration parameter -
java_heap_sz en el manual Administration Guide: Performance
v Java Development Kit Installation Path configuration parameter -
jdk_path en el manual Administration Guide: Performance
Actualizacin de clases Java para tiempo de ejecucin
Procedimiento:
Cuando actualice clases de rutinas Java, debe tambin emitir una sentencia
CALL SQLJ.REFRESH_CLASSES() para hacer que DB2 cargue las nuevas
clases. Si no emite la sentencia CALL SQLJ.REFRESH_CLASSES() despus de
actualizar las clases de rutinas Java, DB2 contina utilizando las versiones
anteriores de las clases. La sentencia CALL SQLJ.REFRESH_CLASSES() slo se
aplica a rutinas FENCED. DB2 renueva las clases cuando se produce una
operacin COMMIT o ROLLBACK.
Nota: no puede actualizar rutinas NOT FENCED sin detener y volver a
iniciar el gestor de bases de datos.
Paquetes de Java
Para utilizar las bibliotecas de clases que se incluyen con DB2 en sus propias
aplicaciones, debe incluir las sentencias import package adecuadas al principio
de los archivos fuente. Puede utilizar los siguientes paquetes en las
aplicaciones Java:
java.sql.*
La API JDBC que se incluye en JDK. Debe importar este paquete en
cada programa JDBC y SQLj.
sqlj.runtime.*
Soporte de SQLj que se incluye con cada cliente DB2. Debe importar
este paquete en cada programa SQLj.
sqlj.runtime.ref.*
Soporte de SQLj que se incluye con cada cliente DB2. Debe importar
este paquete en cada programa SQLj.
Variables del lenguaje principal en Java
Los argumentos de sentencias de SQL incorporado se pasan mediante variables
del lenguaje principal, que son variables del lenguaje principal que aparecen en
la sentencia de SQL. Las variables del lenguaje principal pueden tener un
mximo de tres partes:
v Un prefijo consistente en dos puntos, :
v Un identificador opcional de modalidad de parmetro: IN, OUT o INOUT
v Una variable del lenguaje principal Java que es un identificador de Java
correspondiente al parmetro, variable o campo
La evaluacin de un identificador de Java no tiene efectos secundarios en un
programa Java, as que puede aparecer varias veces en el cdigo Java
generado para sustituir una clusula SQLj.
La siguiente consulta contiene la variable del lenguaje principal, :x, que es la
variable, campo o parmetro x de Java visible en el mbito que contiene la
consulta:
SELECT COL1, COL2 FROM TABLE1 WHERE :x > COL3
Todas las variables del lenguaje principal especificadas en SQL compuesto son
por omisin variables del lenguaje principal de entrada. Tiene que especificar
el identificador de modalidad de parmetro OUT o INOUT antes de la
variable del lenguaje principal para marcarla como variable del lenguaje
principal de salida. Por ejemplo:
#sql {begin compound atomic static
select count(*) into :OUT count1 from employee;
end compound}
Tipos de datos SQL soportados en Java
La tabla siguiente muestra el equivalente en Java de cada tipo de datos SQL,
segn la especificacin JDBC correspondiente a correlaciones de tipos de
datos. El controlador JDBC convierte los datos que se intercambian entre la
aplicacin y la base de datos utilizando el siguiente esquema de correlacin.
Utilice estas correlaciones en sus aplicaciones Java y sus UDF y
procedimientos PARAMETER STYLE JAVA.
Nota: no hay soporte de variables del lenguaje principal para el tipo de datos
DATALINK en ninguno de los lenguajes de programacin soportados
por DB2.
Tabla 17. Tipos de datos SQL correlacionados con declaraciones Java
Tipo de columna SQL Tipo de datos Java Descripcin del tipo de columna SQL
SMALLINT (500 501) short Entero con signo de 16 bits
INTEGER
(496 497)
int Entero con signo de 32 bits
BIGINT
(492 493)
long Entero con signo de 64 bits
REAL
(480 481)
DOUBLE
(480 481)
DECIMAL(p,s)(484 485) java.math.BigDecimal Decimal empaquetado
CHAR(n)
(452 453)
java.lang.String Serie de caracteres de longitud fija con
CHAR(n)
FOR BIT DATA
byte[] Serie de caracteres de longitud fija con
VARCHAR(n)
(448 449)
java.lang.String Serie de caracteres de longitud variable
VARCHAR(n)
FOR BIT DATA
byte[] Serie de caracteres de longitud variable
LONG VARCHAR
(456 457)
java.lang.String Serie de caracteres de longitud variable
larga
Tabla 17. Tipos de datos SQL correlacionados con declaraciones Java (continuacin)
Tipo de columna SQL Tipo de datos Java Descripcin del tipo de columna SQL
LONG VARCHAR
FOR BIT DATA
byte[] Serie de caracteres de longitud variable
larga
BLOB(n)
(404 405)
java.sql.Blob Serie binaria de longitud variable y objeto
grande
CLOB(n)
(408 409)
java.sql.Clob Serie de caracteres de longitud variable y
objeto grande
DBCLOB(n)
(412 413)
java.sql.Clob Serie de caracteres de doble byte de
longitud variable y objeto grande
DATE (384 385) java.sql.Date Serie de caracteres de 10 bytes
TIME (388 389) java.sql.Time Serie de caracteres de 8 bytes
TIMESTAMP (392 393) java.sql.Timestamp Serie de caracteres de 26 bytes
Componentes de habilitacin de Java
La habilitacin de Java de DB2 tiene tres componentes independientes:
v Soporte para aplicaciones y applets cliente escritos en Java mediante JDBC
para acceder a DB2
v Soporte de precompilacin y vinculacin para aplicaciones y applets cliente
escritos en Java mediante SQLj para acceder a DB2
v Soporte para UDF y procedimientos almacenados de Java en el servidor
v Programacin en SQLj en la pgina 302
v Codificacin de aplicaciones y applets JDBC en la pgina 294
Soporte de aplicaciones y applets
Las secciones siguientes describen el soporte de aplicaciones y applets que
ofrecen los distintos controladores JDBC.
Soporte de aplicaciones en Java con el controlador de tipo 2
La siguiente figura muestra cmo funciona una aplicacin JDBC de tipo 2 con
DB2. Las llamadas a JDBC se convierten en llamadas a DB2 a travs de
mtodos nativos de Java. JDBC solicita flujo del cliente DB2 al servidor DB2.
Las aplicaciones SQLj utilizan este soporte de JDBC y adems necesitan las
clases en tiempo de ejecucin de SQLj para autentificar y ejecutar los paquetes
de SQL vinculados a la base de datos en la fase de precompilacin y
vinculacin.
Soporte de aplicaciones y applets en Java con el controlador de tipo 4
La siguiente figura muestra cmo funciona una aplicacin o applet JDBC de
DB2 de tipo 4. La aplicacin o applet de tipo 4 se comunica directamente con
la base de datos.
Soporte de applets en Java mediante el controlador de tipo 3
La siguiente figura muestra cmo funciona el controlador de applets de JDBC,
tambin denominado controlador de red, con el controlador JDBC de tipo 3. El
controlador de tipo 3 consiste en un cliente JDBC y un servidor JDBC, db2jd.
El controlador del cliente JDBC se carga en el navegador Web junto con el
Aplicacin SQLJ
Clases en tiempo
de ejecucin SQLJ
Aplicacion
Java
JDBC Cliente DB2
Base de datos
remota
Figura 4. Soporte de aplicaciones con el controlador de tipo 2
Base de datos
remota
Aplicacin
Java
Applet Java
Figura 5. Soporte de aplicaciones y applets con el controlador de tipo 4
applet. Cuando el applet solicita una conexin con una base de datos de DB2,
el cliente abre un zcalo TCP/IP para el servidor JDBC en la mquina en la
que se est ejecutando el servidor Web. Una vez configurada una conexin, el
cliente enva cada una de las siguientes peticiones de acceso a la base de datos
desde el applet hasta el servidor JDBC a travs de la conexin TCP/IP. Luego
el servidor JDBC realiza las llamadas a la CLI (ODBC) correspondiente para
realizar la tarea. Una vez finalizado el proceso, el servidor JDBC enva los
resultados al cliente a travs de la conexin.
Los applets SQLj aaden el controlador del cliente SQLj en la parte superior
del controlador del cliente JDBC, pero por lo dems funcionan igual que los
applets JDBC.
Utilice el mandato db2jstrt para iniciar el servidor JDBC de DB2.
Programacin en JDBC
Las secciones siguientes describen cmo crear aplicaciones JDBC.
Codificacin de aplicaciones y applets JDBC
Las aplicaciones y applets JDBC suelen seguir una lgica de programa similar.
Applet SQLJ
Base de datos
remota de DB2
Navegador de Web
Sistema principal
de servidor de Web
Clases en tiempo
de ejecuci n SQLJ
Applet
Java/
JDBC
Cliente
JDBC
HTTPd
Servidor JDBC
CLI
Base de datos
local de DB2
Socket
TCP/IP
HTTP
Figura 6. Implantacin de applet Java de DB2 con el controlador JDBC de tipo 3
Procedimiento:
Cuando codifique una aplicacin o applet JDBC, normalmente los codificar
de modo que lleven a cabo las siguientes tareas:
1. Importar las clases y paquetes Java adecuados (java.sql.*).
2. Cargar el controlador JDBC adecuado:
v Para JDBC de tipo 2, COM.ibm.db2.jdbc.app.DB2Driver para aplicaciones
v Para JDBC de tipo 3, COM.ibm.db2.jdbc.net.DB2Driver para applets.
Nota: se desaprueba el uso del controlador de tipo 3 en la Versin 8.
v Para JDBC de tipo 4, com.ibm.db2.jcc.DB2Driver tanto para aplicaciones
como para applets.
3. Conectar con la base de datos, especificando la ubicacin con un URL
segn lo definido en la especificacin JDBC y utilizando el subprotocolo
db2.
Los controladores de tipo 3 y 4 necesitan que proporcione el ID de
usuario, contrasea, nombre de sistema principal y nmero de puerto.
Para el controlador de tipo 3, el nmero de puerto es el nmero de puerto
del servidor de applets. Para el controlador de tipo 4, el nmero de puerto
es el nmero de puerto del servidor de DB2. El controlador de tipo 2
utiliza de forma implcita el valor por omisin para ID de usuario y
contrasea del catlogo de clientes DB2, a no ser que especifique de forma
explcita valores alternativos.
4. Pasar sentencias de SQL a la base de datos.
5. Recibir los resultados.
6. Cerrar la conexin.
Despus de codificar el programa, complelo igual que compilara cualquier
otro programa Java. No es necesario que realice ningn paso especial de
precompilacin ni de vinculacin.
v Ejemplo de un programa JDBC en la pgina 296
Especificacin JDBC
Si la aplicacin o el applet utiliza JDBC o SQLj, tiene que familiarizarse con la
especificacin JDBC, disponible de Sun Microsystems. Consulte el sitio Web
de Java de DB2 para ver enlaces a recursos JDBC y SQLj. Esta especificacin
describe cmo llamar a las API de JDBC para acceder a una base de datos y
manipular los datos de dicha base de datos.
v Componentes de habilitacin de Java en la pgina 292
v JDBC 2.1 en la pgina 299
Ejemplo de un programa JDBC
Cada programa JDBC debe realizar los pasos siguientes:
1. Importar el paquete JDBC.
Cada programa JDBC y SQLj debe importar el paquete JDBC.
2. Declarar un objeto Conexin.
El objeto Conexin establece y gestiona la conexin con la base de datos.
3. Establecer la variable URL de la base de datos.
El controlador de la aplicacin DB2 acepta URL con el siguiente formato:
jdbc:db2:nombre-basedatos
4. Conectar con la base de datos.
El mtodo DriverManager.getConnection() se suele utilizar con los
siguientes parmetros:
v getConnection(String url), que establece una conexin con la base de
datos especificada por un URL y utiliza el ID de usuario y contrasea
por omisin.
v getConnection(String url, String userid, String password), que
establece una conexin con la base de datos especificada por un URL y
utiliza el ID de usuario y contrasea especificados mediante userid y
password respectivamente.
Nota: todos los programas de ejemplo de JDBC utilizan la clase Db
definida en el programa Util.java para llevar a cabo la conexin.
Puede volver a utilizar la clase Db del programa Util.java para
conectar con una base de datos. Consulte los programas de ejemplo
de JDBC para obtener ms informacin.
El ejemplo de JDBC TutMod.java muestra algunas modificaciones bsicas en
la base de datos que incluyen sentencias INSERT, UPDATE y DELETE. Otro
ejemplo de JDBC, TbMod.java, constituye un ejemplo ms completo que
muestra cmo insertar, actualizar y suprimir datos de una tabla. Este ejemplo
muestra muchas formas posibles de modificar datos de una tabla.
Ejemplo de una sentencia INSERT
Statement stmt = con.createStatement();
stmt.executeUpdate(
"INSERT INTO staff(id, name, dept, job, salary) " +
" VALUES (380, Pearce, 38, Clerk, 13217.50), "+
" (390, Hachey, 38, Mgr, 21270.00), " +
" (400, Wagland, 38, Clerk, 14575.00) ");
stmt.close();
Ejemplo de una sentencia UPDATE
stmt.executeUpdate(
"UPDATE staff " +
" SET salary = salary + 1000 " +
" WHERE id >= 310 AND dept = 84");
stmt.close();
Ejemplo de una sentencia DELETE
stmt.executeUpdate("DELETE FROM staff " +
" WHERE id >= 310 AND salary > 20000");
stmt.close();
v TbMod.java -- How to modify table data (JDBC)
v TbMod.out -- HOW TO MODIFY TABLE DATA (JDBC)
v TutMod.java -- Modify data in a table (JDBC)
v TutMod.out -- HOW TO MODIFY DATA IN A TABLE (JDBC)
Distribucin de aplicaciones JDBC mediante el controlador de tipo 2
Distribuya sus aplicaciones JDBC como distribuira cualquier otra aplicacin
Java. Como la aplicacin utiliza el cliente DB2 para comunicarse con el
servidor DB2, no debe tomar ninguna precaucin especial sobre seguridad; la
verificacin de autorizacin la realiza el cliente DB2.
Para ejecutar la aplicacin en una mquina cliente, debe instalar en dicha
mquina:
v Una Java Virtual Machine (JVM), necesaria para ejecutar cualquier cdigo
Java
v Un cliente DB2, que tambin incluye el controlador JDBC de DB2
Para crear la aplicacin, tambin debe instalar el JDK correspondiente a su
sistema operativo.
v Creacin de aplicaciones JDBC en el manual Gua de desarrollo de
Distribucin y ejecucin de applets JDBC del controlador de tipo 4
Al igual que otros applets Java, el applet JDBC se distribuye por la red
(intranet o Internet). Normalmente, incorporara el applet en una pgina de
lenguaje de marcacin de hipertexto (HTML). Por ejemplo, para llamar al
applet de ejemplo DB2Applt.java, (que se suministra en sqllib/samples/java),
puede utilizar el siguiente cdigo <APPLET>:
<applet code="DB2Applt.class" width=325 height=275 archive="db2jcc.jar">
<param name="server" value="db_server">
<param name="port" value="50006">
</applet>
Para ejecutar el applet, slo necesita un navegador Web habilitado para Java
en la mquina cliente (es decir, no necesita instalar un cliente DB2 en la
mquina cliente). Cuando carga la pgina HTML, el cdigo del applet indica
al navegador que descargue el applet Java y la biblioteca de clases db2jcc.jar,
que incluye el controlador JDBC de DB2 que implanta la clase
com.ibm.db2.jcc.DB2Driver. Cuando el applet llama a la API JDBC para
conectar con DB2, el controlador JDBC establece comunicaciones separadas
con la base de datos DB2 a travs del servidor de applets JDBC que se ejecuta
en el servidor Web.
Nota: para asegurar que el navegador Web baja db2jcc.jar desde el servidor,
asegrese de que la variable de entorno CLASSPATH en el cliente no
incluye db2jcc.jar. Es posible que el applet no funcione correctamente si
el cliente utiliza una versin local de db2jcc.jar.
v Creacin de applets JDBC en el manual Gua de desarrollo de aplicaciones:
Excepciones ocasionadas por una falta de correspondencia de archivos
db2java.zip cuando se utiliza el controlador JDBC de tipo 3
Si utiliza el controlador JDBC de tipo 3, resulta esencial que el archivo
db2java.zip que utiliza el applet Java est al mismo nivel de FixPak que el
servidor de applets JDBC. Bajo circunstancias normales, db2java.zip se
descarga desde el servidor Web en el que se ejecuta el servidor de applets
JDBC. Esto asegura una correspondencia. Sin embargo, si la configuracin
tiene el applet Java cargando db2java.zip desde otra ubicacin, puede
producirse una discrepancia. Antes de DB2 Versin 7.1 FixPak 2, esto poda
dar lugar a errores inesperados. Desde DB2 Versin 7.1 FixPak 2, se hace
cumplir de forma estricta la correspondencia de niveles de FixPak entre los
dos archivos en el momento de la conexin. Si se detecta una discrepancia, se
rechaza la conexin y el cliente recibe una de las excepciones siguientes:
v Si db2java.zip est al nivel de DB2 Versin 7.1 FixPak 2 o posterior:
COM.ibm.db2.jdbc.DB2Exception: [IBM][Controlador JDBC]
CLI0621E Configuracin de servidor JDBC no soportada.
v Si db2java.zip es anterior a DB2 Versin 7.1 FixPak 2:
COM.ibm.db2.jdbc.DB2Exception: [IBM][Controlador JDBC]
CLI0601E Se ha cerrado la sentencia o descriptor de contexto de
sentencia no vlidos. SQLSTATE=S1000
Si se produce una discrepancia, el servidor de applets JDBC registra uno de
los siguientes mensajes en el archivo jdbcerr.log:
v Si el servidor de applets JDBC est al nivel de DB2 Versin 7.1 FixPak o
posterior:
jdbcFSQLConnect: Las versiones de servidor y cliente de applet
JDBC (db2java.zip) no coinciden. La conexin no puede proseguir.
einfo= -111
v Si el servidor de applets JDBC es anterior a DB2 Versin 7.1 FixPak 2:
jdbcServiceConnection(): Se ha recibido una peticin no vlida. einfo= 0
Nota: puesto que el controlador de tipo 4 no tiene ningn componente de
servidor JDBC, no se puede producir el tipo de discrepancia descrito
anteriormente. Se recomienda modificar las aplicaciones para que
utilicen el controlador de tipo 4.
JDBC 2.1
JDBC Versin 2.1 de Sun tiene dos partes definidas: la API central y la API de
paquete opcional. Para obtener informacin sobre la especificacin JDBC,
consulte el sitio Web de Java de DB2 Universal Database.
v Restricciones de la API central de JDBC 2.1 por parte del controlador JDBC
de DB2 de tipo 2 en la pgina 299
v Soporte de la API de paquete opcional de JDBC 2.1 por parte del
controlador de JDBC de DB2 de tipo 2 en la pgina 300
v Restricciones de la API central JDBC 2.1 impuestas por el controlador
JDBC de DB2 de tipo 4 en la pgina 300
v Soporte de la API Paquete opcional de JDBC 2.1 por parte del controlador
JDBC de DB2 de tipo 4 en la pgina 302
v Configuracin del entorno Java en el manual Gua de desarrollo de
Restricciones de la API central de JDBC 2.1 por parte del controlador
JDBC de DB2 de tipo 2
El controlador JDBC de DB2 de tipo 2 da soporte a la API central de JDBC 2.1,
aunque no da soporte a todas las funciones definidas en la especificacin. El
controlador JDBC de DB2 no da soporte a las siguientes funciones:
v Conjuntos de resultados actualizables
v Nuevos tipos de SQL (Array, Ref, Java Object, Struct)
v Correlacin personalizada de tipos de SQL
v Conjuntos de resultados sensibles desplazables (tipo de desplazamiento
ResultSet.TYPE_SCROLL_SENSITIVE)
Restricciones de la API central JDBC 2.1 impuestas por el controlador
El controlador JDBC de DB2 de tipo 4 da soporte a la API central JDBC 2.1,
aunque no da soporte a todas las funciones definidas en la especificacin. El
controlador JDBC de DB2 no da soporte a las siguientes funciones:
v Conjuntos de resultados actualizables
v Nuevos tipos de SQL (Array, Ref, Java Object, Struct)
v Correlacin personalizada de tipos de SQL
Soporte de la API de paquete opcional de JDBC 2.1 por parte del
controlador de JDBC de DB2 de tipo 2
El controlador de JDBC de DB2 de tipo 2 da soporte a las siguientes funciones
de la API de paquete opcional de JDBC 2.1:
v Java Naming and Directory Interface (JNDI) para dar nombre a bases de
datos
DB2 proporciona el siguiente soporte para la interfaz Javing Naming and
Directory Interface (JNDI) para dar nombre a bases de datos:
javax.naming.Context
Esta interfaz la implanta COM.ibm.db2.jndi.DB2Context, el cual
maneja el almacenamiento y recuperacin de objetos DataSource.
Para dar soporte a las asociaciones permanentes de nombres fuente
de datos lgicos con informacin de bases de datos fsicas, como
nombres de bases de datos, estas asociaciones se guardan en un
archivo denominado .db2.jndi. Para una aplicacin, el archivo reside
(o se crea si no existe ninguno) en el directorio especificado por la
variable de entorno USER.HOME. Para un applet, debe crear este
archivo en el directorio raz del servidor web para facilitar la
operacin de lookup(). Los applets no dan soporte a los mtodos
bind(), rebind(), unbind() ni rename() de esta clase. Slo las
aplicaciones pueden vincular objetos DataSource a JNDI.
javax.sql.DataSource
Esta interfaz la implanta COM.ibm.db2.jdbc.DB2DataSource. Puede
guardar un objeto de esta clase en cualquier implantacin de
javax.naming.Context. Esta clase tambin utiliza el soporte de
sondeo de conexin.
DB2DataSource da soporte a los siguientes mtodos:
public void setDatabaseName( String databaseName )
public void setServerName( String serverName )
public void setPortNumber( int portNumber )
javax.naming.InitialContextFactory
Esta interfaz la implanta
COM.ibm.db2.jndi.DB2InitialContextFactory, el cual crea una
instancia de DB2Context. Las aplicaciones definen automticamente
para la variable de entorno JAVA.NAMING.FACTORY.INITIAL el
valor COM.ibm.db2.jndi.DB2InitialContextFactory. Para utilizar
esta clase en un applet, llame a InitialContext() mediante la
siguiente sintaxis:
Hashtable env = new Hashtable( 5 );
env.put( "java.naming.factory.initial",
"COM.ibm.db2.jndi.DB2InitialContextFactory" );
Context ctx = new InitialContext( env );
v Sondeo de conexiones
DB2ConnectionPoolDataSource y DB2PooledConnection proporcionan los
enganches necesarios para que pueda implantar su propio mdulo de
sondeo de conexiones del siguiente modo:
javax.sql.ConnectionPoolDataSource
Esta interfaz la implanta
COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource y es una fbrica de
objetos COM.ibm.db2.jdbc.DB2PooledConnection.
javax.sql.PooledConnection
Esta interfaz la implanta COM.ibm.db2.jdbc.DB2PooledConnection.
v API de transacciones de Java (JTA)
DB2 da soporte a las API de transacciones de Java (JTA) mediante el
controlador JDBC de DB2 de tipo 2. DB2 no proporciona soporte de JTA con
los controladores de JDBC de DB2 de tipo 3 y de tipo 4.
javax.sql.XAConnection
Esta interfaz la implanta COM.ibm.db2.jdbc.DB2XAConnection.
javax.sql.XADataSource
Esta interfaz la implanta COM.ibm.db2.jdbc.DB2XADataSource y es
una fbrica de objetos COM.ibm.db2.jdbc.DB2PooledConnection.
javax.transactions.xa.XAResource
Esta interfaz la implanta COM.ibm.db2.jdbc.app.DBXAResource.
javax.transactions.xa.Xid
Esta interfaz la implanta COM.ibm.db2.jdbc.DB2Xid.
Soporte de la API Paquete opcional de JDBC 2.1 por parte del controlador
El controlador JDBC de DB2 de tipo 4 da soporte a las siguientes funciones de
la API Paquete opcional de JDBC 2.1:
v Java Naming and Directory Interface (JNDI) para dar nombre a bases de
datos
DB2 proporciona el siguiente soporte para la interfaz Javing Naming and
Directory Interface (JNDI) para dar nombre a bases de datos:
javax.sql.DataSource
Esta interfaz la implanta com.ibm.db2.jcc.DB2SimpleDataSource.
Puede guardar un objeto de esta clase en cualquier implantacin de
javax.naming.Context.
DB2SimpleDataSource da soporte a los siguientes mtodos:
public void setDatabaseName( String databaseName )
public void setServerName( String serverName )
public void setPortNumber( int portNumber )
public void setDescription( String description )
public void setLoginTimeout( int seconds )
public void setLogWriter( java.io.PrintWriter logWriter )
public void setPassword( String password )
public void setUser( String user )
public void setDriverType( int driverType )
Nota: el nico tipo soportado actualmente es el 4; la aplicacin
debe definir este tipo de forma explcita tras la
construccin de una nueva DB2SimpleDataSource.
Programacin en SQLj
Las secciones siguientes describen cmo crear aplicaciones SQLj.
Programacin en SQLj
El soporte de SQLj de DB2 se basa en el estndar ANSI de SQLj. Consulte el
sitio Web de Java de DB2 para ver un puntero al sitio Web de ANSI y a otros
recursos de SQLj. Las siguientes secciones contienen una visin general de la
programacin en SQLj e informacin especfica del soporte de SQLj de DB2.
Los siguientes tipos de construcciones SQL pueden aparecer en programas
SQLj:
v Consultas; por ejemplo, expresiones y sentencias SELECT
v Sentencias de cambio de datos (DML) de SQL; por ejemplo, INSERT,
UPDATE, DELETE
v Sentencias de datos; por ejemplo, FETCH, SELECT..INTO
v Control de Transacciones; por ejemplo, COMMIT, ROLLBACK, etc.
v Lenguaje de definicin de datos (DDL, tambin denominado Lenguaje de
manipulacin de esquemas); por ejemplo, CREATE, DROP, ALTER
v Llamadas a procedimientos almacenados; por ejemplo, CALL MYPROC(:x,
:y, :z)
v Invocaciones de funciones; por ejemplo, VALUES( MYFUN(:x) )
v Soporte de DB2 para SQLj en la pgina 303
v Restricciones de DB2 en SQLj en la pgina 304
Soporte de DB2 para SQLj
El soporte de SQLj de DB2 se proporciona mediante DB2 Application
Development Client. Junto con el soporte de JDBC que proporciona el cliente
DB2, el soporte de SQLj de DB2 le permite crear, construir y ejecutar
aplicaciones, applets, procedimientos almacenados y funciones definidas por
el usuario (UDF) de SQL incorporado para Java. Estas aplicaciones pueden
contener SQL esttico y utilizar sentencias de SQL incorporado que se
vinculan a una base de datos DB2.
El soporte de SQLj que proporciona DB2 Application Development Client
incluye:
v El conversor SQLj, sqlj, que sustituye sentencias de SQL incorporado del
programa SQLj por sentencias fuente Java y genera un perfil colocado en
serie que contiene informacin sobre las operaciones SQL encontradas en el
programa SQLj. El conversor SQLj utiliza el archivo sqllib/java/sqlj.zip.
v Las clases en tiempo de ejecucin de SQLj, disponibles en
sqllib/java/runtime.zip.
v El personalizador de perfiles de SQLj de DB2, db2profc, que precompila las
sentencias de SQL almacenadas en el perfil generado y genera un paquete
en la base de datos DB2.
v La impresora de perfiles de SQLj de DB2, db2profp, que imprime el
contenido de un perfil personalizado de DB2 en texto plano.
v El instalador de auditores de perfiles de SQLj, profdb, que instala (o
desinstala) auditores de clases de depuracin en un conjunto existente de
perfiles binarios. Una vez instalado, todas las llamadas a RTStatement y a
RTResultSet realizadas durante el tiempo de ejecucin de la aplicacin se
registran en un archivo (o salida estndar), que luego se puede consultar
para verificar el comportamiento esperado y para ver si hay errores de
rastreo. Observe que slo se auditan las llamadas realizadas a las interfaces
de llamadas RTStatement y RTResultSet subyacentes durante el tiempo de
ejecucin.
v La herramienta de conversin de perfiles de SQLj, profconv, que convierte
una instancia de perfiles colocados en secuencia a formato de cdigo de
bytes de clase. Algunos navegadores an no dan soporte a la carga de un
objeto colocado en serie desde un archivo de recursos asociado con el
applet. Como solucin temporal, tiene que ejecutar este programa de
utilidad para realizar la conversin.
Para obtener ms informacin sobre clases en tiempo de ejecucin de SQLj,
consulte el sitio Web de Java de DB2.
v Restricciones de DB2 en SQLj en la pgina 304
v db2profc - Mandato Personalizador de perfiles SQLj de DB2 en el manual
Consulta de mandatos
v db2profp - Mandato Impresora de perfiles SQLj de DB2 en el manual
Restricciones de DB2 en SQLj
Cuando cree aplicaciones DB2 con SQLj, debe tener en cuenta las siguientes
restricciones:
v El soporte de SQLj de DB2 cumple con las restricciones estndar de DB2
Universal Database sobre la emisin de sentencias de SQL.
v Una sentencia UPDATE y DELETE posicionada no es una subsentencia
vlida en una sentencia de SQL compuesto.
v La opcin de precompilacin DATETIME no recibe soporte. Slo reciben
soporte los formatos de fecha y hora de la Organizacin Internacional de
Estndares (ISO).
v La opcin de precompilacin PACKAGE USING package-name especifica
el nombre del paquete que debe generar el conversor. Si no se especifica
ningn nombre, se utiliza el nombre del perfil (menos extensin y
convertido a maysculas). La longitud mxima es de 8 caracteres. Puesto
que el nombre del perfil de SQLj tiene el sufijo _SJProfileN, donde N es el
nmero clave del perfil, el nombre del perfil siempre tendr ms de 8
caracteres. El nombre de paquete por omisin se construir concatenando
los primeros (8 - pfKeyNumLen) caracteres del nmero de perfil y el nmero
clave del perfil, donde pfKeyNumLen es la longitud del nmero clave del
perfil en el nombre del perfil. Si la longitud del nmero clave del perfil es
mayor que 7, se utilizarn los 7 ltimos dgitos sin ningn aviso. Por
ejemplo:
nombre del perfil nombre paquete por omisin
--------------------- ----------------------------
App_SJProfile1 App_SJP1
App_SJProfile123 App_S123
App_SJProfile1234567 A1234567
App_SJProfile12345678 A2345678
v Si se utiliza una variable del lenguaje principal java.math.BigDecimal, la
precisin y escala de la variable del lenguaje principal no est disponible
durante la conversin de la aplicacin. Si la precisin y escala de la variable
del lenguaje principal decimal no resultan obvias a partir del contexto de la
sentencia en la que se utiliza, la precisin y escala se pueden especificar
mediante CAST.
v No se puede utilizar una variable Java con el tipo java.math.BigInteger
como variable del lenguaje principal en una sentencia de SQL.
Algunos navegadores an no dan soporte a la carga de un objeto colocado en
serie desde un archivo de recursos asociado con el applet. Obtendr el
siguiente mensaje de error si intenta cargar el applet Applt en dichos
navegadores:
java.lang.ClassNotFoundException: Applt_SJProfile0
Como solucin temporal, existe un programa de utilidad que convierte un
perfil colocado en serie en un perfil almacenado en formato de clase Java. El
programa de utilidad es una clase Java denominada
sqlj.runtime.profile.util.SerProfileToClass. Toma un archivo de recursos
de perfiles colocados en serie como entrada y genera una clase Java que
contiene el perfil como salida. El perfil se puede convertir mediante el
siguiente mandato:
profconv Applt_SJProfile0.ser
o
java sqlj.runtime.profile.util.SerProfileToClass Applt_SJProfile0.ser
Como resultado se crea la clase Applt_SJProfile0.class. Sustituya todos los
perfiles en formato .ser que utiliza el applet por perfiles en formato .class.
Para un applet SQLj, necesita los archivos db2java.zip y runtime.zip. Si elige
no empaquetar todas las clases del applet, las clases en db2java.zip y
runtime.zip en un solo archivo Jar, coloque db2java.zip y runtime.zip
(separados por una coma) en el parmetro archive en el cdigo applet. Para
los navegadores que no dan soporte a varios archivos zip en el cdigo
archive, especifique db2java.zip en el cdigo archive y deszipee runtime.zip
con las clases del applet en un directorio de trabajo al que pueda acceder el
navegador web.
Sentencias de SQL incorporado en Java
Las sentencias de SQL esttico en SQLj aparecen en clusulas SQLj. Las
clusulas SQLj constituyen el mecanismo mediante el cual las sentencias de
SQL de programas Java se comunican con la base de datos.
El conversor SQLj reconoce clusulas SQLj y sentencias de SQL gracias a su
estructura, del siguiente modo:
v las clusulas SQLj empiezan con el smbolo #sql
v las clusulas SQLj terminan con un punto y coma
Las clusulas SQLj ms sencillas son las clusulas ejecutables y consisten en el
smbolo #sql seguido de una sentencia de SQL entre llaves. Por ejemplo, la
siguiente clusula SQLj puede aparecer en cualquier lugar en el que pueda
aparecer de forma vlida una sentencia de Java. Su objetivo es eliminar todas
las filas de la tabla denominada TAB:
#sql { DELETE FROM TAB };
En una clusula ejecutable SQLj, los smbolos que aparecen dentro de las
llaves son smbolos de SQL, excepto las variables del lenguaje principal. Todas
las variables del lenguaje principal se distinguen por el carcter de dos puntos
para que el conversor las pueda identificar. Los smbolos de SQL nunca
aparecen fuera de las llaves de una clusula ejecutable SQLj. Por ejemplo, el
siguiente mtodo Java inserta sus argumentos en una tabla de SQL. La parte
principal del mtodo cosiste en una clusula ejecutable SQLj que contiene las
variables del lenguaje principal x, y y z:
void m (int x, String y, float z) throws SQLException
{
#sql { INSERT INTO TAB1 VALUES (:x, :y, :z) };
}
No inicialice sentencias de SQL esttico en un bucle. Debe haber una sentencia
fsica para cada sentencia de SQL esttico. Por ejemplo, sustituya:
for( int i=0; i<2; i++){
#sql [ctx] itr[i] = { SELECT id, name FROM staff };
}
por lo siguiente:
int i=0;
i=1;
En general, los smbolos de SQL no son sensibles a maysculas y minsculas
(excepto los identificadores delimitados por comillas dobles) y se pueden
escribir en maysculas, en minsculas o en una combinacin de ambas. Sin
embargo, los smbolos de Java son sensibles a maysculas y minsculas. Para
que los ejemplos resulten ms claros, los smbolos de SQL que no son
sensibles a maysculas y minsculas aparecen en maysculas y los smbolos
de Java aparecen en minsculas o en una combinacin de maysculas y
minsculas. El valor null en minsculas se utiliza para representar un valor
nulo de Java y el valor NULL en maysculas se utiliza para representar un
valor nulo de SQL.
v Declaraciones y comportamiento del iterador en SQLj en la pgina 307
Declaraciones y comportamiento del iterador en SQLj
A diferencia de las sentencias de SQL que recuperan datos de una tabla, las
aplicaciones que llevan a cabo operaciones UPDATE y DELETE posicionadas
o que utilizan iteradores con los atributos holdability o returnability
necesitan dos archivos fuente Java. Declare el iterador como public en un
archivo fuente, agregando la clusula with e implements segn convenga.
Para definir el valor del atributo holdability o returnability, debe declarar
el iterador mediante la clusula with para el atributo correspondiente. El
siguiente ejemplo define para el atributo holdability el valor true para el
iterador WithHoldCurs:
#sql public iterator WithHoldCurs with (holdability=true) (String EmpNo);
Los iteradores que llevan a cabo actualizaciones posicionadas necesitan una
clusula implements que implementa la interfaz sqlj.runtime.ForUpdate. Por
ejemplo, supongamos que declara un iterador DelByName como este en
file1.sqlj:
#sql public iterator DelByName implements sqlj.runtime.ForUpdate(String EmpNo);
Luego puede utilizar el iterador convertido y compilado en otro archivo
fuente. Para utilizar el iterador:
1. Declare una instancia de la clase de iterador generada
2. Asigne la sentencia SELECT correspondiente a la operacin UPDATE o
DELETE posicionada a la instancia del iterador
3. Ejecute las sentencias UPDATE o DELETE posicionadas mediante el
iterador
Para utilizar DelByName para una sentencia DELETE posicionada en
file2.sqlj, ejecute sentencias como las del siguiente ejemplo:
{
DelByName deliter; // Declarar objeto de clase DelByName
String enum;
1 #sql deliter = { SELECT EMPNO FROM EMP WHERE WORKDEPT=D11};
while (deliter.next())
{
2 enum = deliter.EmpNo(); // Obtener valor de la tabla de resultados
3 #sql { DELETE WHERE CURRENT OF :deliter };
// Suprimir la fila en la que est posicionado el cursor
}
}
Notas:
1. Esta clusula SQLj ejecuta la sentencia SELECT, construye un objeto
iterador que contiene la tabla de resultados correspondiente a la sentencia
SELECT y asigna el objeto iterador a la variable deliter.
2. Esta sentencia coloca el iterador en la siguiente fila que hay que suprimir.
3. Esta clusula SQLj lleva a cabo la operacin DELETE posicionada.
v Ejemplo de iteradores en un programa SQLj en la pgina 308
Ejemplo de iteradores en un programa SQLj
El ejemplo de SQLj, TbRead.sqlj, utiliza SQL esttico para recuperar datos de
la tabla DEPARTMENT de la base de datos sample de DB2. Este ejemplo
muestra dos tipos de iteradores:
v Vinculacin con nombre a columnas
Este iterador declara tipos y nombres de datos de columna y devuelve los
valores de las columnas segn el nombre de columna. El siguiente ejemplo
se demuestra mediante la funcin selectUsingNamedBindingToColumns() del
ejemplo TbRead.sqlj:
#sql iterator Named_Iterator(String deptnumb, String deptname);
Named_Iterator namedIter = null;
// declarar un cursor
#sql namedIter = {SELECT deptno as deptnumb, deptname
FROM department
WHERE admrdept = A00};
// recuperar los valores de las columnas segn el nombre de columna
while (namedIter.next())
{
System.out.println( namedIter.deptnumb() + ", "+ namedIter.deptname() );
}
// cerrar el cursor
namedIter.close();
v Vinculacin posicional a columnas
Este iterador declara tipos de datos de columna y devuelve los valores de
las columnas por posicin de columna. El siguiente ejemplo se demuestra
mediante la funcin selectUsingPositionalBindingToColumns() del ejemplo
TbRead.sqlj:
#sql iterator Positioned_Iterator(String, String);
Positioned_Iterator posIter;
String deptnumb = "";
String deptname = "";
// declarar cursor
#sql posIter = {SELECT deptno as deptnumb, deptname
FROM department
WHERE admrdept = A00};
// captar el cursor
#sql {FETCH :posIter INTO :deptnumb, :deptname};
while (!posIter.endFetch())
{
System.out.println( deptnumb + ", " + deptname );
#sql {FETCH :posIter INTO :deptnumb, :deptname};
}
// cerrar el cursor
posIter.close();
v TbRead.out -- HOW TO READ TABLE DATA (SQLJ)
v TbRead.sqlj -- How to read table data (SQLj)
Llamadas a rutinas en SQLj
Las bases de datos pueden contener procedimientos, funciones definidas por el
usuario y mtodos definidos por el usuario. Los procedimientos, las funciones
definidas por el usuario y los mtodos definidos por el usuario son objetos de
esquema con nombre que se ejecutan en la base de datos. Una clusula
ejecutable SQLj que aparece en una sentencia de Java puede llamar a un
procedimiento mediante una sentencia CALL como la siguiente:
#sql { CALL SOME_PROC(:INOUT myarg) };
Los procedimientos pueden tener parmetros IN, OUT o INOUT. En el caso
anterior, el valor de la variable del lenguaje principal myarg se modifica tras la
ejecucin de esta clusula. Una clusula ejecutable SQLj puede llamar a una
funcin mediante la construccin de SQL VALUES. Por ejemplo, supongamos
que tenemos una funcin F que devuelve un entero. El siguiente ejemplo
ilustra una llamada a dicha funcin que luego asigna su resultado a la
variable local de Java x:
{
int x;
#sql x = { VALUES( F(34) ) };
}
v Referencias a funciones en el manual Gua de desarrollo de aplicaciones:
v Vas de acceso y nombres de rutina en el manual Gua de desarrollo de
aplicaciones: Programacin de aplicaciones de servidor
v Referencias a procedimientos almacenados en el manual Gua de desarrollo
de aplicaciones: Programacin de aplicaciones de servidor
v Creacin de rutinas SQLJ en el manual Gua de desarrollo de aplicaciones:
v Invocacin de procedimientos almacenados en el manual Gua de
v Invocacin de rutinas en el manual Gua de desarrollo de aplicaciones:
v Invocacin de UDF en el manual Gua de desarrollo de aplicaciones:
v Invocacin de funciones de tabla definidas por el usuario en el manual
Gua de desarrollo de aplicaciones: Programacin de aplicaciones de servidor
v Programas de ejemplo SQLJ en el manual Gua de desarrollo de aplicaciones:
Ejemplo de compilacin y ejecucin de un programa SQLj
Supongamos que tiene un programa SQLj denominado MyClass. Para ejecutar
este programa, hara lo siguiente:
1. Convertir el archivo fuente SQLj (SQL incorporado para Java),
MyClass.sqlj, con el conversor SQLj para generar el archivo fuente Java,
Myclass.java. El conversor tambin crea los perfiles
MyClass_SJProfile0.ser, MyClass_SJProfile1.ser, ... (un perfil para cada
contexto de conexin):
sqlj MyClass.sqlj
Si utiliza el conversor sqlj sin especificar un archivo sqlj.properties, el
conversor utiliza los siguientes valores:
sqlj.url=jdbc:db2:sample
sqlj.driver=COM.ibm.db2.jdbc.app.DB2Driver
sqlj.online=sqlj.semantics.JdbcChecker
sqlj.offline=sqlj.semantics.OfflineChecker
Si especifica un archivo sqlj.properties, asegrese de que estn definidas
las siguientes opciones:
sqlj.url=jdbc:db2:dbname
sqlj.driver=COM.ibm.db2.jdbc.app.DB2Driver
sqlj.online=sqlj.semantics.JdbcChecker
sqlj.offline=sqlj.semantics.OfflineChecker
donde dbname es el nombre de la base de datos. Tambin puede especificar
estas opciones en la lnea de mandatos. Por ejemplo, para especificar la
base de datos mydata al convertir MyClass, puede emitir el siguiente
mandato:
sqlj -url=jdbc:db2:mydata MyClass.sqlj
Observe que el conversor SQLj compila automticamente el cdigo fuente
convertido en archivos de clases, a no ser que desactive de forma explcita
la opcin de compilacin con la clusula -compile=false.
2. Instalar Personalizadores de SQLj de DB2 en los perfiles generados y crear
los paquetes de DB2 en la base de datos de DB2 dbname:
db2profc -user=user-name -password=user-password -url=jdbc:db2:dbname
-prepoptions="bindfile using MyClass0.bnd package using MyClass0"
MyClass_SJProfile0.ser
db2profc -user=user-name -password=user-password -url=jdbc:db2:dbname
-prepoptions="bindfile using MyClass1.bnd package using MyClass1"
...
3. Ejecutar el programa SQLj:
java MyClass
El conversor genera la sintaxis de SQL correspondiente a la base de datos
para la que est personalizado el perfil de SQLj. Por ejemplo:
i = { VALUES ( F(:x) ) };
se convierte mediante el conversor SQLj y se almacena como:
? = VALUES (F (?))
en el perfil generado. Cuando establezca conexin con una base de datos DB2
Universal Database, DB2 personalizar la sentencia VALUE como:
VALUES(F(?)) INTO ?
pero cuando establezca conexin con una base de datos DB2 Universal
Database para OS/390 y z/OS, DB2 personalizar la sentencia VALUE como:
SELECT F(?) INTO ? FROM SYSIBM.SYSDUMMY1
Si ejecuta el personalizador de perfiles de SQLj de DB2, db2profc, contra una
base de datos DB2 Universal Database y genera un archivo de vinculacin, no
puede utilizar dicho archivo de vinculacin para vincular con una base de
datos DB2 para OS/390 si hay una clusula VALUES en el archivo de
vinculacin. Esto tambin se aplica si se genera un archivo de vinculacin
contra una base de datos DB2 para OS/390 y si se intenta vincularla con una
base de datos DB2 Universal Database.
v Creacin de applets SQLJ en el manual Gua de desarrollo de aplicaciones:
v Creacin de aplicaciones SQLJ en el manual Gua de desarrollo de
v Creacin de rutinas SQLJ en el manual Gua de desarrollo de aplicaciones:
v Creacin de programas SQLJ en el manual Gua de desarrollo de
Opciones del conversor SQLj
El conversor SQLj da soporte a las mismas opciones de precompilacin que el
mandato PRECOMPILE de DB2, con las siguientes excepciones:
CONNECT
DISCONNECT
DYNAMICRULES
NOLINEMACRO
OPTLEVEL
OUTPUT
SQLCA
SQLFLAG
SQLRULES
SYNCPOINT
TARGET
WCHARTYPE
Para imprimir el contenido de los perfiles que genera el conversor SQLj en
texto plano, utilice el programa de utilidad profp del siguiente modo:
profp MyClass_SJProfile0.ser
profp MyClass_SJProfile1.ser
...
Para imprimir el contenido de la versin personalizada de DB2 del perfil en
texto plano, utilice el programa de utilidad db2profp del siguiente modo,
donde dbname es el nombre de la base de datos:
db2profp -user=user-name -password=user-password -url=jdbc:db2:dbname
db2profp -user=user-name -password=user-password -url=jdbc:db2:dbname
...
Resolucin de problemas de aplicaciones Java
Las secciones siguientes describen los recursos de rastreo disponibles para
Java y los valores de SQLSTATE y SQLCODE de Java.
Recursos de rastreo en Java
Tanto el recurso de rastreo de CLI/ODBC/JDBC como el recurso de rastreo de
DB2, db2trc, se pueden utilizar para diagnosticar problemas relacionados con
programas JDBC o SQLj.
Nota: el controlador JDBC de tipo 4 no utiliza el recurso de rastreo de
CLI/ODBC/JDBC. El rastreo correspondiente al controlador JDBC de
tipo 4 se habilita mediante el mtodo setLogWriter() en la API
javax.sql.DataSource.
Tambin puede instalar la funcin de rastreo de llamadas en tiempo de
ejecucin en programas SQLj. El programa de utilidad trabaja con los perfiles
asociados con un programa. Supongamos que un programa utiliza un perfil
denominado App_SJProfile0. Para instalar el rastreo de llamadas en el
programa, utilice el siguiente mandato:
profdb App_SJProfile0.ser
El programa de utilidad profdb utiliza Java Virtual Machine para ejecutar el
mtodo main() de clase sqlj.runtime.profile.util.AuditorInstaller. Para
obtener ms detalles sobre el uso y las opciones de la clase AuditorInstaller,
visite el sitio Web de Java de DB2.
v Archivos de rastreo de CLI y JDBC en la pgina 324
v db2trc - Mandato Rastrear en el manual Consulta de mandatos
Recurso de rastreo de CLI/ODBC/JDBC
Este tema trata los siguientes aspectos:
v Configuracin del rastreo CLI de DB2 y JDBC de DB2 en la pgina 314
v Opciones de rastreo de CLI de DB2 y el archivo db2cli.ini en la
pgina 315
v Opciones de rastreo de JDBC de DB2 y el archivo db2cli.ini en la
pgina 320
v Rastreo del controlador de CLI de DB2 frente a rastreo del Gestor de
controladores de ODBC en la pgina 322
v Rastreos del controlador de CLI de DB2, del controlador de JDBC de DB2
y de DB2 en la pgina 323
v Rastreos de CLI de DB2 y de JDBC de DB2 y procedimientos almacenados
de CLI o Java en la pgina 323
Los controladores de CLI de DB2 y DB2 JDBC proporcionan completos
recursos de rastreo. Por omisin, estos recursos estn inhabilitados y no
utilizan ningn recurso de clculo adicional. Cuando estn habilitados, los
recursos de rastreo generan uno o ms archivos de registro de texto siempre
que una aplicacin accede al controlador adecuado (CLI de DB2 o JDBC de
DB2). Estos archivos de registro proporcionan informacin detallada sobre:
v el orden en que la aplicacin ha llamado a las funciones CLI o JDBC
v el contenido de los parmetros de entrada y salida que se han pasado a las
funciones CLI o JDBC y se han recibido de las mismas
v los cdigos de retorno y los mensajes de error o de aviso generados por las
funciones CLI o JDBC
El anlisis de rastreo de CLI de DB2 y JDBC de DB2 puede ayudar a los
programadores de aplicaciones de varias formas. En primer lugar, los errores
sutiles de lgica del programa y de inicializacin de parmetros suelen ser
evidentes en los rastreos. En segundo lugar, los rastreo de CLI de DB2 y JDBC
de DB2 pueden sugerir formas de ajustar una aplicacin o las bases de datos a
las que accede. Por ejemplo, si un rastreo de CLI de DB2 muestra una tabla
que se consulta varias veces en un determinado grupo de atributos, se puede
crear un ndice correspondiente a dichos atributos en la tabla para mejorar el
rendimiento de la aplicacin. Finalmente, el anlisis de los archivos de rastreo
de CLI de DB2 y JDBC de DB2 pueden ayudar a los programadores de
aplicaciones a comprender el comportamiento de una interfaz o aplicacin de
otro proveedor.
Configuracin del rastreo CLI de DB2 y JDBC de DB2:
Los parmetros de configuracin correspondientes a los recursos de rastreo
CLI de DB2 y JDBC de DB2 se leen del archivo de configuracin de CLI de
DB2 db2cli.ini. Por omisin, este archivo se encuentra en la va de acceso
\sqllib en la plataforma Windows y en la va de acceso /sqllib/cfg en
plataformas UNIX. Puede alterar temporalmente la va de acceso por omisin
estableciendo la variable de entorno DB2CLIINIPATH. En la plataforma
Windows, es posible que se encuentre un archivo db2cli.ini adicional en el
directorio del perfil (o inicial) del usuario si hay fuentes de datos definidas
por el usuario que se han definido mediante el Gestor de controladores de
ODBC. Este archivo db2cli.ini alterar temporalmente el archivo por omisin.
Para ver los parmetros de configuracin de rastreo actuales de db2cli.ini
desde el procesador de lnea de mandatos, emita el siguiente mandato:
db2 GET CLI CFG FOR SECTION COMMON
Hay tres formas de modificar el archivo db2cli.ini para configurar los recursos
de rastreo de CLI de DB2 y de JDBC de DB2:
v utilizar el Asistente de configuracin de DB2, si est disponible
v editar de forma manual el archivo db2cli.ini mediante un editor de texto
v emitir el mandato UPDATE CLI CFG desde el procesador de lnea de
mandatos
Por ejemplo, el siguiente mandato, emitido desde el procesador de lnea de
mandatos, actualiza el archivo db2cli.ini y habilita el recurso de rastreo JDBC:
db2 UPDATE CLI CFG FOR SECTION COMMON USING jdbctrace 1
Notas:
1. Normalmente, las opciones de configuracin de rastreo CLI de DB2 y
JDBC de DB2 slo se leen desde el archivo de configuracin db2cli.ini en
el momento en que se inicializa una aplicacin. Sin embargo, se puede
utilizar una opcin de rastreo especial de db2cli.ini,
TRACEREFRESHINTERVAL, para indicar un intervalo en el que se deben
volver a leer las opciones especficas de rastreo de CLI de DB2 desde el
archivo db2cli.ini.
2. El recurso de rastreo de CLI de DB2 tambin se puede configurar de
forma dinmica estableciendo los atributos de entorno SQL_ATTR_TRACE
y SQL_ATTR_TRACEFILE. Estos valores alterarn temporalmente los
valores contenidos en el archivo db2cli.ini.
Importante: Inhabilite los recursos de rastreo de CLI de DB2 y JDBC de DB2
cuando no los necesite. El rastreo innecesario puede reducir el
rendimiento de la aplicacin y puede generar archivos de registro
de rastro no deseados. DB2 no suprime los archivos de rastreo
generados y agrega la nueva informacin de rastreo a los
archivos de rastreo existentes.
Opciones de rastreo de CLI de DB2 y el archivo db2cli.ini:
Cuando una aplicacin que utiliza el controlador de CLI de DB2 se empieza a
ejecutar, el controlador comprueba la existencia de opciones del recurso de
rastreo en la seccin [COMMON] del archivo db2cli.ini. Estas opciones de
rastreo son palabras clave de rastreo especficas que se establecen en
determinados valores en el archivo db2cli.ini bajo la seccin [COMMON].
Nota: puesto que las palabras clave de rastreo de CLI de DB2 aparecen en la
seccin [COMMON] del archivo db2cli.ini, sus valores se aplican a
todas las conexiones de bases de datos a travs del controlador de CLI
de DB2.
Las palabras clave de rastreo de CLI de DB2 que se pueden definir son:
v TRACE
v TRACEFILENAME
v TRACEPATHNAME
v TRACEFLUSH
v TRACEREFRESHINTERVAL
v TRACECOMM
v TRACETIMESTAMP
v TRACEPIDTID
v TRACEPIDLIST
v TRACETIME
v TRACESTMTONLY
Nota: las palabras clave de rastreo de CLI de DB2 slo se leen del archivo
db2cli.ini una vez, en el momento de inicializacin de la aplicacin, a
no ser que est establecida la palabra clave
TRACEREFRESHINTERVAL. Si esta palabra clave est establecida, las
palabras clave TRACE y TRACEPIDLIST se vuelven a leer del archivo
db2cli.ini en el intervalo especificado y se aplican, segn proceda, a la
aplicacin que se est ejecutando en ese momento.
TRACE = 0 | 1
La palabra clave TRACE determina si las palabras clave de rastreo de
CLI de DB2 tienen o no efecto. Si esta palabra clave no est
establecida o est establecida en el valor por omisin (0), el recurso de
rastreo de CLI de DB2 est inhabilitado. Si esta palabra clave tiene el
valor 1, el recurso de rastreo de CLI de DB2 est habilitado y se
tienen en cuenta otras palabras clave de rastreo.
Por s misma, la palabra clave TRACE tiene poco efecto (excepto para
habilitar el proceso del recurso de rastreo de CLI de DB2). No se
genera ninguna salida de rastreo a no ser que tambin se especifique
la palabra clave TRACEPATHNAME o TRACEFILENAME.
TRACEFILENAME = <nombre_archivo_rastreo_completamente_calificado>
El nombre completamente calificado del archivo de registro en el que
se graba toda la informacin de rastreo de CLI de DB2.
Si el archivo no existe, el recurso de rastreo de CLI de DB2 intentar
crearlo. Si el archivo ya existe, la nueva informacin de rastreo de la
sesin actual, si la hay, se agregar al contenido anterior de dicho
archivo.
La opcin de palabra clave TRACEFILENAME no se debe utilizar con
aplicaciones de varios procesos o de varias hebras, puesto que la
salida de rastreo correspondiente a todas las hebras o procesos se
grabar en el mismo archivo de rastreo, y la salida correspondiente a
cada hebra o proceso resultar difcil de descifrar. Adems, se utilizan
semforos para controlar el acceso al archivo de rastreo compartido, lo
que puede cambiar el comportamiento de las aplicaciones de varias
hebras. No hay ningn nombre por omisin del archivo de registro de
salida de rastreo de CLI de DB2.
TRACEPATHNAME =
<nombre_va_acceso_rastreo_completamente_calificado>
El nombre completamente calificado de la va de acceso al directorio
en el que se graba la informacin de rastreo de CLI de DB2. El recurso
de rastreo de CLI de DB2 intentar generar un nuevo archivo de
registro de rastreo cada vez que se ejecuta una aplicacin que accede a
la interfaz CLI de DB2. Si la aplicacin tiene varias hebras, se generar
un archivo de registro de rastreo independiente para cada hebra. Se
utiliza de forma automtica una concatenacin del ID del proceso de
la aplicacin y el nmero de secuencia de la hebra para nombrar los
archivos de registro de rastreo. No hay ninguna va de acceso por
omisin en la que se graban los archivos de registro de salida de
rastreo de CLI de DB2, y la va de acceso especificada debe existir en
el momento en que se ejecuta la aplicacin (el controlador de CLI de
DB2 no crear la va de acceso).
Nota: si se especifica tanto TRACEFILENAME como
TRACEPATHNAME, la palabra clave TRACEFILENAME
prevalece y TRACEPATHNAME se pasa por alto.
TRACEFLUSH = 0 | <cualquier entero positivo>
La palabra clave TRACEFLUSH especifica la frecuencia con la que la
informacin de rastreo se graba en el archivo de registro de rastreo de
CLI de DB2. Por omisin, TRACEFLUSH tiene el valor 0 y cada
archivo de registro de rastreo de CLI de DB2 se mantiene abierto
hasta que la aplicacin o hebra de la que se realiza el rastreo termina
de forma normal. Si la aplicacin termina de forma anormal, es
posible que se pierda la informacin de rastreo que no se grab en el
archivo de registro de rastreo.
Para asegurar la integridad y precisin de la informacin de rastreo
que se graba en el archivo de registro de rastreo de CLI de DB2, se
puede especificar la palabra clave TRACEFLUSH. Una vez se han
grabado n entradas de rastreo en el archivo de registro de rastreo, el
controlador de CLI de DB2 cierra el archivo y lo vuelve a abrir,
agregando las nuevas entradas de rastreo al final del archivo. Cada
operacin de cerrar y volver a abrir el archivo genera una actividad
general de entrada/salida significativa y puede reducir
considerablemente el rendimiento. Cuando menor es el valor de la palabra
clave TRACEFLUSH, mayor es el impacto del rastreo de CLI de DB2 en el
rendimiento de la aplicacin.
El valor TRACEFLUSH=1 tiene un gran impacto sobre el rendimiento,
pero asegura que cada entrada se graba en disco antes de que la
aplicacin contine con la siguiente sentencia.
TRACEREFRESHINTERVAL = 0 | <cualquier entero positivo>
Si se establece TRACEREFRESHINTERVAL en un valor n entero
positivo distinto del valor por omisin (0), el recurso de rastreo de
CLI de DB2 vuelve a leer las palabras clave TRACE y TRACEPIDLIST
del archivo db2cli.ini en el intervalo especificado (cada n segundos).
Luego el recurso de rastreo de CLI de DB2 aplica estas palabras clave,
segn convenga, al rastreo que se est ejecutando en ese momento.
El resto de las palabras clave de configuracin de rastreo de CLI de DB2
determinan qu informacin se graba en los archivos de registro de rastreo de
CLI de DB2.
TRACECOMM = 0 | 1
Si se establece TRACECOMM en el valor por omisin (0), significa
que no se incluir informacin de comunicacin cliente-servidor de
DB2 en el rastreo de CLI de DB2. Si se establece TRACECOMM en 1,
el rastreo de CLI de DB2 mostrar:
v qu funciones de CLI de DB2 se procesan por completo en el cliente
y qu funciones de CLI de DB2 implican una comunicacin con el
servidor
v el nmero de bytes enviados y recibidos en cada comunicacin con
el servidor
v el tiempo empleado en la comunicacin de datos entre el cliente y
el servidor
TRACETIMESTAMP = 0 | 1 | 2 | 3
Si se establece TRACETIMESTAMP en un valor distinto del valor por
omisin (0), significa que la indicacin horaria actual o el tiempo de
ejecucin absoluto se aade al principio de cada lnea de informacin
de rastreo a medida que se graba en el archivo de registro de rastreo
de CLI de DB2. Si se establece TRACETIMESTAMP en 1 se aade el
tiempo de ejecucin absoluto, en segundos y milisegundos, seguido
de una indicacin horaria. Si se establece TRACETIMESTAMP en 2 se
aade el tiempo de ejecucin absoluto, en segundos y milisegundos.
Si se establece TRACETIMESTAMP en 3 se aade la indicacin
horaria.
TRACEPIDTID = 0 | 1
Si se establece TRACEPIDTID en el valor por omisin (0), significa
que la informacin de ID de hebra y proceso no se aadir a cada
lnea del rastreo de CLI de DB2. Si se establece TRACEPIDTID en 1
significa que la informacin de ID de hebra y proceso se incluir en el
rastreo.
TRACEPIDLIST = <ningn valor> | <idp1,idp2, idp3,...>
Si se establece TRACEPIDLIST en su valor por omisin (ningn
valor), o si no se establece, significa que el recurso de rastreo de CLI
de DB2 realizar un rastreo de todos los procesos que acceden a la
interfaz del controlador de CLI de DB2. Si se establece
TRACEPIDLIST en una lista de uno o ms valores de ID de proceso,
delimitados por comas, se restringirn los rastreos de CLI generados a
los procesos que aparecen en dicha lista.
TRACETIME = 0 | 1
Si se establece TRACETIME en su valor por omisin (1), o si no se
establece, significa que el tiempo transcurrido entre las llamadas de
funciones de CLI y la devolucin de informacin se calcular e
incluir en el rastreo de CLI de DB2. Si se establece TRACETIME en 0
significa que el tiempo transcurrido entre llamadas de funciones de
CLI y la devolucin de la informacin no se calcular ni incluir en el
rastreo de CLI de DB2.
TRACESTMTONLY = 0 | 1
Si se establece TRACESTMTONLY en su valor por omisin (0),
significa que todas las llamadas de funciones de CLI de DB2 se
grabarn en el archivo de registro de rastreo de CLI de DB2. Si se
establece TRACESTMTONLY en 1 significa que slo al informacin
relacionada con las llamadas de las funciones SQLExecute() y
SQLExecDirect() se grabarn en el archivo de registro. Esta opcin de
rastreo puede resultar til para determinar el nmero de veces que se
ejecuta una sentencia en una aplicacin.
A continuacin se muestra un ejemplo de configuracin de rastreo del archivo
db2cli.ini en el que se utilizan estas palabras clave y valores de CLI de DB2:
[COMMON]
trace=1
TraceFileName=\temp\clitrace.txt
TRACEFLUSH=1
Notas:
1. Las palabras clave de rastreo de CLI NO son sensibles a maysculas y
minsculas. Sin embargo, puede que los valores de palabras claves
correspondientes a nombres de archivos y de vas de acceso sean sensibles
a maysculas y minsculas en algunos sistemas operativos (como en
UNIX).
2. Si la palabra clave de rastreo de CLI de DB2 o su valor asociado en el
archivo db2cli.ini no son vlidos, el recurso de rastreo de CLI de DB2 los
pasar por alto y utilizar el valor por omisin correspondiente a dicha
palabra clave de rastreo.
Opciones de rastreo de JDBC de DB2 y el archivo db2cli.ini:
Cuando una aplicacin que utiliza el controlador de JDBC de DB2 empieza a
ejecutarse, el controlador tambin comprueba la existencia de opciones de
recurso de rastreo en el archivo db2cli.ini. Al igual que sucede con las
opciones de rastreo de CLI de DB2, las opciones de rastreo de JDBC de DB2
se especifican como pares palabra clave/valor situados bajo la seccin
[COMMON] del archivo db2cli.ini.
Nota: puesto que las palabras clave de rastreo de JDBC de DB2 aparecen en
la seccin [COMMON] del archivo db2cli.ini, sus valores se aplican a
todas las conexiones de bases de datos a travs del controlador de
JDBC de DB2.
Las palabras clave de rastreo de JDBC de DB2 que se pueden definir son:
v JDBCTRACE
v JDBCTRACEPATHNAME
v JDBCTRACEFLUSH
JDBCTRACE = 0 | 1
La palabra clave JDBCTRACE controla si las otras palabras clave de
rastreo de JDBC de DB2 tienen o no efecto en la ejecucin del
programa. Si se establece JDBCTRACE en su valor por omisin (0), se
inhabilita el recurso de rastreo de JDBC de DB2; si se establece
JDBCTRACE en 1, se habilita.
Por s misma, la palabra clave JDBCTRACE tiene poco efecto y no
genera ninguna salida de rastreo a no ser que tambin se especifique
la palabra clave JDBCTRACEPATHNAME.
JDBCTRACEPATHNAME =
<nombre_va_acceso_rastreo_completamente_calificada>
El valor de JDBCTRACEPATHNAME es la va de acceso
completamente calificada al directorio en el que se graba toda la
informacin de rastreo de JDBC de DB2. El recurso de rastreo de
JDBC de DB2 intenta generar un nuevo archivo de registro de rastreo
cada vez que se ejecuta una aplicacin JDBC que utiliza el controlador
de JDBC de DB2. Si la aplicacin tiene varias hebras, se generar un
archivo de registro de rastreo independiente para cada hebra. Se
utiliza de forma automtica una concatenacin del ID del proceso de
aplicacin, el nmero de secuencia de la hebra y una serie que
identifica la hebra para nombrar los archivos de registro de rastreo.
No hay ningn nombre de va de acceso por omisin en el que se
graben los archivos de registro de salida de rastreo de JDBC de DB2.
JDBCTRACEFLUSH = 0 | 1
La palabra clave JDBCTRACEFLUSH especifica la frecuencia con la
que la informacin de rastreo se graba en el archivo de registro de
rastreo de JDBC de DB2. Por omisin, JDBCTRACEFLUSH tiene el
valor 0 y cada archivo de registro de rastreo de JDBC de DB2 se
mantiene abierto hasta que la aplicacin o hebra de la que se realiza el
rastreo termina de forma normal. Si la aplicacin termina de forma
anormal, es posible que se pierda la informacin de rastreo que no se
grab en el archivo de registro de rastreo.
Para asegurar la integridad y precisin de la informacin de rastreo
que se graba en el archivo de registro de rastreo de JDBC de DB2, la
palabra clave JDBCTRACEFLUSH se puede establecer en 1. Despus
de que cada entrada de rastreo se haya grabado en el archivo de
registro de rastreo, el controlador de JDBC de DB2 cierra el archivo y
lo vuelve a abrir, aadiendo las nuevas entradas de rastreo al final del
archivo. Esto garantiza que no se pierde informacin de rastreo.
Nota: cada operacin de cerrar y volver a abrir el archivo de registro de
JDBC de DB2 genera una actividad general de entrada/salida
significativa y puede reducir considerablemente el rendimiento de la
aplicacin.
A continuacin se muestra un ejemplo de configuracin de rastreo del archivo
db2cli.ini en el que se utilizan las palabras clave y valores de JDBC de DB2:
[COMMON]
jdbctrace=1
JdbcTracePathName=\temp\jdbctrace\
JDBCTRACEFLUSH=1
Notas:
1. Las palabras clave de rastreo de JDBC NO son sensibles a maysculas y
minsculas. Sin embargo, puede que los valores de palabras claves
correspondientes a nombres de archivos y de vas de acceso sean sensibles
a maysculas y minsculas en algunos sistemas operativos (como en
UNIX).
2. Si una palabra clave de rastreo de JDBC de DB2 o su valor asociado en el
archivo db2cli.ini no son vlidos, el recurso de rastreo de JDBC de DB2 los
pasa por alto y utiliza el valor por omisin correspondiente a esa palabra
clave.
3. Al habilitar el rastreo de JDBC de DB2 no se habilita el rastreo de CLI de
DB2. Algunas versiones del controlador de JDBC de DB2 dependen del
controlador de CLI de DB2 para acceder a la base de datos. Por lo tanto,
puede que los programadores de Java tambin deseen habilitar el rastreo
de CLI de DB2 para obtener informacin adicional sobre cmo las
aplicaciones interactan con la base de datos a travs de las distintas capas
de software. Las opciones de rastreo de JDBC de DB2 y de CLI de DB2
son independientes entre s y se pueden especificar juntas en cualquier
orden bajo la seccin [COMMON] del archivo db2cli.ini.
Rastreo del controlador de CLI de DB2 frente a rastreo del Gestor de
controladores de ODBC:
Es importante comprender las diferencias entre un rastreo del gestor de
controladores de ODBC y un rastreo del controlador de CLI de DB2. Un
rastreo del gestor de controladores de ODBC muestra las llamadas de
funciones de ODBC realizadas por una aplicacin ODBC a un gestor de
controladores de ODBC. Por el contrario, un rastreo del controlador de CLI de
DB2 muestra las llamadas de funciones realizadas por el gestor de
controladores de ODBC al controlador de CLI de DB2 en nombre de la
aplicacin.
Un gestor de controladores de ODBC puede reenviar algunas llamadas de
funciones directamente desde la aplicacin al controlador de CLI de DB2. Sin
embargo, el gestor de controladores de ODBC puede tambin retrasar o evitar
el reenvo de algunas llamadas de funciones al controlador. El gestor de
controladores de ODBC tambin puede modificar los argumentos de
funciones de la aplicacin o correlacionar funciones de la aplicacin con otras
funciones antes de reenviar la llamada al controlador de CLI de DB2.
Las razones para la intervencin de llamadas de funciones de aplicacin por
parte del gestor de controladores de ODBC incluyen:
v Para las aplicaciones escritas con funciones de ODBC 2.0 que ya no se
recomiendan en ODBC 3.0, las funciones antiguas se correlacionarn con
funciones nuevas.
v Los argumentos de funciones de ODBC 2.0 que ya no se recomiendan en
ODBC 3.0 se correlacionarn con argumentos equivalentes de ODBC 3.0.
v La biblioteca de cursores de Microsoft correlacionar llamadas como
SQLExtendedFetch() con varias llamadas a SQLFetch() y a otras funciones
soportadas para conseguir el mismo resultado final.
v La agrupacin de conexiones del gestor de controladores de ODBC
generalmente diferir las peticiones SQLDisconnect() (o las evitar si la
conexin se reutiliza).
Por esta y por otras razones, puede que los programadores de aplicaciones
consideren el rastreo del gestor de controladores de ODBC un complemento
til al rastreo del controlador de CLI de DB2.
Para obtener ms informacin sobre cmo capturar e interpretar rastreo del
gestor de controladores de ODBC, consulte la documentacin del gestor de
controladores de ODBC. En las plataformas Windows, consulte el manual
Microsoft ODBC 3.0 Software Development Kit and Programmers Reference,
tambin disponible en lnea en: http://www.msdn.microsoft.com/.
Rastreos del controlador de CLI de DB2, del controlador de JDBC de DB2 y
de DB2:
Internamente, algunas versiones del controlador de JDBC de DB2 utilizan el
controlador de CLI de DB2 para el acceso a bases de datos. Por ejemplo, es
posible que el controlador de JDBC de DB2 correlacione internamente el
mtodo getConnection() de Java con la funcin SQLConnect() de CLI de DB2.
Como resultado, puede que los programadores de Java consideren el rastreo
de CLI de DB2 un complemento til al rastreo de JDBC de DB2.
El controlador de CLI de DB2 utiliza muchas funciones internas y especficas
de DB2 para realizar su trabajo. Estas llamadas de funciones internas y
especficas de DB2 se registran en el rastreo de DB2. Los programadores de
aplicaciones no encontrarn tiles los rastreos de DB2, puesto que slo estn
diseados para ayudar al Servicio de IBM en la determinacin y resolucin de
problemas.
Rastreos de CLI de DB2 y de JDBC de DB2 y procedimientos almacenados
de CLI o Java:
En todas las plataformas de estacin de trabajo, se pueden utilizar los recursos
de rastreo de CLI de DB2 y de JDBC de DB2 para realizar el rastreo de
procedimientos almacenados de CLI de DB2 y de JDBC de DB2.
La mayor parte de la informacin y las instrucciones sobre rastreo de CLI de
DB2 y de JDBC de DB2 proporcionada en anteriores secciones es genrica y se
aplica por igual a aplicaciones y a procedimientos almacenados. Sin embargo,
a diferencia de las aplicaciones, que son clientes de un servidor de base de
datos (y generalmente se ejecutan en una mquina distinta de la del servidor
de base de datos), los procedimientos almacenados se ejecutan en el servidor
de base de datos. Por lo tanto, debe seguir los siguientes pasos adicionales
cuando efecte un rastreo de procedimientos almacenados de CLI de DB2 o
de JDBC de DB2:
v Asegrese de que las opciones de palabras clave de rastreo estn
especificadas en el archivo db2cli.ini del servidor DB2.
v Si la palabra clave TRACEREFRESHINTERVAL no tiene un valor positivo
distinto de cero, asegrese de que todas las palabras clave estn
correctamente configuradas antes del momento del arranque de la base de
datos (es decir, cuando se emita el mandato db2start). Si se cambian los
valores de rastreo mientras se est ejecutando el servidor de base de datos
se pueden producir resultados inesperados. Por ejemplo, si se cambia el
valor de TRACEPATHNAME mientras se est ejecutando el servidor, la
prxima vez que se ejecute un procedimiento almacenado es posible que
algunos archivos de rastreo se graben en la nueva va de acceso mientras
otros se graben en la va de acceso original. Para asegurar la coherencia,
vuelva a iniciar el servidor cada vez que se modifique una palabra clave de
rastreo que no sea TRACE o TRACEPIDLIST.
v db2cli.ini Initialization File en el manual CLI Guide and Reference, Volume 1
v Archivos de rastreo de CLI y JDBC en la pgina 324
v SQLSetEnvAttr Function (CLI) - Set Environment Attribute en el manual
v Mandato GET CLI CONFIGURATION en el manual Consulta de mandatos
v Mandato UPDATE CLI CONFIGURATION en el manual Consulta de
mandatos
v Miscellaneous variables en el manual Administration Guide: Performance
v CLI/ODBC Configuration Keywords Listing by Category en el manual
Archivos de rastreo de CLI y JDBC
Las aplicaciones que acceden a controladores de CLI de DB2 o JDBC de DB2
pueden utilizar los recursos de rastreo de CLI de DB2 o JDBC de DB2. Estos
programas de utilidad registran todas las llamadas de funciones realizadas
por los controladores de CLI de DB2 o JDBC de DB2 en un archivo de registro
que resulta til en la determinacin de problemas. Este tema describe cmo
acceder a estos archivos de registro que generan los recursos de rastreo y
cmo interpretarlos:
v Ubicacin del archivo de rastreo de CLI y JDBC en la pgina 325
v Interpretacin del archivo de rastreo de CLI en la pgina 326
v Interpretacin del archivo de rastreo de JDBC en la pgina 332
Ubicacin del archivo de rastreo de CLI y JDBC:
Si se ha utilizado la palabra clave TRACEFILENAME en el archivo db2cli.ini
para especificar un nombre de archivo completamente calificado, el archivo de
registro de rastreo de CLI de DB2 estar en la ubicacin especificada. Si se ha
especificado un nombre de archivo relativo para el archivo de registro de
rastreo de CLI de DB2, la ubicacin de dicho archivo depender de lo que el
sistema operativo considere que es la va de acceso actual de la aplicacin.
Nota: si el usuario que ejecuta la aplicacin no tiene suficiente autoridad para
grabar en el archivo de registro de rastreo de la va de acceso
especificada, no se generar ningn archivo ni se proporcionar ningn
aviso ni error.
Si se ha utilizado la palabra clave TRACEPATHNAME o
JDBCTRACEPATHNAME, o ambas, en el archivo db2cli.ini para especificar
directorios completamente calificados, los archivos de registro de rastreo de
CLI de DB2 y JDBC de DB2 estarn en la ubicacin especificada. Si se ha
especificado un nombre de directorio relativo para cualquiera de estos
directorios de rastreo, o para ambos, el sistema operativo determinar su
ubicacin segn lo que considere que es la va de acceso actual de la
aplicacin.
Nota: si el usuario que ejecuta la aplicacin no tiene suficiente autoridad para
grabar archivos de rastreo en la va de acceso especificada, no se
generar ningn archivo ni se proporcionar ningn aviso ni error. Si la
va de acceso de rastreo especificada no existe, no se crear.
Los recursos de rastreo de CLI de DB2 y JDBC de DB2 utilizan de forma
automtica el ID de proceso y el nmero de secuencia de la hebra para
nombrar los archivos de registro de rastreo cuando se han establecido las
palabras clave TRACEPATHNAME y JDBCTRACEPATHNAME. Por ejemplo,
un rastreo de CLI de DB2 de una aplicacin con tres hebras puede generar los
siguientes archivos de registro de rastreo de CLI de DB2: 100390.0, 100390.1,
100390.2.
De forma similar, un rastreo de JDBC de DB2 de una aplicacin Java con dos
hebras puede generar los siguientes archivos de registro de rastreo de JDBC:
7960main.trc, 7960Thread-1.trc.
Nota: Si el directorio de rastreo contiene archivos de registro de rastreo
antiguos y nuevos, se puede utilizar la informacin de indicacin
horaria y fecha de los archivos para localizar los archivos de rastreo
ms recientes.
Si parece que no se ha creado ningn archivo de salida de rastreo de CLI de
DB2 o JDBC de DB2:
v Compruebe que las palabras clave de configuracin de rastreo estn
correctamente establecidas en el archivo db2cli.ini. Una forma rpida de
hacerlo consiste en emitir el mandato db2 GET CLI CFG FOR SECTION COMMON
desde el procesador de lnea de mandatos.
v Asegrese de que la aplicacin se vuelve a iniciar despus de actualizar el
archivo db2cli.ini. En concreto, los recursos de rastreo de CLI de DB2 y
JDBC de DB2 se vuelven a inicializar durante el arranque de la aplicacin.
Una vez inicializado, el recurso de rastreo de JDBC de DB2 no se puede
volver a configurar. El recurso de rastreo de CLI de DB2 se puede volver a
configurar en el tiempo de ejecucin, pero slo si se ha especificado la
palabra clave TRACEREFRESHINTERVAL correctamente antes del arranque
de la aplicacin.
Nota: Slo las palabras clave de CLI de DB2 TRACE y TRACEPIDLIST se
pueden volver a ejecutar en el tiempo de ejecucin. Los cambios
realizados en otras palabras clave de CLI de DB2, incluida
TRACEREFRESHINTERVAL, no tienen efecto si no se vuelve a iniciar la
aplicacin.
v Si la palabra clave TRACEREFRESHINTERVAL se ha especificado antes del
arranque de la aplicacin y la palabra clave TRACE se ha establecido
inicialmente en 0, asegrese de que ha transcurrido suficiente tiempo para
que el recurso de rastreo de CLI de DB2 haya podido volver a leer el valor
de la palabra clave TRACE.
v Si se utiliza la palabra clave TRACEPATHNAME o
JDBCTRACEPATHNAME, o ambas, para especificar directorios de rastreo,
asegrese de que dichos directorios existen antes de iniciar la aplicacin.
v Asegrese de que la aplicacin tiene acceso de grabacin en el archivo de
registro de rastreo o en el directorio de rastreo especificados.
v Compruebe la variable de entorno DB2CLIINIPATH. Si est establecida, los
recursos de rastreo de CLI de DB2 y JDBC de DB2 esperan que el archivo
db2cli.ini est en la ubicacin especificada por esta variable.
v Si la aplicacin utiliza ODBC como interfaz con el controlador de CLI de
DB2, compruebe que se ha llamado satisfactoriamente a una de estas
funciones: SQLConnect(), SQLDriverConnect() o SQLBrowseConnect(). No se
grabar ninguna entrada en los archivos de registro de rastreo de CLI de
DB2 hasta que se haya establecido satisfactoriamente una conexin con la
base de datos.
Interpretacin del archivo de rastreo de CLI:
Los rastreos de CLI de DB2 siempre empiezan con una cabecera que identifica
el ID de proceso y el ID de hebra de la aplicacin que ha generado el rastreo,
la hora en que ha comenzado el rastreo e informacin especfica del producto,
como el nivel de build de DB2 y la versin del controlador de CLI de DB2.
Por ejemplo:
1 [ Process: 1227, Thread: 1024 ]
2 [ Date, Time: 01-27-2002 13:46:07.535211 ]
3 [ Product: QDB2/LINUX 7.1.0 ]
4 [ Level Identifier: 02010105 ]
5 [ CLI Driver Version: 07.01.0000 ]
6 [ Informational Tokens: "DB2 v7.1.0","n000510","" ]
Nota: en los ejemplos de rastreo que se muestran en esta seccin se han
aadido nmeros de lnea a la izquierda del rastreo. Estos nmeros de
lnea se han aadido para clarificar la explicacin y no aparecen en el
rastreo de CLI de DB2 real.
Inmediatamente despus de la cabecera del rastreo, suele haber varias
entradas de rastreo relacionadas con el entorno y la asignacin e inicializacin
del descriptor de contexto de la conexin. Por ejemplo:
7 SQLAllocEnv( phEnv=&bffff684 )
8 > Time elapsed - +9.200000E-004 seconds
9 SQLAllocEnv( phEnv=0:1 )
10 < SQL_SUCCESS Time elapsed - +7.500000E-004 seconds
11 SQLAllocConnect( hEnv=0:1, phDbc=&bffff680 )
13 SQLAllocConnect( phDbc=0:1 )
15 SQLSetConnectOption( hDbc=0:1, fOption=SQL_ATTR_AUTOCOMMIT, vParam=0 )
17 SQLSetConnectOption( )
19 SQLConnect( hDbc=0:1, szDSN="SAMPLE", cbDSN=-3, szUID="", cbUID=-3,
szAuthStr="", cbAuthStr=-3 )
21 ( DBMS NAME="DB2/LINUX", Version="07.01.0000", Fixpack="0x22010105" )
22 SQLConnect( )
24 ( DSN=""SAMPLE"" )
25 ( UID=" " )
26 ( PWD="*" )
En el ejemplo de rastreo anterior, observe que hay dos entradas para cada
llamada de funcin de CLI de DB2 (por ejemplo, lneas 19-21 y 22-26 para la
llamada de funcin SQLConnect()). Esto siempre es as en los rastreos de CLI
de DB2. La primera entrada muestra los valores de los parmetros de entrada
que se han pasado a la llamada de funcin, mientras que la segunda entrada
muestra los valores de parmetros de salida de funcin y el cdigo de retorno
que se ha devuelto a la aplicacin.
El ejemplo de rastreo anterior muestra que la funcin SQLAllocEnv() ha
asignado satisfactoriamente un descriptor de contexto de entorno ( phEnv=0:1
) en la lnea 9. Este descriptor de contexto se ha pasado a la funcin
SQLAllocConnect(), la cual ha asignado satisfactoriamente un descriptor de
contexto de conexin de base de datos ( phDbc=0:1 ) en la lnea 13. Luego, se
ha utilizado la funcin SQLSetConnectOption() para establecer el atributo
SQL_ATTR_AUTOCOMMIT de la conexin de phDbc=0:1 en
SQL_AUTOCOMMIT_OFF ( vParam=0 ) en la lnea 15. Finalmente, se ha
llamado a la funcin SQLConnect() para conectar con la base de datos de
destino ( SAMPLE ) en la lnea 19.
En la entrada de rastreo de entrada de la funcin SQLConnect(), en la lnea 21,
se incluye el nivel de build y de FixPak del servidor de la base de datos de
destino. Otra informacin que tambin puede aparecen en esta entrada de
rastreo incluye palabras claves de la serie de conexin de entrada y las
pginas de cdigos del cliente y del servidor. Por ejemplo, supongamos que
tambin apareciera la siguiente informacin en la entrada de rastreo de
SQLConnect():
( Application Codepage=819, Database Codepage=819,
Char Send/Recv Codepage=819, Graphic Send/Recv Codepage=819,
Application Char Codepage=819, Application Graphic Codepage=819 )
Esto significara que la aplicacin y el servidor de base de datos estaran
utilizando la misma pgina de cdigos ( 819 ).
La entrada de rastreo de retorno de la funcin SQLConnect() tambin contiene
informacin de conexin importante (lneas 24-26 en el rastreo de ejemplo
anterior). Informacin adicional que puede aparecer en la entrada de retorno
incluye los valores de la palabra clave PATCH1 o PATCH2 que se aplican a la
conexin. Por ejemplo, si se hubiera especificado PATCH2=27,28 en el archivo
db2cli.ini bajo la seccin COMMON, tambin aparecera la siguiente lnea en
la entrada de retorno de SQLConnect():
( PATCH2="27,28" )
Despus de las entradas de rastreo relacionadas con el entorno y con la
conexin se encuentran las entradas de rastreo relacionadas con sentencias.
Por ejemplo:
27 SQLAllocStmt( hDbc=0:1, phStmt=&bffff684 )
29 SQLAllocStmt( phStmt=1:1 )
31 SQLExecDirect( hStmt=1:1, pszSqlStr="CREATE TABLE GREETING (MSG
VARCHAR(10))", cbSqlStr=-3 )
33 ( StmtOut="CREATE TABLE GREETING (MSG VARCHAR(10))" )
34 SQLExecDirect( )
En el ejemplo de rastreo anterior, se ha utilizado el descriptor de contexto de
la conexin de base de datos ( phDbc=0:1 ) para asignar un descriptor de
contexto de sentencia ( phStmt=1:1 ) en la lnea 29. Luego se ha ejecutado una
sentencia de SQL no preparada en dicho descriptor de contexto de sentencia
en la lnea 31. Si se hubiera establecido la palabra clave TRACECOMM=1 en
el archivo db2cli.ini, las entradas de rastreo de llamada de la funcin
SQLExecDirect() mostraran informacin adicional de comunicacin
cliente-servidor como la siguiente:
SQLExecDirect( hStmt=1:1, pszSqlStr="CREATE TABLE GREETING (MSG
VARCHAR(10))", cbSqlStr=-3 )
> Time elapsed - +2.876000E-003 seconds
( StmtOut="CREATE TABLE GREETING (MSG VARCHAR(10))" )
sqlccsend( ulBytes - 232 )
sqlccsend( Handle - 1084869448 )
sqlccsend( ) - rc - 0, time elapsed - +1.150000E-004
sqlccrecv( )
sqlccrecv( ulBytes - 163 ) - rc - 0, time elapsed - +2.243800E-002
SQLExecDirect( )
< SQL_SUCCESS Time elapsed - +2.384900E-002 seconds
Observe la informacin adicional de llamada de funciones sqlccsend() y
sqlccrecv() de esta entrada de rastreo. La informacin de la llamada
sqlccsend() revela la cantidad de datos que se han enviado del cliente al
servidor, cunto ha durado la transmisin y el xito de dicha transmisin ( 0
= SQL_SUCCESS ). Luego la informacin de la llamada sqlccrecv() revela el
tiempo que el cliente ha esperado una respuesta del servidor y la cantidad de
datos incluidos en la respuesta.
A menudo aparecern varios descriptores de contexto de sentencias en el
rastreo de CLI de DB2. Si presta atencin al identificador del descriptor de
contexto de la sentencia, puede seguir fcilmente el mtodo de ejecucin de
un descriptor de contexto de sentencia de forma independiente de los dems
descriptores de contexto de sentencia que aparecen en el rastreo.
Los mtodos de ejecucin de sentencias que aparecen en el rastreo de CLI de
DB2 suelen ser ms complicados que el del ejemplo anterior. Por ejemplo:
36 SQLAllocStmt( hDbc=0:1, phStmt=&bffff684 )
38 SQLAllocStmt( phStmt=1:2 )
40 SQLPrepare( hStmt=1:2, pszSqlStr="INSERT INTO GREETING VALUES ( ? )",
cbSqlStr=-3 )
42 ( StmtOut="INSERT INTO GREETING VALUES ( ? )" )
43 SQLPrepare( )
45 SQLBindParameter( hStmt=1:2, iPar=1, fParamType=SQL_PARAM_INPUT,
fCType=SQL_C_CHAR, fSQLType=SQL_CHAR, cbColDef=14,
ibScale=0, rgbValue=&080eca70, cbValueMax=15,
pcbValue=&080eca4c )
47 SQLBindParameter( )
49 SQLExecute( hStmt=1:2 )
51 ( iPar=1, fCType=SQL_C_CHAR, rgbValue="Hello World!!!", pcbValue=14,
piIndicatorPtr=14 )
52 SQLExecute( )
53 < SQL_ERROR Time elapsed - +5.951000E-003 seconds
En el ejemplo de rastreo anterior, se ha utilizado el descriptor de contexto de
conexin de base de datos ( phDbc=0:1 ) para asignar un segundo descriptor
de contexto de sentencia ( phStmt=1:2 ) en la lnea 38. Luego se ha preparado
una sentencia de SQL con un marcador de parmetro en dicho descriptor de
contexto de sentencia en la lnea 40. Luego, se ha vinculado un parmetro de
entrada ( iPar=1 ) del tipo de SQL adecuado ( SQL_CHAR ) con el marcador
de parmetro en la lnea 45. Finalmente, se ha ejecutado la sentencia en la
lnea 49. Observe que tanto el contenido como la longitud del parmetro de
entrada ( rgbValue=Hello World!!!, pcbValue=14 ) se muestran en el rastreo
en la lnea 51.
La funcin SQLExecute() falla en la lnea 52. Si la aplicacin llama a una
funcin de CLI de DB2 de diagnstico, como SQLError(), para diagnosticar la
causa del error, dicha causa aparecer en el rastreo. Por ejemplo:
54 SQLError( hEnv=0:1, hDbc=0:1, hStmt=1:2, pszSqlState=&bffff680,
pfNativeError=&bfffee78, pszErrorMsg=&bffff280,
cbErrorMsgMax=1024, pcbErrorMsg=&bfffee76 )
56 SQLError( pszSqlState="22001", pfNativeError=-302, pszErrorMsg="[IBM][CLI
Driver][DB2/LINUX] SQL0302N El valor de una variable del lenguaje
principal de la sentencia EXECUTE u OPEN es demasiado alto para su
uso correspondiente.
SQLSTATE=22001", pcbErrorMsg=157 )
El mensaje de error que se devuelve en la lnea 56 contiene el cdigo de error
nativo de DB2 que se ha generado ( SQL0302N ), el sqlstate correspondiente a
dicho cdigo ( SQLSTATE=22001 ) y una breve descripcin del error. En este
ejemplo, el origen del error es evidente: en la lnea 49, la aplicacin intenta
insertar una serie de 14 caracteres en una columna definida como
VARCHAR(10) en la lnea 31.
Si la aplicacin no responde a un cdigo de retorno de error o de aviso de
una funcin de CLI de DB2 llamando a una funcin de diagnstico como
SQLError(), el mensaje de aviso o de error se tiene que grabar igualmente en
el rastreo de CLI de DB2. Sin embargo, es posible que la ubicacin de dicho
mensaje en el rastreo no est cerca de donde se ha producido realmente el
error. Adems, el rastreo indicar que la aplicacin no ha recuperado el
mensaje de error o de aviso. Por ejemplo, si no se recupera, es posible que el
mensaje de error del ejemplo anterior no aparezca hasta ms adelante y
parezca que no est relacionado con la llamada de funcin de CLI de DB2,
como en el siguiente caso:
SQLDisconnect( hDbc=0:1 )
> Time elapsed - +1.501000E-003 seconds
sqlccsend( ulBytes - 72 )
sqlccsend( Handle - 1084869448 )
sqlccsend( ) - rc - 0, time elapsed - +1.080000E-004
sqlccrecv( )
sqlccrecv( ulBytes - 27 ) - rc - 0, time elapsed - +1.717950E-001
( Unretrieved error message="SQL0302N El valor de una variable del lenguaje principal
en la sentencia EXECUTE u OPEN es demasiado alto para su uso correspondiente.
SQLSTATE=22001" )
SQLDisconnect( )
La parte final de un rastreo de CLI de DB2 debe mostrar que la aplicacin
libera la conexin de base de datos y los descriptores de contexto de entorno
que haba asignado anteriormente en el rastreo. Por ejemplo:
58 SQLTransact( hEnv=0:1, hDbc=0:1, fType=SQL_ROLLBACK )
60 ( ROLLBACK=0 )
61 SQLTransact( )
62 SQLDisconnect( hDbc=0:1 )
64 SQLDisconnect( )
66 SQLFreeConnect( hDbc=0:1 )
68 SQLFreeConnect( )
70 SQLFreeEnv( hEnv=0:1 )
72 SQLFreeEnv( )
Interpretacin del archivo de rastreo de JDBC:
Los rastreos de JDBC de DB2 siempre comienzan con una cabecera que
contiene informacin importante del sistema, como valores de variables clave
de entorno, el nivel de JDK o JRE, el nivel del controlador de JDBC de DB2 y
el nivel del build de DB2. Por ejemplo:
1 ========================================================
2 | Trace beginning on 2002-1-28 7:21:0.19
3 ========================================================
4 System Properties:
5 ------------------
6 user.language = en
7 java.home = c:\Program Files\SQLLIB\java\jdk\bin\..
8 java.vendor.url.bug =
9 awt.toolkit = sun.awt.windows.WToolkit
10 file.encoding.pkg = sun.io
11 java.version = 1.1.8
12 file.separator = \
13 line.separator =
14 user.region = US
15 file.encoding = Cp1252
16 java.compiler = ibmjitc
17 java.vendor = IBM Corporation
18 user.timezone = EST
19 user.name = db2user
20 os.arch = x86
21 java.fullversion = JDK 1.1.8 IBM build n118p-19991124 (JIT ibmjitc
V3.5-IBMJDK1.1-19991124)
22 os.name = Windows NT
23 java.vendor.url = http://www.ibm.com/
24 user.dir = c:\Program Files\SQLLIB\samples\java
25 java.class.path =
.:C:\Program Files\SQLLIB\lib;C:\Program Files\SQLLIB\java;
C:\Program Files\SQLLIB\java\jdk\bin\
26 java.class.version = 45.3
27 os.version = 5.0
28 path.separator = ;
29 user.home = C:\home\db2user
30 ----------------------------------------
Nota: en los ejemplos de rastreo que se muestran en esta seccin se han
aadido nmeros de lnea a la izquierda del rastreo. Estos nmeros de
lnea se han aadido para clarificar la explicacin y no aparecen en el
rastreo de JDBC de DB2 real.
Inmediatamente despus de la cabecera de rastreo, suele haber varias entradas
de rastreo relacionadas con la inicializacin del entorno JDBC y el
establecimiento de conexin de base de datos. Por ejemplo:
31 jdbc.app.DB2Driver > DB2Driver() (2002-1-28 7:21:0.29)
32 | Loaded db2jdbc from java.library.path
33 jdbc.app.DB2Driver < DB2Driver() [Time Elapsed = 0.01]
34 DB2Driver - connect(jdbc:db2:sample)
35 jdbc.app.DB2ConnectionTrace > connect( sample, info, db2driver, 0, false )
(2002-1-28 7:21:0.59)
36 | 10: connectionHandle = 1
37 jdbc.app.DB2ConnectionTrace < connect() [Time Elapsed = 0.16]
38 jdbc.app.DB2ConnectionTrace > DB2Connection (2002-1-28 7:21:0.219)
39 | source = sample
40 | Connection handle = 1
41 jdbc.app.DB2ConnectionTrace < DB2Connection
En el ejemplo de rastreo anterior, se ha efectuado una peticin de carga del
controlador de JDBC de DB2 en la lnea 31. Esta peticin ha resultado
satisfactoria, tal como se notifica en la lnea 33.
El recurso de rastreo de JDBC de DB2 utiliza clases Java especficas para
capturar la informacin de rastreo. En el ejemplo de rastreo anterior, una de
estas clases de rastreo, DB2ConnectionTrace, ha generado dos entradas de
rastreo situadas en las lneas 35-37 y 38-41.
La lnea 35 muestra que se invoca el mtodo connect() y los parmetros de
entrada de dicha llamada de mtodo. La lnea 37 muestra que la llamada al
mtodo connect() ha resultado satisfactoria, mientras que la lnea 36 muestra
el parmetro de salida de dicha llamada ( Connection handle = 1 ).
Despus de las entradas relacionadas con la conexin se suelen encontrar las
entradas relacionadas con sentencias en el rastreo de JDBC. Por ejemplo:
42 jdbc.app.DB2ConnectionTrace > createStatement() (2002-1-28 7:21:0.219)
43 | Connection handle = 1
44 | jdbc.app.DB2StatementTrace > DB2Statement( con, 1003, 1007 )
(2002-1-28 7:21:0.229)
45 | jdbc.app.DB2StatementTrace < DB2Statement() [Time Elapsed = 0.0]
46 | jdbc.app.DB2StatementTrace > DB2Statement (2002-1-28 7:21:0.229)
47 | | Statement handle = 1:1
48 | jdbc.app.DB2StatementTrace < DB2Statement
49 jdbc.app.DB2ConnectionTrace < createStatement - Time Elapsed = 0.01
50 jdbc.app.DB2StatementTrace > executeQuery(SELECT * FROM EMPLOYEE WHERE
empno = 000010) (2002-1-28 7:21:0.269)
51 | Statement handle = 1:1
52 | jdbc.app.DB2StatementTrace > execute2( SELECT * FROM EMPLOYEE WHERE
empno = 000010 ) (2002-1-28 7:21:0.269)
52 | | jdbc.DB2Exception > DB2Exception() (2002-1-28 7:21:0.729)
53 | | | 10: SQLError = [IBM][CLI Driver][DB2/NT] SQL0401N Los tipos de datos de
los operandos de la operacin "=" no son compatibles.
SQLSTATE=42818
54 | | | SQLState = 42818
55 | | | SQLNativeCode = -401
56 | | | LineNumber = 0
57 | | | SQLerrmc = =
58 | | jdbc.DB2Exception < DB2Exception() [Time Elapsed = 0.0]
59 | jdbc.app.DB2StatementTrace < executeQuery - Time Elapsed = 0.0
En las lneas 42 y 43, la clase DB2ConnectionTrace ha notificado que se ha
llamado al mtodo de JDBC createStatement() con el descriptor de contexto de
conexin 1. Dentro de dicho mtodo, se ha llamado al mtodo interno
DB2Statement(), tal como indica otra clase del recurso de rastreo de JDBC de
DB2, DB2StatementTrace. Observe que esta llamada al mtodo interno aparece
anidada en la entrada de rastreo. Las lneas 47-49 muestran que los mtodos
han resultado satisfactorios y que se ha asignado el descriptor de contexto de
sentencia 1:1.
En la lnea 50, se ha realizado una llamada al mtodo de consulta de SQL en
la sentencia 1:1, pero la llamada ha generado una excepcin en la lnea 52. El
mensaje de error se notifica en la lnea 53 y contiene el cdigo de error nativo
de DB2 que se ha generado ( SQL0401N ), el sqlstate correspondiente a dicho
cdigo ( SQLSTATE=42818 ) y una breve descripcin del error. En este
ejemplo, el error se debe a que la columna EMPLOYEE.EMPNO est definida
como CHAR(6) y no como un valor entero, tal como se supone en la consulta.
v Miscellaneous variables en el manual Administration Guide: Performance
v TRACE CLI/ODBC Configuration Keyword en el manual CLI Guide and
Reference, Volume 1
v TRACECOMM CLI/ODBC Configuration Keyword en el manual CLI
v TRACEFILENAME CLI/ODBC Configuration Keyword en el manual CLI
v TRACEPATHNAME CLI/ODBC Configuration Keyword en el manual
v TRACEPIDLIST CLI/ODBC Configuration Keyword en el manual CLI
v TRACEREFRESHINTERVAL CLI/ODBC Configuration Keyword en el
manual CLI Guide and Reference, Volume 1
Valores de SQLSTATE y SQLCODE en Java
Si se produce un error de SQL, los programas JDBC y SQLj emiten una
SQLException. Para recuperar los valores de SQLSTATE, SQLCODE o
SQLMSG correspondientes a una instancia de una SQLException, invoque el
mtodo de la instancia correspondiente del siguiente modo:
Cdigo de retorno de SQL Mtodo SQLException
SQLCODE SQLException.getErrorCode()
SQLMSG SQLException.getMessage()
SQLSTATE SQLException.getSQLState()
Por ejemplo:
int sqlCode=0; // Variable que va a contener SQLCODE
String sqlState=00000; // Variable que va a contener SQLSTATE
try
{
// Las sentencias de JDBC pueden emitir SQLExceptions
stmt.executeQuery("Your JDBC statement here");
// Las sentencias de SQLj tambin pueden emitir SQLExceptions
#sql {..... your SQLj statement here ......};
}
/* As es como puede comprobar la existencia de SQLCODEs y SQLSTATE */
catch (SQLException e)
{
sqlCode = e.getErrorCode() // Obtener SQLCODE
sqlState = e.getSQLState() // Obtener SQLSTATE
if (sqlCode == -190 || sqlState.equals("42837"))
{
// Cdigo para manejar SQLCODE -190 o SQLSTATE 42837
}
else
{
// Cdigo para manejar otros errores
}
System.err.println(e.getMessage()) ; // Imprimir la excepcin
System.exit(1); // Salir
}
Captulo 11. Aplicaciones Java que utilizan WebSphere
Application Servers
Servicios Web . . . . . . . . . . . 337
Arquitectura de servicios Web . . . . . 339
Acceso a datos . . . . . . . . . . . 341
Acceso a datos de DB2 a travs de
servicios Web . . . . . . . . . . 341
consultas basadas en XML . . . . . . 342
consultas basadas en SQL . . . . . . 342
Archivo de extensin de definicin de
acceso a documentos. . . . . . . . 343
Java 2 Platform Enterprise Edition . . . . 343
Visin general de Java 2 Platform
Enterprise Edition (J2EE) . . . . . . 343
Java 2 Platform Enterprise Edition . . . 344
Contenedores de Java 2 Platform
Servidor Java 2 Platform Enterprise
Edition . . . . . . . . . . . . 346
Requisitos de bases de datos de Java 2
(JNDI) . . . . . . . . . . . . 346
Gestin de transacciones Java . . . . . 347
Enterprise Java Beans . . . . . . . 348
WebSphere . . . . . . . . . . . . 351
Conexin con datos de la empresa . . . 351
Fuentes de datos y agrupacin de
conexiones WebSphere . . . . . . . 351
Parmetros para ajustar las agrupaciones
de conexiones de WebSphere . . . . . 352
Ventajas de la agrupacin de conexiones
de WebSphere . . . . . . . . . . 357
Colocacin de sentencias en antememoria
en WebSphere . . . . . . . . . . 358
Servicios Web
La infraestructura de Internet est lista para dar soporte a la prxima
generacin de aplicaciones e-business, denominada servicios Web. Los
servicios Web representan el siguiente nivel de funcin y eficacia en
e-business. En concreto, los servicios Web son aplicaciones e-business
mejoradas que resultan ms fciles de anunciar y de descubrir por parte de
otras empresas porque se describen de forma ms uniforme en Internet.
Estas nuevas mejoras permiten conectar aplicaciones e-business con mayor
facilidad tanto dentro como fuera de la empresa.
Un servicio Web es un conjunto de funciones de aplicacin que realizan un
servicio para un peticionario, como funciones informativas o transaccionales.
Un servicio Web se puede describir y publicar en la red para que lo utilicen
otros programas de la red. Ejemplos de servicios Web disponibles actualmente
a nivel pblico incluyen un servicio de oferta de acciones, un servicio para
obtener noticias de fuentes de noticias de la Web, un servicio para obtener
mapas de eventos meteorolgicos histricos por cdigo postal, servicios de
conversin de moneda y un servicio para obtener las condiciones de las
autopistas en California. Puesto que los servicios Web son modulares, se
pueden aadir servicios Web relacionados para formar un servicio Web de
mayor tamao. Por ejemplo, podemos imaginar una aplicacin inalmbrica
compuesta de servicios Web independientes que obtiene ofertas de acciones,
se suscribe a servicios de noticias, convierte moneda y gestiona agendas.
Los servicios Web amplan la audiencia de la Web para incluir programas y
personas. En concreto, los servicios Web crean una arquitectura que permite
que programas de software hagan lo que hacen las personas con la Web, es
decir, acceder a documentos y ejecutar aplicaciones de forma general, sin
necesitar un conocimiento ni software cliente especfico de la aplicacin. Una
arquitectura que da soporte a los servicios Web proporciona la infraestructura
para conseguir este objetivo.
La infraestructura de servicios Web se basa en XML (eXtensible Markup
Language). Los mensajes y los datos fluyen entre un peticionario de servicios
y un proveedor de servicios mediante XML. Las siguientes secciones describen
brevemente los servicios Web, como se pueden transformar de forma
dinmica datos DB2 a XML y el importante papel que juega DB2 en el mundo
de los servicios Web.
Los servicios Web proporcionan un nivel de abstraccin que facilita la tarea de
acomodar una aplicacin de empresa existente y convertirla en un servicio
Web. Los servicios Web se basan en el formato de datos estndar XML y en
mecanismos de intercambio de datos, que proporcionan tanto flexibilidad
como independencia de la plataforma. Con servicios Web, los peticionarios no
suelen conocer ni preocuparse de la implantacin subyacente de servicios
Web, lo que puede simplificar la integracin de procesos empresariales
heterogneos.
Los servicios Web tambin le ofrecen una manera de hacer que sus procesos
empresariales clave resulten accesibles para clientes, socios y proveedores. Por
ejemplo, una compaa area puede proporcionar sus sistemas de reserva de
vuelos como servicio Web para facilitar que sus clientes de empresas grandes
integren el servicio en sus aplicaciones de planificacin de viajes. Un
proveedor puede hacer que sus niveles de inventario y sus precios resulten
accesibles para sus principales compradores.
En un posible ejemplo, un comprador compara pedidos de compra entrantes
con servicios de transporte:
1. El comprador accede a la base de datos local para seleccionar una lista de
pedidos de compra.
2. Mientras consulta los detalles correspondientes a un determinado pedido
de compra, el comprador selecciona un proveedor de servicios de
transporte de una lista aprobada, una lista que se conserva en un registro
privado.
3. Para cada proveedor, el comprador recibe ofertas de forma dinmica
mediante las funciones de los servicios Web. Cada peticin se vincula y se
enva a la ubicacin especificada en el registro, y el servicio Web del
proveedor la procesa. El servicio Web del proveedor toma la entrada sobre
la peticin, accede a su base de datos y devuelve la oferta al peticionario.
4. Luego el comprador elige un proveedor de servicio basndose en los
precios ofrecidos y la seleccin se aade a la pgina de pedidos de compra
para reflejar la seleccin de un proveedor de servicio de envo.
Es probable que los servicios Web se extiendan donde las tecnologas
existentes no lo han hecho. Los servicios Web aprovechan XML para la
representacin y el intercambio de datos y no necesitan complejas
correlaciones que dependen del lenguaje ni vinculaciones en el momento de la
compilacin. Los servicios Web ofrecen facilidad tanto de desarrollo como de
modificacin. Adems, los servicios Web no imponen estrechas relaciones
sncronas entre peticionarios y proveedores de servicios. Esta caracterstica
facilita an ms la implantacin de servicios Web en un entorno de Internet
en el que no se puede controlar de forma estrecha el comportamiento de la
red. La confianza en XML para el intercambio de datos y la abundancia de
herramientas existentes y emergentes para la tecnologa de servicios Web
facilita bastante la implantacin del primer servicio Web.
Arquitectura de servicios Web
La naturaleza de los servicios Web los convierte en componentes naturales de
una arquitectura orientada a servicios. En una tpica arquitectura orientada a
servicios, los proveedores de servicios alojan un mdulo de software accesible
a travs de la red, o servicio Web. Un proveedor de servicios define una
descripcin de servicio para un servicio Web y lo publica en un registro de
servicios. Un peticionario de servicios utiliza una operacin de bsqueda para
recuperar la descripcin del servicio del registro y utiliza la descripcin del
servicio para vincular con el proveedor de servicios e invocar o interactuar
con la implantacin del servicio Web.
En trminos sencillos, un servicios Web se crea acomodando una aplicacin de
modo que se pueda acceder a la misma mediante mensajes XML estndares,
que a su vez se acomodan de modo que enmascaran el protocolo de
transporte subyacente. El servicio se puede poner a disponibilidad pblica si
se registra en un registro de formato estndar. Este registro permite a otras
personas o aplicaciones encontrar y utilizar el servicio.
Las piezas de la arquitectura de servicios Web incluyen:
v Un servicio Web (un trmino general que se utiliza para describir software
que se puede invocar sobre la Web)
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 339
v Mensajes especficos de cada aplicacin que se envan en formatos de
documento XML estndar que cumplen con la correspondiente descripcin
de servicio.
v Los mensajes XML estn contenidos en sobres Simple Object Access Protocol
(SOAP). SOAP es un protocolo de invocacin de aplicaciones que define un
protocolo sencillo para intercambiar informacin codificada como mensajes
XML.
Puesto que SOAP no realiza ningn supuesto sobre la implantacin de
puntos finales, el peticionario de servicios slo tiene que crear una peticin
XML, enviarla a un proveedor de servicios y comprender la respuesta XML
que se le devuelve. La implantacin de DB2 se oculta al peticionario.
Una peticin SOAP consta del propio sobre, que contiene los espacios de
nombres que utiliza el resto del mensaje SOAP, una cabecera opcional y la
parte principal, que puede ser una llamada a un procedimiento remoto
(RPC) o un documento XML.
SOAP se basa en estndares existentes de Internet como HTTP y XML, pero
se puede utilizar con cualquier protocolo de red, lenguaje de programacin
o modelo de codificacin de datos. Por ejemplo, puede enviar mensajes
SOAP sobre IBM MQSeries, FTP o incluso como mensajes de correo.
v La interfaz lgica y la implantacin del servicio los describe el Lenguaje de
descripcin de servicios Web (WSDL). WSDL es un vocabulario XML que se
utiliza para automatizar los detalles que intervienen en la comunicacin
entre las aplicaciones de servicios Web. Hay tres piezas de WSDL: un
descriptor de tipo de datos (Esquema XML), una descripcin de interfaz e
informacin de vinculacin. La descripcin de interfaz se suele utilizar en el
momento del desarrollo y la informacin de vinculacin se puede utilizar
en el momento del desarrollo o de la ejecucin para invocar un
determinado servicio en la ubicacin especificada. La descripcin del
servicio resulta crucial para hacer que la arquitectura de servicios Web est
acoplada de forma holgada y para reducir la cantidad de conocimientos
compartidos necesarios y programacin personalizada entre proveedores de
servicios y peticionarios de servicios.
v Para permitir que los peticionarios de servicios encuentren el servicio Web,
puede publicar informacin descriptiva, como taxonoma, propiedad,
nombre de empresa, tipo de empresa, etc., a travs de un registro que
cumpla con la especificacin Uniform Description, Discovery and
Integration (UDDI) o de algn otro registro XML. La informacin UDDI
puede incluir un puntero a las interfaces WSDL, informacin de
vinculacin, as como el nombre real de la empresa (el nombre que permita
a los usuarios comprender el objetivo del servicio Web). Un registro UDDI
se puede buscar mediante programas, lo que permite a un peticionario de
servicios vincular con un proveedor UDDI para encontrar ms informacin
sobre un servicio antes de utilizarlo realmente.
v La posibilidad de componer servicios Web juntos se suministra mediante
Web Services Flow Language (WSFL). WSFL se puede utilizar para describir
un proceso empresarial (es decir, un flujo de ejecucin de principio a fin) o
una descripcin de las interacciones generales entre servicios Web variantes
sin ninguna secuencia especificada.
Si se mira el modo en que estas especificaciones trabajan juntas, un servicio
Web se puede definir como una aplicacin modular que se puede:
v Describir mediante WSDL
v Publicar mediante UDDI
v Encontrar mediante UDDI
v Vincular mediante SOAP (o HTTP GET /POST)
v Invocar mediante SOAP (o HTTP GET/POST)
v Componer con otros servicios en nuevos servicios mediante WSFL
Puede restringir el acceso a servicios Web de forma parecida a como
restringira el acceso a sitios Web que no estn disponibles para todo el
mundo. WebSphere proporciona muchas opciones para controlar el acceso y
para autentificacin. La extensin de seguridad de SOAP, que se incluye con
WebSphere Application Server 4.0, tiene como objetivo ser una arquitectura de
seguridad basada en la especificacin de seguridad de SOAP y en tecnologas
de seguridad ampliamente aceptadas como Secure Socket Layer (SSL).
Cuando se utiliza HTTP como mecanismo de transporte, hay distintas formas
de combinar autentificacin bsica HTTP, SSL y signaturas SOAP para
manejar requisitos variantes de seguridad y autentificacin.
Acceso a datos
Las secciones siguientes describen cmo acceder a datos de DB2 con servicios
Web.
Acceso a datos de DB2 a travs de servicios Web
IBM est habilitando sus modelos de programacin claves y servidores de
aplicaciones con herramientas de desarrollo de Web para generar
automticamente servicios Web a partir de objetos y procedimientos
almacenados existentes. Las secciones siguientes describen otra forma de
someter consultas SQL y, si lo necesita, se ha planificado dar soporte al
control del formato de las operaciones de los servicios Web:
v Almacenamiento o consulta basada en XML. Es decir, un documento XML
se almacena en tablas relacionales DB2 y se compone de nuevo durante la
recuperacin. Este mtodo de funcionamiento necesita la presencia de DB2
XML Extender.
v Operaciones basadas en SQL, como llamar a procedimientos almacenados o
insertar, actualizar y suprimir datos de DB2.
v Acceso a datos de DB2 mediante consultas basadas en XML en la pgina
342
v Acceso a datos de DB2 mediante consultas basadas en SQL en la pgina
342
Acceso a datos de DB2 mediante consultas basadas en XML
La consulta basada en XML le permite componer documentos XML a partir de
datos relacionales. Tambin puede dividir un documento XML en sus piezas
de componentes y almacenarlo en tablas relacionales. Parte del soporte
subyacente para esta funcin la ofrece DB2 XML Extender. Las operaciones de
almacenamiento y recuperacin se manejan mediante procedimientos
almacenados especiales que se suministran con DB2 XML Extender.
Una de las entradas tanto en almacenamiento como en recuperacin es el
archivo de correlacin especificado por el usuario que crea la asociacin entre
datos relacionales y la estructura del documento XML. Este archivo de
correlacin se denomina una definicin de acceso a documento (DAD) y
proporciona una forma de crear un documento XML con atributos y
elementos XML denominados segn necesite y con la forma que desee. En el
centro de este enfoque est el movimiento y manipulacin de documentos
XML.
Acceso a datos de DB2 mediante consultas basadas en SQL
En servicios Web, consulta basada en SQL es sencillamente la posibilidad de
enviar sentencias de SQL, incluidas llamadas a procedimientos almacenados, a
DB2 y devolver resultados con la codificacin por omisin. El centro de este
enfoque consiste en mover datos a la base de datos y fuera de esta y no en
formatear los resultados de una determinada manera.
La consulta basada en SQL no necesita el uso de DB2 XML Extender, porque
no hay ninguna correlacin definida por el usuario de datos SQL con
atributos y elementos XML. En su lugar, los datos se devuelven utilizando
nicamente una sencilla correlacin de tipos de datos SQL, mediante nombres
de columnas como elementos.
Sin embargo, si utiliza DB2 XML Extender para almacenar documentos XML
dentro de una sola columna de una tabla, puede utilizar la consulta basada en
SQL para recuperar estos documentos intactos como un objeto grande de
caracteres (CLOB) o para invocar las funciones definidas por el usuario que
extraen partes del documento. Otra funcin de DB2 XML Extender es la
posibilidad de almacenar datos a los que se accede con frecuencia en tablas
adicionales, lo que permite realizar bsquedas rpidas en documentos XML
que estn almacenados en columnas.
Otra cosa de utilidad que puede hacer con la consulta basada en SQL es
invocar procedimientos almacenados de DB2. La naturaleza de los
procedimientos almacenados permite convertirlos en servicios Web puesto que
son en s una encapsulacin de lgica de programacin y acceso a base de
datos. Una invocacin de servicio Web de un procedimiento almacenado
permite proporcionar de forma dinmica parmetros de entrada y recuperar
resultados.
Archivo de extensin de definicin de acceso a documentos
Tanto los formatos de consulta basados en XML como los basados en SQL se
controlan mediante un archivo de configuracin denominado extensin de
definicin de acceso a documentos (DADX). El archivo de configuracin DADX
define las operaciones que puede llevar a cabo el servicio Web. Por ejemplo,
puede tener un archivo DADX que especifique las operaciones para buscar
todos los pedidos de piezas, buscar todos los pedidos de piezas con un
determinado color y pedidos de piezas que sobrepasan un precio especificado.
(El color o precio se puede especificar en el tiempo de ejecucin como
parmetros de entrada utilizando la notacin de estilo de variable del lenguaje
principal en la consulta.)
Despus de crear un archivo DADX, WebSphere Studio Application Developer
puede generar automticamente la descripcin WSDL de las interfaces y
publicar las interfaces en un registro UDDI o en algn otro directorio de
servicios. WebSphere Studio Application Developer tambin generar los
objetos necesarios para desplegar el servicio Web en WebSphere Application
Server y para generar los proxies del cliente, los cuales puede utilizar para
pruebas y como base para la creacin de la parte cliente de la aplicacin Web.
Java 2 Platform Enterprise Edition
Las secciones siguientes describen Java 2 Platform Enterprise Edition (J2EE).
Visin general de Java 2 Platform Enterprise Edition (J2EE)
En el entorno empresarial global actual, las organizaciones tienen que ampliar
su alcance, reducir sus costes y reducir sus tiempos de respuesta,
proporcionando servicios a los que puedan acceder fcilmente sus clientes,
empleados, proveedores y otros socios empresariales. Estos servicios deben
tener las siguientes caractersticas:
v Altamente disponibles, para ajustarse a los requisitos del entorno
empresarial global
v Seguros, para proteger la privacidad de los usuarios y la integridad de la
empresa
v Fiables y escalables, de modo que las transacciones empresariales resulten
precisas y se procesen con rapidez
En la mayora de los casos, estos servicios se suministran con la ayuda de
aplicaciones de varios enlaces en las que cada enlace tiene un objetivo
especfico. Java 2 Platform Enterprise Edition reduce el coste y la complejidad
de desarrollar estos servicios de varios enlaces, lo que da lugar a servicios que
se pueden desplegar rpidamente y se pueden mejorar fcilmente segn los
requisitos de la empresa.
Java 2 Enterprise Edition consigue estas ventajas definiendo una arquitectura
estndar que se suministra como los siguientes elementos:
v Java 2 Enterprise Edition Application Model, un modelo de aplicacin
estndar para desarrollar servicios de clientes ligeros de varios enlaces
v Java 2 Enterprise Edition Platform, una plataforma estndar para alojar
aplicaciones Java 2 Enterprise Edition
v Java 2 Enterprise Edition Compatibility Test Suite para verificar que un
producto Java 2 Enterprise Edition Platform cumple con el estndar de Java
2 Enterprise Edition Platform
v Java 2 Enterprise Edition Reference Implementation para demostrar las
funciones de Java 2 Enterprise Edition y para proporcionar una definicin
operativa de la plataforma Java 2 Enterprise Edition
v Java 2 Platform Enterprise Edition en la pgina 344
Java 2 Platform Enterprise Edition
Java 2 Platform Enterprise Edition proporciona el entorno de tiempo de
ejecucin para alojar aplicaciones Java 2 Enterprise Edition. El entorno de
tiempo de ejecucin define cuatro tipos de componentes a los que un
producto Java 2 Enterprise Edition debe dar soporte:
v Los clientes de aplicaciones son programas en lenguaje de programacin
Java que suelen ser programas GUI que se ejecutan en un sistema de
escritorio. Los clientes de aplicaciones tienen acceso a todas las funciones
del enlace medio de Java 2 Enterprise Edition.
v Los componentes applets y GUI que normalmente se ejecutan en un
navegador web pero que se pueden ejecutar en otras aplicaciones o
dispositivos que den soporte al modelo de programacin de applets.
v Los servlets, JavaServer Pages (JSP), filtros y receptores de sucesos de la
web que se suelen ejecutar en un navegador web y que pueden responder a
peticiones HTTP procedentes de clientes web. Los servlets, JSP y filtros se
pueden utilizar para generar pginas HTML que constituyen la interfaz de
usuario de una aplicacin. Tambin se pueden utilizar para generar XML o
datos en otro formato que consumen otros componentes de la aplicacin.
Los servlets, las pginas creadas con tecnologa JSP, los filtros y los
receptores de sucesos de la web reciben conjuntamente en esta
especificacin el nombre componentes de la web. Las aplicaciones web constan
de componentes de la web y de otros datos como pginas HTML.
v Los componentes Enterprise JavaBeans (EJB) se ejecutan en un entorno
gestionado que da soporte a transacciones. Los Enterprise Beans suelen
contener la lgica empresarial correspondiente a una aplicacin Java 2
Enterprise Edition.
Los componentes de aplicaciones listados anteriormente se pueden dividir en
tres categoras, segn el modo en que se pueden desplegar y gestionar:
v Componentes que se despliegan, gestionan y ejecutan en un servidor Java 2
Enterprise Edition.
v Componentes que se despliegan y gestionan en un servidor Java 2
Enterprise Edition pero que se cargan en una mquina cliente y se ejecutan
en la misma.
v Componentes cuyo despliegue y gestin no estn completamente definidos
por esta especificacin. Los clientes de aplicaciones pueden encontrarse en
esta categora.
El soporte de tiempo de ejecucin correspondiente a estos componentes se
proporciona mediante contenedores.
v Contenedores de Java 2 Platform Enterprise Edition en la pgina 345
Contenedores de Java 2 Platform Enterprise Edition
Un contenedor proporciona una vista federada de las API subyacentes de Java
2 Platform Enterprise Edition a los componentes de la aplicacin. Un producto
Java 2 Platform Enterprise Edition tpico proporcionar un contenedor para
cada tipo de componente de la aplicacin: contenedor de clientes de la
aplicacin, contenedor de applets, contenedor de web y contenedor de
Enterprise Beans. Las herramientas de contenedor tambin comprenden los
formatos de archivo para empaquetar los componentes de la aplicacin para
su despliegue.
La especificacin necesita que estos contenedores proporcionen un entorno de
tiempo de ejecucin compatible con Java, segn lo definido en la
especificacin J2SE de Java 2 Platform Enterprise Edition, Standard Edition
V1.3.1. Esta especificacin define un conjunto de servicios estndar a los que
debe dar soporte cada producto Java 2 Enterprise Edition. Estos servicios
estndar son:
v Servicio HTTP
v Servicio HTTPS
v API de transacciones Java
v Mtodo de invocacin remota
v IDL Java
v API JDBC
v Servicio de mensajes de Java
v Naming and Directory Interface de Java
v JavaMail
v Infraestructura de activacin de JavaBeans
v API Java para el anlisis XML
v Arquitectura de conectores
v Servicio de autentificacin y autorizacin de Java
v Java Naming and Directory Interface (JNDI) en la pgina 346
Servidor Java 2 Platform Enterprise Edition
Como elemento subyacente de un contenedor Java 2 Platform Enterprise
Edition se encuentra el servidor del que forma parte el contenedor. Un
proveedor de productos Java 2 Enterprise Edition suele implantar las
funciones de servidor Java 2 Platform Enterprise Edition mediante una
infraestructura existente de proceso de transacciones en combinacin con la
tecnologa J2SE. Las funciones del cliente Java 2 Platform Enterprise Edition
suelen estar integradas en la tecnologa J2SE.
Nota: IBM WebSphere Application Server es un servidor que cumple con las
especificaciones de Java 2 Platform Enterprise Edition.
Requisitos de bases de datos de Java 2 Enterprise Edition
La plataforma Java 2 Enterprise Edition necesita una base de datos a la que se
pueda acceder a travs de la API JDBC para el almacenamiento de los datos
de la empresa. Se puede acceder a la base de datos desde componentes de la
web, Enterprise Beans y componentes cliente de la aplicacin. No hace falta
que se pueda acceder a la base de datos desde los applets.
v Consideraciones sobre la programacin en Java en la pgina 284
Java Naming and Directory Interface (JNDI)
JNDI permite que las aplicaciones basadas en la plataforma Java accedan a
varios servicios de nomenclatura y directorio. Esto forma parte del conjunto
de interfaces de programacin de aplicaciones (API) de Java Enterprise. JNDI
permite a los programadores crear aplicaciones portables habilitadas para
distintos servicios de nomenclatura y directorio que incluyen sistemas de
archivos, servicios de directorio como Lightweight Directory Access Protocol
(LDAP), Novell Directory Services y Network Information System (NIS) y
sistemas de objetos distribuidos como Common Object Request Broker
Architecture (CORBA), Invocacin a mtodos remotos (RMI) de Java y
Enterprise JavaBeans (EJB).
La API JNDI tiene dos partes: una interfaz de nivel de aplicacin que utilizan
los componentes de la aplicacin para acceder a los servicios de nomenclatura
y directorio y una interfaz de proveedor de servicios para conectar con un
proveedor de un servicio de nomenclatura y directorio.
Gestin de transacciones Java
Java 2 Enterprise Edition simplifica la programacin de aplicaciones para la
gestin de transacciones distribuidas. Java 2 Enterprise Edition incluye soporte
de transacciones distribuidas a travs de dos especificaciones, API de
transacciones Java y Servicio de transacciones Java (JTS). JTA es una API de
alto nivel, independiente de la implementacin e independiente del protocolo,
que permite a las aplicaciones y a los servidores de aplicaciones acceder a
transacciones. Adems, JTA est siempre habilitada.
JTA especifica interfaces Java estndar entre un gestor de transacciones y las
partes que intervienen en un sistema de transacciones distribuidas: el gestor
de recursos, el servidor de aplicaciones y las aplicaciones transaccionales.
JTS especifica la implantacin de un Gestor de transacciones que da soporte a
JTA e implanta la correlacin Java de la especificacin OMG Object
Transaction Service (OTS) 1.1 al nivel que hay bajo la API. JTS propaga las
transacciones mediante IIOP.
JTA y JTS permiten a los servidores de aplicaciones Java 2 Enterprise Edition
evitar al desarrollador de componentes la tarea de gestin de transacciones.
Los programadores pueden definir las propiedades transaccionales de la
tecnologa EJB basndose en componentes durante el diseo o despliegue
mediante sentencias declarativas en el descriptor de despliegue. El servidor de
aplicaciones se hace cargo de la responsabilidad de la gestin de
transacciones.
En DB2 y en el entorno WebSphere Application Server, WebSphere
Application Server asume la funcin de gestor de transacciones y DB2 acta
como un gestor de recursos. WebSphere Application Server implanta JTS y
parte de JTA, y el controlador JDBC de DB2 tambin implanta parte de JTA de
modo que WebSphere y DB2 pueden proporcionar transacciones distribuidas
coordinadas.
Nota: no es necesario configurar DB2 de modo que est habilitado para JTA
en el entorno WebSphere porque el controlador JDBC de DB2 detecta
automticamente este entorno. Actualmente, slo se proporciona
soporte de JTA en el controlador JDBC de DB2 de tipo 2.
El controlador JDBC de DB2 proporciona dos clases DataSource:
v COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource
v COM.ibm.db2.jdbc.DB2XADataSource
WebSphere Application Server proporciona conexiones DB2 agrupadas con
bases de datos. Si la aplicacin va a participar en una transaccin distribuida,
se debe utilizar la clase COM.ibm.db2.jdbc.DB2XADataSource al definir fuentes
de datos DB2 dentro de WebSphere Application Server.
Para ver informacin detallada sobre cmo configurar WebSphere Application
Server con DB2, consulte WebSphere Application Server InfoCenter en:
http://www-4.ibm.com/software/webservers/appserv/library.html
Enterprise Java Beans
La arquitectura Enterprise Java Beans constituye la arquitectura de
componentes para el desarrollo y despliegue de aplicaciones de empresa
distribuidas basadas en componentes. Las aplicaciones escritas mediante la
arquitectura de Enterprise Java Beans son escalables, transaccionales y seguras
para mltiples usuarios. Estas aplicaciones se pueden escribir una vez y luego
desplegar en cualquier plataforma de servidor que d soporte a la
especificacin Enterprise Java Beans. Las aplicaciones Java 2 Enterprise
Edition implantan componentes de empresa del servidor mediante Enterprise
Java Beans (EJB) que incluyen beans de sesin y beans de entidad.
Los beans de sesin representan los servicios de la empresa y no se comparten
entre usuarios. Los beans de entidad son objetos transaccionales distribuidos
de mltiples usuarios que representan datos permanentes. Los lmites
transaccionales de una aplicacin EJB se pueden definir especificando
transacciones gestionadas por contenedor o gestionadas por bean.
La aplicacin de ejemplo EJB proporciona dos servicios de empresa. Un
servicio permite al usuario acceder a informacin sobre un empleado (que se
almacena en la tabla EMPLOYEE de la base de datos sample) mediante el
nmero de empleado de dicho empleado. El otro servicio permite al usuario
recuperar una lista de nmeros de empleado de modo que el usuario pueda
obtener un nmero de empleado para utilizarlo para consultar datos del
empleado.
El siguiente ejemplo utiliza EJB para implantar una aplicacin Java 2
Enterprise Edition para acceder a una base de datos DB2. El ejemplo utiliza la
arquitectura Modelo-Vista-Controlador (MVC). Se utiliza la JSP para implantar
la Vista (el componente de presentacin). Un servlet acta como el controlador
en el ejemplo. Controla el flujo de trabajo y delega la peticin del usuario al
Modelo que se implanta mediante Enterprise Java Beans. El componente
Modelo del ejemplo consta de dos EJB, un bean de sesin y un bean de
entidad. El bean de entidad CMP, Employee, representa los objetos
transaccionales distribuidos que representan los datos permanentes de la tabla
EMPLOYEE de la base de datos sample. El objetivo de utilizar el bean de
permanencia gestionada por contenedor (CMP) es mostrar lo fcil que resulta
utilizarlo en el desarrollo. El trminos permanencia gestionada por contenedor
significa que el contenedor EJB maneja todo el acceso a base de datos que
necesita el bean de entidad. El cdigo del bean no contiene ninguna llamada
de acceso a base de datos (SQL). Como resultado, el cdigo del bean no est
enlazado a ningn mecanismo de almacenamiento permanente especfico
(base de datos). Gracias a esta flexibilidad, aunque vuelva a desplegar el
mismo bean de entidad en distintos servidores Java 2 Enterprise Edition que
utilicen distintas bases de datos, el bean de sesin, AccessEmployee, acta
como fachada del bean de entidad y proporciona una estrategia uniforme de
acceso de clientes. Este diseo de fachada reduce el trfico en la red entre el
cliente EJB y el bean de entidad y resulta ms eficiente en transacciones
distribuidas que cuando el cliente EJB accede al bean de entidad directamente.
El acceso a la base de datos DB2 se puede proporcionar desde el bean de
sesin o desde el bean de entidad. Los dos servicios de la aplicacin de
ejemplo demuestran ambos enfoques para acceder a la base de datos DB2 de
acuerdo con las caractersticas de los servicios. En el Servicio uno, se utiliza
un bean de entidad:
//====================================================
// Este mtodo devuelve la informacin de un empleado
// mediante la interaccin con el bean de entidad localizado
// mediante el nmero de empleado proporcionado
public EmployeeInfo getEmployeeInfo(String empNo)
throws java.rmi.RemoteException
}
Employee employee = null;
try
}
employee = employeeHome.findByPrimaryKey(new EmployeeKey(empNo));
EmployeeInfo empInfo = new EmployeeInfo(empNo);
//establecer la informacin del empleado en el objeto de valor dependiente
empInfo.setEmpno(employee.getEmpno());
empInfo.setFirstName (employee.getFirstName());
empInfo.setMidInit(employee.getMidInit());
empInfo.setLastName(employee.getLastName());
empInfo.setWorkDept(employee.getWorkDept());
empInfo.setPhoneNo(employee.getPhoneNo());
empInfo.setHireDate(employee.getHireDate());
empInfo.setJob(employee.getJob());
empInfo.setEdLevel(employee.getEdLevel());
empInfo.setSex(employee.getSex());
empInfo.setBirthDate(employee.getBirthDate());
empInfo.setSalary(employee.getSalary());
empInfo.setBonus(employee.getBonus());
empInfo.setComm(employee.getComm());
return empInfo;
}
catch (java.rmi.RemoteException rex)
{
......
La lnea uno del cdigo sirve para acceder a la base de datos DB2. En el
servicio de visualizacin de nmeros de empleado, el bean de sesin,
AccessEmployee, accede directamente a la base de datos DB2 sample.
/=============================================
* Obtener la lista de nmeros de empleado.
* @return Collection
*/
public Collection getEmpNoList()
{
ResultSet rs = null;
PreparedStatement ps = null;
Vector list = new Vector();
DataSource ds = null;
Connection con = null;
try
{
ds = getDataSource();
con = ds.getConnection();
String schema = getEnvProps(DBschema);
String query = "Select EMPNO from " + schema + ".EMPLOYEE";
ps = con.prepareStatement(query);
ps.executeQuery();
rs = ps.getResultSet();
EmployeeKey pk;
while (rs.next())
{
pk = new EmployeeKey();
pk.employeeId = rs.getString(1);
list.addElement(pk.employeeId);
}
rs.close();
return list;
El programa de ejemplo AccessEmployee.ear utiliza Enterprise Java Beans
para implantar una aplicacin Java 2 Enterprise Edition para acceder a la base
de datos DB2. Encontrar este ejemplo en el directorio
SQLLIB/samples/websphere.
WebSphere
Las secciones siguientes describen la colocacin en antememoria de sentencias
y la agrupacin de conexiones WebSphere.
Conexin con datos de la empresa
Con compaas que confan cada vez ms en sus datos almacenados, es
necesario tenerlos todos en sistemas grandes como servidores zSeries. Con
esta nueva necesidad de consolidacin, las aplicaciones Web necesitan formas
de acceder a los datos de la empresa.
DB2 Connect ofrece a las aplicaciones basadas en Windows o en UNIX la
posibilidad de conectar con datos almacenados en estos sistemas grandes y de
poderlos utilizar. DB2 tambin ofrece su propio conjunto de funciones como la
agrupacin de conexiones y el concentrador de conexiones.
Fuentes de datos y agrupacin de conexiones WebSphere
Cada vez que un recurso intenta acceder a una base de datos, debe establecer
conexin con dicha base de datos. Una conexin con una base de datos
implica actividad general; necesita recursos para crear la conexin, mantenerla
y luego liberarla cuando ya no la necesita.
Nota: la informacin que se proporciona aqu se refiere a la Versin 4 de
WebSphere Application Server para UNIX, LINUX y Windows.
La actividad general total de la base de datos correspondiente a una
aplicacin es especialmente alta para aplicaciones basadas en la Web, porque
los usuarios de la Web se conectan y desconectan con ms frecuencia.
Adems, las interacciones de los usuarios suelen ser ms cortas, debido a la
naturaleza de Internet. Normalmente, se emplea ms esfuerzo en conectar y
desconectar que durante la propia transaccin. Adems, puesto que las
peticiones de Internet pueden llegar prcticamente de cualquier lugar, los
volmenes de uso pueden ser superiores y ms difciles de predecir.
IBM WebSphere Application Server permite a los administradores establecer
una agrupacin de conexiones de bases de datos que pueden compartir las
aplicaciones de un servidor de aplicaciones para solucionar estos problemas
de actividad general.
La agrupacin de conexiones extiende la actividad general de conexin entre
varias peticiones de usuarios, por lo que conserva los recursos para futuras
peticiones.
Puede utilizar la agrupacin de conexiones de WebSphere o el soporte de
agrupacin de conexiones de DB2, que se proporciona mediante la API
Paquete opcional de JDBC 2.1, para establecer la agrupacin de conexiones.
La agrupacin de conexiones de WebSphere es la implantacin de la
especificacin de la API Paquete opcional de JDBC 2.1. Por lo tanto, el modelo
de programacin de agrupacin de conexiones es el que se especifica en las
especificaciones JDBC 2.1 Core y API Paquete opcional de JDBC 2.1. Esto
significa que las aplicaciones que obtienen sus conexiones a travs de una
fuente de datos creada en WebSphere Application Server pueden aprovechar
las funciones de JDBC 2.1 como la agrupacin de conexiones y las conexiones
habilitadas para JTA.
Adems, la agrupacin de conexiones de WebSphere proporciona funciones
adicionales que permiten a los administradores ajustar la agrupacin para
optimizar su rendimiento y proporcionar aplicaciones con excepciones de
WebSphere que permiten a los programadores escribir aplicaciones sin
conocer las SQLExceptions comunes especficas del proveedor. No todas las
SQLExceptions especficas del proveedor se correlacionan con excepciones de
WebSphere; se deben codificar las aplicaciones para que puedan manejar las
SQLExceptions especficas del proveedor. Sin embargo, las excepciones
recuperables ms comunes se correlacionan con excepciones de WebSphere.
La fuente de datos obtenida a travs de WebSphere es una fuente de datos
que implanta la API Paquete opcional de JDBC 2.1. Proporciona agrupacin
de conexiones y, en funcin de la fuente de datos seleccionada especfica del
proveedor, es posible que proporcione conexiones capaces de participar en
transacciones de protocolo de confirmacin en dos fases (habilitadas para
JTA).
El programa AccessEmployee del archivo AccessEmployee.ear utiliza
DataSource de WebSphere para acceder a una base de datos DB2.
Parmetros para ajustar las agrupaciones de conexiones de WebSphere
Se pueden realizar mejoras en el rendimiento ajustando correctamente los
parmetros en la agrupacin de conexiones. Esta seccin detalla cada una de
las propiedades que se encuentran en la pestaa Agrupacin de conexiones y
cmo se pueden ajustar para conseguir un rendimiento ptimo.
Las siguientes propiedades se encuentran en la pestaa Agrupacin de
conexiones de la ventana de creacin de fuente de datos y en la pestaa
Agrupacin de conexiones de la ventana de propiedades de la fuente de
datos:
Tamao mnimo de la agrupacin
El nmero mnimo de conexiones que puede albergar la agrupacin
de conexiones. Por omisin, este valor es 1. Cualquier entero no
negativo es un valor vlido para esta propiedad. El tamao mnimo
de la agrupacin puede afectar al rendimiento de una aplicacin.
Agrupaciones menores requieren menos actividad general cuando la
demanda es baja, porque se mantienen abiertas menos conexiones con
la base de datos. Por otro lado, cuando la demanda es alta, las
primeras aplicaciones obtendrn una respuesta lenta porque se
tendrn que crear nuevas conexiones si se estn utilizando las de la
agrupacin.
Tamao mximo de la agrupacin
El nmero mximo de conexiones que puede albergar la agrupacin
de conexiones. Por omisin, este valor es 10. Cualquier entero positivo
es un valor vlido para esta propiedad. El tamao mximo de la
agrupacin puede afectar al rendimiento de una aplicacin.
Agrupaciones mayores requieren ms actividad general cuando la
demanda es alta, porque hay ms conexiones abiertas con la base de
datos en momentos de demanda punta. Estas conexiones permanecen
hasta que quedan desocupadas fuera de la agrupacin. Por otro lado,
si el mximo es menor, pueden producirse tiempos de espera ms
largos o errores de tiempo de espera excedido de conexin durante
momentos de demanda punta. La base de datos debe ser capaz de dar
soporte al nmero mximo de conexiones en el servidor de
aplicaciones, adems de a cualquier carga que pueda tener fuera del
servidor de aplicaciones.
Tiempo de espera excedido de conexin
El nmero mximo de segundos que una aplicacin espera una
conexin procedente de la aplicacin antes de exceder el tiempo de
espera enviando una ConnectionWaitTimeoutException a la aplicacin.
El valor por omisin es 180 segundos (3 minutos). Cualquier entero
no negativo es un valor vlido para esta propiedad. Si establece para
esta propiedad el valor 0, se inhabilita el tiempo de espera excedido
de la conexin.
Tiempo de espera excedido de desocupacin
EL nmero de segundos que una conexin puede estar libre en la
agrupacin antes de que la conexin se elimine de la agrupacin. El
valor por omisin es 1800 segundos (30 minutos). Cualquier entero no
negativo es un valor vlido para esta propiedad. Las conexiones
tienen que estar desocupadas fuera de la agrupacin, porque
mantener conexiones abiertas con la base de datos puede ocasionar
problemas de memoria con la base de datos. Sin embargo, no todas
las conexiones quedan desocupadas fuera de la agrupacin, aunque
superen el valor especificado para la propiedad Tiempo de espera
excedido de desocupacin. Una conexin no queda desocupada si al
eliminar la conexin la agrupacin quedara con un tamao menor al
de su tamao mnimo. Si establece para esta propiedad el valor 0, se
inhabilita el tiempo de espera excedido de desocupacin.
Tiempo de espera excedido de orfandad
El nmero de segundos que una aplicacin puede mantener una
conexin inactiva. El valor por omisin es 1800 segundos (30
minutos). Cualquier entero no negativo es un valor vlido para esta
propiedad. Si no ha habido actividad en una conexin asignada
durante ms tiempo del especificado en el valor Tiempo de espera
excedido de orfandad, la conexin se marca como hurfana.
Transcurridos otra vez el nmero de segundos especificados en
Tiempo de espera excedido de orfandad, si la conexin sigue sin
actividad, se devuelve a la agrupacin. Si la aplicacin vuelve a
intentar utilizar la conexin, recibe una StaleConnectionException. Las
conexiones que aparecen listadas en una transaccin no son hurfanas.
Si establece para esta propiedad el valor 0, se inhabilita el tiempo de
espera excedido de orfandad.
Tamao de antememoria de sentencias
El nmero de sentencias preparadas colocadas en antememoria se
mantiene para una agrupacin de conexiones entera. El valor por
omisin es 100. Cualquier entero no negativo es un valor vlido para
esta propiedad. Cuando una sentencia se coloca en antememoria, se
aumenta el rendimiento, porque una sentencia se recupera de la
antememoria si se encuentra una sentencia coincidente, en lugar de
tener que crear una nueva sentencia preparada (lo que constituye una
operacin ms cara). El tamao de antememoria de sentencias no
cambia el modelo de programacin, nicamente el rendimiento de la
aplicacin. El tamao de antememoria de sentencias es el nmero de
sentencias colocadas en antememoria correspondientes a la agrupacin
entera, no a cada conexin. Poder establecer el tamao de
antememoria de sentencias en la consola administrativa constituye
una nueva opcin de la Versin 4.0. En versiones anteriores, este valor
slo se poda establecer mediante un archivo datasources.xml. El uso
de datasources.xml no se recomienda en la Versin 4.0.
Inhabilitar limpieza automtica de conexiones
Indica si la conexin se tiene o no que cerrar al final de una
transaccin. El valor por omisin es false, lo que indica que, una vez
completada una transaccin, WebSphere cierra la conexin y la
devuelve a la agrupacin. Esto significa que, si se intenta utilizar la
conexin una vez finalizada la transaccin, se recibe una
StaleConnectionException, porque la conexin se ha cerrado y ha
vuelto a la agrupacin. Este mecanismo asegura que la aplicacin no
mantiene conexiones de forma indefinida. Si el valor es true, la
conexin no se devuelve a la agrupacin al final de una transaccin.
En este caso, la aplicacin debe devolver la conexin a la agrupacin
llamando al mtodo close(). Si la aplicacin no cierra la conexin, la
agrupacin puede quedarse sin conexiones para que las utilicen otras
aplicaciones.
Cada uno de estos parmetros configurables puede determinar el modo en
que se utilizan los recursos en cada agrupacin. Los dos parmetros ms
importantes son Tamao mnimo de la agrupacin y Tamao mximo de la
agrupacin. A continuacin se muestran definiciones ms detalladas y
posibilidades de uso de estos dos parmetros:
Tamao mnimo de la agrupacin
El nmero mnimo de conexiones que la agrupacin de conexiones
puede mantener abiertas con la base de datos. El valor por omisin es
1. En las versiones 3.5 y 4.0, la agrupacin no crea el nmero mnimo
de conexiones con la base de datos en un principio. En su lugar, a
medida que se necesitan conexiones adicionales, se crean nuevas
conexiones con la base de datos, con lo que la agrupacin va
creciendo. Cuando la agrupacin alcanza el nmero mnimo de
conexiones, no se reduce por debajo de este mnimo.
El valor mnimo correcto para la agrupacin se puede determinar
examinando las aplicaciones que utilizan la agrupacin. Si, por
ejemplo, se determina que se necesitan al menos cuatro conexiones en
cualquier momento, el nmero mnimo de conexiones se debe
establecer en 4 para asegurar que todas las peticiones se pueden
responder sin excepciones de tiempo de espera excedido de conexin.
En momentos de baja demanda, la agrupacin recupera su nmero
mnimo de conexiones. Una buena norma general a seguir consiste en
mantener este nmero tan bajo como sea posible para evitar mantener
conexiones abiertas innecesarias.
Tamao mximo de la agrupacin
El nmero mximo de conexiones que la agrupacin de conexiones
puede mantener abiertas con la base de datos. La agrupacin alberga
este nmero mximo de conexiones abiertas con la base de datos en
momentos punta. En momentos de baja demanda, la agrupacin
vuelve al nmero mnimo de conexiones.
Lo ms recomendable es asegurarse de que slo se necesite una
conexin en una hebra en cualquier momento. Esto evita posibles
puntos muertos cuando la agrupacin est a su capacidad mxima y
no queda ninguna conexin para responder a una peticin de
conexin. Por lo tanto, con una conexin por hebra, el tamao
mximo de la agrupacin se puede establecer en el nmero mximo
de hebras.
Cuando se utilizan servlets, esto se puede determinar examinando la
propiedad MaxConnections del Motor de servlets. Si se necesitan varias
conexiones en una hebra, el valor del tamao mximo de la conexin
se puede determinar mediante la siguiente frmula:
T *(C -1)+1
Donde T es el nmero de hebras y C es el nmero de conexiones.
Los otros parmetros de ajuste dependen en gran medida de la aplicacin si
se utilizan para llevar a cabo ajustes. En cada caso es importante saber
aproximadamente durante cunto tiempo la aplicacin promedio utilizar una
conexin de la agrupacin. Por ejemplo, si se sabe que todas las aplicaciones
que utilizan una agrupacin de conexiones mantienen una conexin durante
un tiempo medio de 5 segundos, con un mximo de 10 segundos, puede
resultar til establecer para Tiempo de espera excedido de orfandad el valor
10 15 segundos, pero estar preparados para recibir alguna
StaleConnectionException ocasional.
No se recomienda definir deliberadamente las conexiones como hurfanas,
aunque puede resultar til en algunos escenarios de determinacin de
problemas en los que las conexiones se mantienen durante periodos de tiempo
largos y se sabe que la aplicacin slo necesita una conexin durante un
periodo corto.
Tiempo de espera excedido de inactividad es un parmetro til si utiliza una
mquina con recursos enlazados. Si ha definido correctamente los tamaos
mnimo y mximo de la agrupacin de conexiones, es posible que desee
reducir el Tiempo de espera excedido de inactividad de modo que, cuando el
uso de la agrupacin sea bajo, no haya conexiones abiertas sin actividad.
Tenga cuidado al reducir el valor de este parmetro porque establecer un
valor demasiado bajo genera el coste de crear conexiones con ms aplicaciones
cuando comienza la transformacin de carga ligera a carga pesada.
Finalmente, el Tiempo de espera excedido de conexin se puede utilizar para
asegurar que las aplicaciones no esperan indefinidamente una conexin. Si se
sabe que todas las aplicaciones que utilizan una agrupacin utilizan
conexiones durante pocos segundos, puede resultar til reducir este
parmetro; sin embargo, no establezca un valor demasiado bajo para los
sistemas con carga pesada. Por ejemplo, si se sabe que la mayora de las
aplicaciones que utilizan una agrupacin utilizan una conexin durante al
menos 10 segundos (consultas de larga ejecucin), cuando este sistema tiene
una carga por debajo de la media es posible que las aplicaciones se copien por
detrs de otra que espera conexiones de la agrupacin. Cuando ms se tarde
en volver a colocar una aplicacin en lnea, ms posibilidades hay de que se
obtenga un Tiempo de espera excedido de conexin. Tenga en cuenta que esto
es un caso raro, puesto que no muchas aplicaciones de la web tienen consultas
de larga ejecucin a las que intenten accede muchos usuarios
simultneamente. Tenga tambin en cuenta que, si se modifican los
parmetros Tamao mnimo y mximo de la agrupacin de conexiones, puede
que no vuelva a tener el problema de copia de seguridad.
Como en el ltimo ejemplo, es importante tener en cuenta todos los
parmetros de ajuste cuando se ajuste el sistema. Si slo se modifican el
tamao mnimo y mximo de la agrupacin se puede mejorar el rendimiento,
pero puede no resultar de ayuda en la contencin de recursos si hay otros
parmetros definidos de forma incorrecta para el sistema.
Como sucede en la mayora de los casos de ajuste, es recomendable probar
distintos valores y ver qu combinacin funciona mejor para el sistema.
Ventajas de la agrupacin de conexiones de WebSphere
La agrupacin de conexiones puede mejorar el tiempo de respuesta de
cualquier aplicacin que necesite conexiones, especialmente aplicaciones
basadas en la Web.
Cuando un usuario realiza una peticin a un recurso sobre la Web, el recurso
accede a una fuente de datos. La mayora de las peticiones de usuario no
implican la actividad general de crear una nueva conexin, porque la fuente
de datos puede localizar y utilizar una conexin existente de la agrupacin de
conexiones. Cuando la peticin se responde y la respuesta se devuelve al
usuario, el recurso devuelve la conexin a la agrupacin de conexiones para
que se reutilice. De nuevo, se evita la actividad general de una desconexin.
Cada usuario asimila una faccin del coste de conexin o desconexin. Una
vez se han utilizado los recursos iniciales para generar las conexiones de la
agrupacin, la actividad general adicional es insignificante porque se
reutilizan las conexiones existentes.
La colocacin en antememoria de sentencias preparadas es otro mecanismo
por el cual el mtodo de agrupacin de conexiones de WebSphere mejora los
tiempos de respuesta de aplicaciones basadas en la Web.
Una antememoria de sentencias preparadas previamente est disponible en
una conexin. Cuando se solicita una nueva sentencia preparada en una
conexin, se devuelve la sentencia preparada colocada en antememoria, si est
disponible. Esta colocacin en antememoria reduce el nmero de sentencias
preparadas creadas, que resultan caras, lo cual mejora los tiempos de
respuesta. La antememoria resulta til para aplicaciones que tienden a
preparar la misma sentencia varias veces.
Adems de mejorar los tiempos de respuesta, el mtodo de agrupacin de
conexiones de WebSphere proporciona una capa de abstraccin de la base de
datos, que puede colocar en almacenamiento intermedio la aplicacin cliente y
hacer que parezca que distintas bases de datos funcionan del mismo modo
ante una aplicacin.
Esta colocacin en almacenamiento intermedio facilita la conmutacin de
bases de datos de aplicacin, puesto que el cdigo de la aplicacin no tiene
que manejar SQLExceptions comunes especficas del cliente, sino una
excepcin de agrupacin de conexiones de WebSphere.
Colocacin de sentencias en antememoria en WebSphere
WebSphere proporciona un mecanismo para colocar en antememoria
sentencias preparadas previamente. La colocacin en antememoria de
sentencias preparadas mejora los tiempos de respuesta, ya que una aplicacin
puede reutilizar una PreparedStatement en una conexin si existe en la
antememoria de dicha conexin, sin tener que crear una nueva
PreparedStatement.
Cuando una aplicacin crea una PreparedStatement en una conexin, primero
se busca en la antememoria de la conexin para determinar si ya existe una
PreparedStatement con la misma serie SQL. Esta bsqueda se realiza
utilizando la serie entera de sentencias de SQL en el mtodo
prepareStatement(). Si se encuentra una coincidencia, se devuelve la
PreparedStatement colocada en antememoria para que se pueda utilizar. Si no
se encuentra, se crea una nueva PreparedStatement y se devuelve a la
aplicacin.
A medida que la aplicacin cierra sentencias preparadas, estas se devuelven a
la antememoria de sentencias de la conexin. Por omisin, slo se pueden
mantener 100 sentencias preparadas en antememoria para la agrupacin
entera de conexiones. Por ejemplo, si hay diez conexiones en la agrupacin, el
nmero de sentencias preparadas colocadas en antememoria correspondientes
a estas diez conexiones no puede ser mayor que 100. Esto asegura que hay un
nmero limitado de sentencias preparadas simultneamente abiertas para la
base de datos, lo que ayuda a evitar problemas de recursos con una base de
datos.
Los elementos slo se eliminan de la antememoria de sentencias preparadas
de la conexin cuando el nmero de sentencias preparadas colocadas
simultneamente en antememoria supera el valor de statementCacheSize (que
por omisin es 100). Si una sentencia preparada se tiene que eliminar de la
antememoria, se elimina y se aade a un vector de sentencias descartadas. En
cuanto finaliza el mtodo en el que se ha eliminado la sentencia preparada,
las sentencias preparadas del vector de sentencias descartadas se cierran para
la base de datos. Por lo tanto, en un determinado momento, puede haber 100
ms el nmero de sentencias recientemente descartadas abiertas para la base
de datos. Las sentencias preparadas adicionales se cierran cuando el mtodo
finaliza.
El nmero de sentencias preparadas que se pueden colocar en antememoria se
puede configurar en la fuente de datos. Cada antememoria se debe ajustar
segn los requisitos de la aplicacin en cuanto a sentencias preparadas.
Parte 4. Otras interfaces de programacin
Captulo 12. Programacin en Perl
Perl . . . . . . . . . . . . . . 363
Restricciones de Perl . . . . . . . . . 363
Perl . . . . . . . . . . . . . . 364
Conexiones de bases de datos en Perl . . . 364
Captacin de resultados en Perl . . . . . 364
Marcadores de parmetros en Perl . . . . 365
Variables SQLSTATE y SQLCODE en Perl 366
Ejemplo de programa Perl . . . . . . . 366
Consideraciones sobre la programacin en Perl
Perl es un lenguaje de programacin popular que est disponible libremente
para muchos sistemas operativos. Utilizando el controlador DBD::DB2
disponible en http://www.ibm.com/software/data/db2/perl con el Mdulo
de Interfaz de base de datos (DBI) de Perl disponible en
http://www.perl.com, puede crear aplicaciones DB2 mediante Perl.
Dado que Perl es un lenguaje interpretado y que el Mdulo DBI de Perl
utiliza SQL dinmico, Perl constituye el lenguaje ideal para crear y revisar con
rapidez los prototipos de aplicaciones DB2. El Mdulo DBI de Perl utiliza una
interfaz que es muy parecida a las interfaces CLI y JDBC, lo cual facilita el
transporte de los prototipos de Perl a CLI y JDBC.
La mayora de proveedores de bases de datos proporcionan un controlador de
base de datos para el Mdulo DBI de Perl, lo cual significa que tambin se
puede utilizar Perl para crear aplicaciones que accedan a datos de muchos
servidores de bases de datos distintos. Por ejemplo, puede escribir en Perl una
aplicacin DB2 que conecte con una base de datos Oracle utilizando el
controlador de base de datos DBD::Oracle, captar datos de la base de datos
Oracle e insertar los datos en una base de datos DB2 utilizando el controlador
de base de datos DBD::DB2.
Restricciones de Perl
El mdulo DBI de Perl slo soporta SQL dinmico. Cuando sea necesario
ejecutar una sentencia varias veces, se puede mejorar el rendimiento de las
aplicaciones DB2 en Perl emitiendo una llamada prepare para preparar la
sentencia.
Para obtener informacin actual sobre las restricciones de la versin del
controlador de DBD::DB2 que instale en la estacin de trabajo, consulte el
archivo CAVEATS contenido en el paquete del controlador de DBD::DB2.
Acceso a bases de datos de varias hebras en Perl
Perl no da soporte al acceso a bases de datos de varias hebras.
Conexiones de bases de datos en Perl
Para permitir que Perl cargue el mdulo DBI, debe incluir la lnea siguiente
en la aplicacin DB2:
use DBI;
El mdulo DBI carga automticamente el controlador DBD::DB2 cuando se
crea un descriptor de contexto de base de datos utilizando la sentencia
DBI->connect con la sintaxis siguiente:
my $dbhandle = DBI->connect(dbi:DB2:dbalias, $userID, $password);
donde:
$dbhandle
representa el descriptor de contexto de base de datos devuelto por la
sentencia de conexin
dbalias
representa un alias de DB2 catalogado en el directorio de bases de
datos de DB2
$userID
representa el ID de usuario utilizado para conectar con la base de
datos
$password
representa la contrasea para el ID de usuario utilizado para conectar
con la base de datos
Captacin de resultados en Perl
Puesto que el Mdulo DBI de Perl slo soporta SQL dinmico, no debe
utilizar variables del lenguaje principal en las aplicaciones DB2 en Perl.
Procedimiento:
Para devolver resultados de una consulta de SQL, lleve a cabo los pasos
siguientes:
1. Cree un descriptor de contexto de base de datos estableciendo conexin
con la base de datos con la sentencia DBI->connect.
2. Cree un descriptor de contexto de sentencia a partir del descriptor de
contexto de base de datos. Por ejemplo, puede llamar a prepare con una
sentencia de SQL como argumento de serie para devolver el descriptor de
contexto de sentencia $sth, tal como se muestra en la sentencia de Perl
siguiente:
my $sth = $descripbd->prepare(
SELECT firstnme, lastname
FROM employee
);
3. Ejecute la sentencia de SQL llamando a execute en el descriptor de
contexto de sentencia. Una llamada satisfactoria a execute asocia un
conjunto de resultados al descriptor de contexto de sentencia. Por ejemplo,
puede ejecutar la sentencia preparada en el ejemplo anterior utilizando la
sentencia de Perl siguiente:
#Nota: $rc representa el cdigo de retorno de la llamada a execute
my $rc = $sth->execute();
4. Capte una fila del conjunto de resultados asociado al descriptor de
contexto de sentencia mediante una llamada a fetchrow(). El DBI de Perl
devuelve una fila en forma de matriz con un valor por columna. Por
ejemplo, puede devolver todas las filas del descriptor de contexto de
sentencia del ejemplo anterior utilizando la sentencia de Perl siguiente:
while (($firstnme, $lastname) = $sth->fetchrow()) {
print "$firstnme $lastname\n";
}
v Conexiones de bases de datos en Perl en la pgina 364
Marcadores de parmetros en Perl
Para permitirle ejecutar una sentencia preparada utilizando distintos valores
de entrada para campos especficos, el mdulo DBI de Perl le permite
preparar y ejecutar una sentencia utilizando marcadores de parmetros. Para
incluir un marcador de parmetro en una sentencia de SQL, utilice un signo
de interrogacin (?).
El cdigo Perl siguiente crea un descriptor de contexto de sentencia que
acepta un marcador de parmetro para la clusula WHERE de una sentencia
SELECT. A continuacin, el cdigo ejecuta la sentencia dos veces, utilizando
los valores de entrada 25000 y 35000 para sustituir el marcador de parmetro.
my $sth = $descripbd->prepare(
SELECT firstnme, lastname
FROM employee
WHERE salary > ?
);
Captulo 12. Programacin en Perl 365
my $rc = $sth->execute(25000);
.
.
.
my $rc = $sth->execute(35000);
Variables SQLSTATE y SQLCODE en Perl
Para devolver el SQLSTATE asociado a un descriptor de contexto de base de
datos del DBI de Perl o a un descriptor de contexto de sentencia, llame al
mtodo state. Por ejemplo, para devolver el SQLSTATE asociado al descriptor
de contexto de base de datos $descripbd, incluya la sentencia de Perl
siguiente en la aplicacin:
my $sqlstate = $descripbd->state;
Para devolver el SQLCODE asociado a un descriptor de contexto de base de
datos del DBI de Perl o a un descriptor de contexto de sentencia, llame al
mtodo err. Para devolver el mensaje para un SQLCODE asociado a un
descriptor de contexto de base de datos del DBI de Perl o a un descriptor de
contexto de sentencia, llame al mtodo errstr. Por ejemplo, para devolver el
SQLCODE asociado al descriptor de contexto de base de datos $descripbd,
incluya la sentencia de Perl siguiente en la aplicacin:
my $sqlcode = $descripbd->err;
Ejemplo de programa Perl
A continuacin se muestra un ejemplo de una aplicacin escrita en Perl:
#!/usr/bin/perl
use DBI;
my $database=dbi:DB2:sample;
my $user=;
my $password=;
my $dbh = DBI->connect($database, $user, $password)
or die "Cant connect to $database: $DBI::errstr";
my $sth = $dbh->prepare(
q{ SELECT firstnme, lastname
FROM employee }
)
or die "Cant prepare statement: $DBI::errstr";
my $rc = $sth->execute
or die "Cant execute statement: $DBI::errstr";
print "Query will return $sth->{NUM_OF_FIELDS} fields.\n\n";
print "$sth->{NAME}->[0]: $sth->{NAME}->[1]\n";
while (($firstnme, $lastname) = $sth->fetchrow()) {
print "$firstnme: $lastname\n";
}
# comprobar si hay problemas que puedan haber cancelado antes la captacin
warn $DBI::errstr if $DBI::err;
$sth->finish;
$dbh->disconnect;
Captulo 12. Programacin en Perl 367
Captulo 13. Programacin en REXX
REXX . . . . . . . . . . . . . . 369
Restricciones del lenguaje en REXX . . . . 370
Restricciones del lenguaje en REXX . . . 370
Registro de SQLEXEC, SQLDBS y
SQLDB2 en REXX. . . . . . . . . 370
en REXX. . . . . . . . . . . . 372
chino tradicional para REXX . . . . . 372
SQL incorporado en aplicaciones REXX . . 372
Referencias a variables del lenguaje
Variables de indicador en REXX . . . . 375
Variables de REXX predefinidas . . . . 376
Variables del lenguaje principal de LOB
en REXX. . . . . . . . . . . . 378
Sintaxis de las declaraciones de
localizador de LOB en REXX . . . . . 378
Sintaxis de las declaraciones de referencia
de archivos LOB en REXX . . . . . . 379
Borrado de variables del lenguaje
principal de LOB en REXX. . . . . . 380
Cursores en REXX . . . . . . . . 381
Tipos de datos SQL soportados en REXX . . 381
Requisitos de ejecucin para REXX . . . . 383
REXX . . . . . . . . . . . . . 383
Archivos de vinculacin de REXX . . . 384
Sintaxis de las API para REXX . . . . . 385
Llamada a procedimientos almacenados
desde REXX . . . . . . . . . . . 387
Procedimientos almacenados en REXX 387
Llamadas a procedimientos almacenados
en REXX. . . . . . . . . . . . 387
Consideraciones del cliente para llamar a
procedimientos almacenados en REXX . . 389
Consideraciones del servidor para llamar
a procedimientos almacenados en REXX . 389
Recuperacin de valores de precisin y
escala (SCALE) de campos decimales del
SQLDA . . . . . . . . . . . . 390
Consideraciones sobre la programacin en REXX
programacin en el lenguaje principal. Se incluye informacin sobre la
incorporacin de sentencias de SQL, las restricciones del lenguaje y los tipos
de datos soportados para las variables del lenguaje principal.
Nota: soporte de REXX estabilizado en DB2 Versin 5, y no hay ninguna
mejora de REXX planificada para el futuro. Por ejemplo, REXX no
puede manejar identificadores de objetos SQL, como por ejemplo
nombres de tabla, que tengan una longitud superior a 18 bytes. Para
utilizar las caractersticas incorporadas en DB2 despus de la Versin 5,
como por ejemplo los nombres de tabla de longitud entre 19 y 128
bytes, debe escribir sus aplicaciones en un lenguaje que no sea REXX.
Puesto que REXX es un lenguaje interpretado, no se utiliza ningn
precompilador, compilador ni enlazador. En su lugar, se utilizan tres API de
DB2 para crear aplicaciones DB2 en REXX. Utilice dichas API para acceder a
distintos elementos de DB2.
SQLEXEC
Da soporte al lenguaje SQL.
SQLDBS
Da soporte a las versiones de lnea de mandatos de las API de DB2.
SQLDB2
Da soporte a una interfaz especfica de REXX con el procesador de
lnea de mandatos. Consulte la descripcin de la sintaxis de la API
para REXX para ver detalles y restricciones sobre cmo se puede
utilizar esta interfaz.
v Sintaxis de las API para REXX en la pgina 385
Restricciones del lenguaje en REXX
Las siguientes secciones describen las restricciones del lenguaje
correspondientes a REXX.
Restricciones del lenguaje en REXX
Es posible que los smbolos que se encuentren dentro de sentencias o
mandatos que se pasen a las rutinas SQLEXEC, SQLDBS y SQLDB2 puedan
corresponder a variables de REXX. En este caso, el intrprete de REXX
sustituye el valor de la variable antes de llamar a SQLEXEC, SQLDBS o
SQLDB2.
Para evitar esta situacin, encierre las series de sentencias entre comillas ( o
). Si no utiliza comillas, el intrprete de REXX resolver los nombres de
variable conflictivos, en lugar de que se pasen a las rutinas SQLEXEC,
SQLDBS o SQLDB2.
En REXX/SQL no se soporta el SQL compuesto.
Los procedimientos almacenados de REXX/SQL se soportan en los sistemas
operativos Windows, pero no en AIX.
v Registro de SQLEXEC, SQLDBS y SQLDB2 en REXX en la pgina 370
Registro de SQLEXEC, SQLDBS y SQLDB2 en REXX
Antes de utilizar cualquiera de las API de DB2 o emitir sentencias de SQL en
una aplicacin, debe registrar las rutinas SQLDBS, SQLDB2 y SQLEXEC. As
se notifica al intrprete de REXX sobre los puntos de entrada de REXX/SQL.
El mtodo que utilice para realizar el registro variar ligeramente entre las
plataformas basadas en Windows y AIX.
Procedimiento:
Utilice los ejemplos siguientes para ver la sintaxis correcta para registrar cada
rutina:
Registro de ejemplo en plataformas basadas en Windows
/* ------------ Registrar SQLDBS con REXX -------------------------*/
If Rxfuncquery('SQLDBS') <> 0 then
rcy = Rxfuncadd('SQLDBS','DB2AR','SQLDBS')
If rcy \= 0 then
do
say SQLDBS was not successfully added to the REXX environment
signal rxx_exit
end
/* ------------ Registrar SQLDB2 con REXX -------------------------*/
If Rxfuncquery('SQLDB2') <> 0 then
rcy = Rxfuncadd('SQLDB2','DB2AR','SQLDB2')
If rcy \= 0 then
do
say SQLDB2 was not successfully added to the REXX environment
signal rxx_exit
end
/* ----------------- Registrar SQLEXEC con REXX --------------------*/
If Rxfuncquery('SQLEXEC') <> 0 then
rcy = Rxfuncadd('SQLEXEC','DB2AR','SQLEXEC')
If rcy \= 0 then
do
say SQLEXEC was not successfully added to the REXX environment
signal rxx_exit
end
Ejemplo de registro en AIX
/* ------------ Registrar SQLDBS, SQLDB2 y SQLEXEC con REXX --------*/
rcy = SysAddFuncPkg("db2rexx")
If rcy \= 0 then
do
say db2rexx was not successfully added to the REXX environment
signal rxx_exit
end
En plataformas basadas en Windows, slo es necesario ejecutar una vez el
mandato RxFuncAdd para todas las sesiones.
En AIX, se debe ejecutar SysAddFuncPkg en cada aplicacin REXX/SQL.
Captulo 13. Programacin en REXX 371
En la documentacin de REXX para plataformas basadas en Windows y AIX,
respectivamente, encontrar detalles sobre las API RXfuncadd y
SysAddFuncPkg.
Acceso a bases de datos de varias hebras en REXX
REXX no da soporte al acceso a bases de datos de varias hebras.
Consideraciones sobre EUC en japons o chino tradicional para REXX
Las aplicaciones REXX no se soportan en los entornos EUC en japons o chino
tradicional.
SQL incorporado en aplicaciones REXX
Las aplicaciones REXX utilizan API que les permiten utilizar la mayora de las
funciones que suministran las API del gestor de bases de datos y SQL. A
diferencia de las aplicaciones escritas en un lenguaje compilado, las
aplicaciones REXX no se precompilan. En su lugar, un manejador de SQL
dinmico procesa todas las sentencias de SQL. Al combinar REXX con estas
API que se pueden llamar, tiene acceso a la mayora de las funciones del
gestor de bases de datos. Aunque REXX no da soporte directamente a algunas
API utilizando SQL incorporado, se puede acceder a las mismas utilizando el
procesador de lnea de mandatos de DB2 desde dentro de la aplicacin REXX.
Como REXX es un lenguaje de interpretacin, es posible que le resulte ms
fcil desarrollar y depurar los prototipos de aplicacin en REXX que en
lenguajes principales compilados. Aunque las aplicaciones DB2 codificadas en
REXX no proporcionan el rendimiento de las aplicaciones DB2 que utilizan
lenguajes compilados, proporcional la posibilidad de crear aplicaciones DB2
sin tener que precompilar, compilar, enlazar o utilizar software adicional.
Utilice la rutina SQLEXEC para procesar todas las sentencias de SQL. Los
argumentos de serie de caracteres para la rutina SQLEXEC estn formados
por los elementos siguientes:
v Palabras clave de SQL
v Identificadores declarados previamente
v Variables del lenguaje principal de sentencia
Realice cada peticin pasando una sentencia de SQL vlida a la rutina
SQLEXEC. Utilice la sintaxis siguiente:
CALL SQLEXEC 'sentencia'
Las sentencias de SQL se pueden continuar en ms de una lnea. Cada parte
de la sentencia se debe encerrar entre comillas, y se debe delimitar mediante
una coma el texto adicional de la sentencia, del modo siguiente:
CALL SQLEXEC 'SQL text',
'additional text',
.
.
.
'final text'
A continuacin se muestra un ejemplo de incorporacin de una sentencia de
SQL en REXX:
statement = "UPDATE STAFF SET JOB = Clerk WHERE JOB = Mgr"
CALL SQLEXEC EXECUTE IMMEDIATE :statement
IF ( SQLCA.SQLCODE < 0) THEN
SAY Update Error: SQLCODE = SQLCA.SQLCODE
En este ejemplo, el campo SQLCODE de la estructura SQLCA se comprueba para
determinar si la actualizacin ha resultado satisfactoria.
v Las sentencias de SQL siguientes se pueden pasar directamente a la rutina
SQLEXEC:
CALL
CLOSE
COMMIT
CONNECT
CONNECT TO
CONNECT RESET
DECLARE
DESCRIBE
DISCONNECT
EXECUTE
EXECUTE IMMEDIATE
FETCH
FREE LOCATOR
OPEN
PREPARE
RELEASE
ROLLBACK
SET CONNECTION
Existen otras sentencias de SQL que se deben procesar dinmicamente
utilizando las sentencias EXECUTE IMMEDIATE o PREPARE y EXECUTE
junto con la rutina SQLEXEC.
v No se pueden utilizar variables del lenguaje principal en las sentencias
CONNECT y SET CONNECTION en REXX.
v Los nombres de cursor y los nombres de sentencia estn predefinidos del
modo siguiente:
de c1 a c100
Nombres de cursor, que van de c1 a c50 para los cursores
declarados sin la opcin WITH HOLD, y de c51 a c100 para los
cursores declarados utilizando la opcin WITH HOLD.
El identificador de nombre de cursor se utiliza para las sentencias
DECLARE, OPEN, FETCH y CLOSE. Identifica el cursor utilizado
en la peticin de SQL.
de s1 a s100
Nombres de sentencia, que van de s1 a s100.
El identificador de nombre de sentencia se utiliza con las sentencias
DECLARE, DESCRIBE, PREPARE y EXECUTE.
Se deben utilizar identificadores declarados previamente para los nombres
de cursor y de sentencia. No se admiten otros nombres.
v Cuando se declaren cursores, el nombre de cursor y el nombre de sentencia
deben corresponder en la sentencia DECLARE. Por ejemplo, si se utiliza c1
como nombre de cursor, se debe utilizar s1 como nombre de sentencia.
v No utilice comentarios dentro de una sentencia de SQL.
Variables del lenguaje principal en REXX
lenguaje principal en programas REXX.
Variables del lenguaje principal en REXX
Las variables del lenguaje principal son variables del lenguaje REXX a las que
se hace referencia en las sentencias de SQL. Permiten que una aplicacin pase
datos de entrada a DB2 y reciba datos de salida de ste. No es necesario que
las aplicaciones REXX declaren las variables del lenguaje principal, a
excepcin de las variables de localizadores de LOB y de referencia de archivos
LOB. Los tamaos y tipos de datos de las variables de sistema principal se
determinan en el tiempo de ejecucin cuando se hace referencia a las
variables. Las siguientes secciones describen las normas a seguir para dar
nombre y utilizar variables del lenguaje principal.
v Nombres de variables del lenguaje principal en REXX en la pgina 375
v Referencias a variables del lenguaje principal en REXX en la pgina 375
v Variables de indicador en REXX en la pgina 375
v Variables del lenguaje principal de LOB en REXX en la pgina 378
v Borrado de variables del lenguaje principal de LOB en REXX en la pgina
380
v Variables de REXX predefinidas en la pgina 376
v Sintaxis de las declaraciones de localizador de LOB en REXX en la pgina
378
v Sintaxis de las declaraciones de referencia de archivos LOB en REXX en
la pgina 379
Nombres de variables del lenguaje principal en REXX
Cualquier variable de REXX correctamente denominada se puede utilizar
como variable del lenguaje principal. Un nombre de variable puede tener una
longitud mxima de 64 caracteres. No termine el nombre con un punto. Un
nombre de variable del lenguaje principal puede constar de caracteres
alfabticos, numricos y los caracteres @, _, !, ., ? y $.
Referencias a variables del lenguaje principal en REXX
El intrprete de REXX examina cada serie que no tiene comillas de un
procedimiento. Si la serie representa a una variable en la agrupacin actual de
variables de REXX, ste sustituye la serie por el valor actual. A continuacin
se muestra un ejemplo de cmo se puede hacer referencia a una variable del
lenguaje principal en REXX:
CALL SQLEXEC FETCH C1 INTO :cm
SAY Commission = cm
Para asegurarse de que una serie de caracteres no se convierta a un tipo de
datos numrico, encierre la serie entre comillas tal como en el ejemplo
siguiente:
VAR = 100
REXX establece la variable VAR en la serie de caracteres de 3 bytes 100. Si se
tienen que incluir comillas como parte de la serie, siga este ejemplo:
VAR = "100"
Cuando se insertan datos numricos en un campo de tipo CHARACTER, el
intrprete de REXX trata los datos numricos como datos enteros, por lo que
deber concatenar explcitamente las series numricas y encerrarlas entre
comillas.
Variables de indicador en REXX
El tipo de datos de una variable de indicador en REXX es un nmero sin
coma decimal. A continuacin se muestra un ejemplo de variable de indicador
en REXX que utiliza la palabra clave INDICATOR.
CALL SQLEXEC FETCH C1 INTO :cm INDICATOR :cmind
IF ( cmind < 0 )
SAY Commission is NULL
En el ejemplo anterior, se examina que cmind tenga un valor negativo. Si no es
negativo, la aplicacin puede utilizar el valor devuelto de cm. Si es negativo, el
valor captado es NULL y no se debe utilizar cm. En este caso, el gestor de
bases de datos no cambia el valor de la variable del lenguaje principal.
Variables de REXX predefinidas
SQLEXEC, SQLDBS y SQLDB2 establecen variables de REXX predefinidas
como consecuencia de determinadas operaciones. Estas variables son:
RESULT
Cada operacin establece este cdigo de retorno. Los valores posibles
son:
n Donde n es un valor positivo que indica el nmero de bytes
de un mensaje formateado. La API GET ERROR MESSAGE
sola devuelve este valor.
0 Se ha ejecutado la API. La SQLCA de la variable de REXX
contiene el estado de terminacin de la API. Si
SQLCA.SQLCODE es distinto de cero, SQLMSG contiene el
mensaje de texto asociado a este valor.
1 No se dispone de suficiente memoria para completar la API.
No se ha devuelto el mensaje solicitado.
2 SQLCA.SQLCODE se establece en 0. No se ha devuelto
ningn mensaje.
3 SQLCA.SQLCODE contena un SQLCODE que no era vlido.
No se ha devuelto ningn mensaje.
6 No se ha podido crear la variable SQLCA de REXX. Esto
indica que no haba suficiente memoria disponible o que la
agrupacin de variables de REXX no estaba disponible por
algn motivo.
7 No se ha podido crear la variable SQLMSG de REXX. Esto
indica que no haba suficiente memoria disponible o que la
agrupacin de variables de REXX no estaba disponible por
algn motivo.
8 No se ha podido captar la variable SQLCA.SQLCODE de
REXX de la agrupacin de variables de REXX.
9 La variable SQLCA.SQLCODE de REXX se ha truncado
durante la captacin. La longitud mxima para esta variable
es de 5 bytes.
10 La variable SQLCA.SQLCODE de REXX no se ha podido
convertir de ASCII a un entero largo vlido.
11 No se ha podido captar la variable SQLCA.SQLERRML de
12 La variable SQLCA.SQLERRML de REXX se ha truncado
es de 2 bytes.
13 La variable SQLCA.SQLERRML de REXX no se ha podido
convertir de ASCII a un entero corto vlido.
14 No se ha podido captar la variable SQLCA.SQLERRMC de
15 La variable SQLCA.SQLERRMC de REXX se ha truncado
es de 70 bytes.
16 No se ha podido establecer la variable de REXX especificada
para el texto del error.
17 No se ha podido captar la variable SQLCA.SQLSTATE de
18 La variable SQLCA.SQLSTATE de REXX se ha truncado
es de 2 bytes.
Nota: los valores 8 a 18 slo los devuelve la API GET ERROR
MESSAGE.
SQLMSG
Si SQLCA.SQLCODE es distinto de cero, esta variable contiene el
mensaje de texto asociado al cdigo de error.
SQLISL
Nivel de aislamiento. Los valores posibles son:
RR Lectura repetible.
RS Estabilidad de lectura.
CS Estabilidad del cursor. ste es el valor por omisin.
UR Lectura no confirmada.
NC Sin confirmacin. (NC slo recibe soporte de algunos
servidores de sistema principal, AS/400 o iSeries.)
SQLCA
La estructura SQLCA actualizada despus de que se procesen las
sentencias de SQL y se llame a las API de DB2.
SQLRODA
La estructura SQLDA de entrada/salida para procedimientos
almacenados invocados mediante la sentencia CALL. Tambin es la
estructura SQLDA de salida para procedimientos almacenados
invocados mediante la API Database Application Remote Interface
(DARI).
SQLRIDA
La estructura SQLDA de entrada para procedimientos almacenados
invocados mediante la API Database Application Remote Interface
(DARI).
SQLRDAT
Una estructura SQLCHAR para procedimientos de servidor invocados
mediante la API Database Application Remote Interface (DARI).
v SQLCHAR en el manual Administrative API Reference
Variables del lenguaje principal de LOB en REXX
Cuando se capte una columna LOB en una variable del lenguaje principal
REXX, esta se almacenar como una serie simple (es decir, descontada). Esto
se maneja del mismo modo que todos los tipos de SQL basados en caracteres
(tales como CHAR, VARCHAR, GRAPHIC, LONG, etc.). En la entrada, si el
tamao del contenido de la variable del lenguaje principal es superior a 32 K,
o si cumple con otros criterios establecidos ms adelante, se le asignar el tipo
de LOB apropiado.
En SQL de REXX, los tipos de SQL se determinan a partir del contenido de la
serie de la variable del lenguaje principal, del modo siguiente:
Contenido de la serie de variable del lenguaje principal Tipo de LOB resultante
:hv1=serie normal entre comillas de ms de 32 K ... CLOB
:hv2=serie con comillas de delimitacin incorporadas ,
de ms de 32 K...
CLOB
:hv3=Gserie DBCS con comillas de delimitacin incorporadas, ,
que empieza por G, de ms de 32 K...
DBCLOB
:hv4=BINserie con comillas de delimitacin incorporadas, ,
que empieza por BIN, de cualquier longitud...
BLOB
Sintaxis de las declaraciones de localizador de LOB en REXX
principal de localizador de LOB en REXX:
Sintaxis de las variables del lenguaje principal de localizador de LOB en REXX

,
DECLARE : nombre-variable LANGUAGE TYPE BLOB LOCATOR
CLOB
DBCLOB
Debe declarar las variables del lenguaje principal de localizador de LOB en la

aplicacin. Cuando REXX/SQL encuentra estas declaraciones, trata las
variables del lenguaje principal declaradas como localizadores durante el resto
del programa. Los valores de localizadores se almacenan en variables de
REXX, en un formato interno.
Ejemplo:
CALL SQLEXEC DECLARE :hv1, :hv2 LANGUAGE TYPE CLOB LOCATOR
Los datos representados por localizadores de LOB devueltos por el
mecanismo se pueden liberar en REXX/SQL mediante la sentencia FREE
LOCATOR, que tiene el formato siguiente:
Sintaxis de la sentencia FREE LOCATOR

,
FREE LOCATOR : nombre-variable
Ejemplo:
CALL SQLEXEC FREE LOCATOR :hv1, :hv2
Sintaxis de las declaraciones de referencia de archivos LOB en REXX
Debe declarar las variables del lenguaje principal de referencia de archivos
LOB en la aplicacin. Cuando REXX/SQL encuentra estas declaraciones, trata
las variables del lenguaje principal declaradas como referencias de archivos
LOB durante el resto del programa.
principal de referencia de archivos LOB en REXX:
Declaraciones de referencia de archivos en REXX

,
DECLARE : nombre-variable LANGUAGE TYPE BLOB FILE
CLOB
DBCLOB

Ejemplo:
CALL SQLEXEC DECLARE :hv3, :hv4 LANGUAGE TYPE CLOB FILE
Las variables de referencia de archivos en REXX contienen tres campos. Para
el ejemplo anterior, stos son:
hv3.FILE_OPTIONS.
Establecido por la aplicacin para indicar cmo se utilizar el archivo.
hv3.DATA_LENGTH.
Establecido por DB2 para indicar el tamao del archivo.
hv3.NAME.
Establecido por la aplicacin con el nombre del archivo LOB.
Para FILE_OPTIONS, la aplicacin establece las palabras clave siguientes:
Palabra clave (valor entero)
Significado
READ (2) El archivo se va a utilizar como entrada. Se trata de un
archivo normal que se puede abrir, leer y cerrar. La longitud
de los datos del archivo (en bytes) se calcula (lo hace el
cdigo solicitante de la aplicacin) al abrir el archivo.
CREATE (8) En la salida, crear un nuevo archivo. Si el archivo ya existe, es
un error. La longitud (en bytes) del archivo se devuelve en el
campo DATA_LENGTH de la estructura de la variable de
referencia de archivos.
OVERWRITE (16)
En la salida, se sobregraba el archivo, si ya existe; de lo
contrario, se crea un nuevo archivo. La longitud (en bytes) del
archivo se devuelve en el campo DATA_LENGTH de la estructura
de la variable de referencia de archivos.
APPEND (32) La salida se aade al archivo, si existe; de lo contrario, se crea
un nuevo archivo. La longitud (en bytes) de los datos que se
han aadido al archivo (y no la longitud total del archivo) se
devuelve en el campo DATA_LENGTH de la estructura de la
variable de referencia de archivos.
Nota: una variable del lenguaje principal de referencia de archivos es una
variable compuesta en REXX, por lo que debe establecer valores para
los campos NAME, NAME_LENGTH y FILE_OPTIONS adems de declararlas.
Borrado de variables del lenguaje principal de LOB en REXX
En plataformas basadas en Windows, puede ser necesario borrar
explcitamente las declaraciones de variables del lenguaje principal de
referencia de archivos y de localizador de LOB de SQL de REXX, puesto que
permanecen en vigor una vez que finaliza el programa de aplicacin. Esto es
debido a que el proceso de la aplicacin no sale hasta que se cierra la sesin
en la que se ejecuta. Si no se borran las declaraciones de LOB del SQL para
REXX, pueden interferir con otras aplicaciones que se ejecuten en la misma
sesin despus de que se haya ejecutado una aplicacin de LOB.
La sintaxis para borrar la declaracin es:
CALL SQLEXEC "CLEAR SQL VARIABLE DECLARATIONS"
Debe codificar esta sentencia al final de las aplicaciones de LOB. Observe que
la puede codificar en cualquier lugar, como medida de precaucin, para
borrar las declaraciones que puedan haber quedado de aplicaciones anteriores
(por ejemplo, al principio de una aplicacin SQL en REXX).
Cursores en REXX
Cuando se declara un cursor en REXX, el cursor se asocia a una consulta. La
consulta se asocia a un nombre de sentencia asignado en la sentencia
PREPARE. Cualquier variable del lenguaje principal a la que se haga
referencia se representa mediante marcadores de parmetros. El siguiente
ejemplo muestra una sentencia DECLARE asociada a una sentencia SELECT
dinmica:
prep_string = "SELECT TABNAME FROM SYSCAT.TABLES WHERE TABSCHEMA = ?"
CALL SQLEXEC PREPARE S1 FROM :prep_string;
CALL SQLEXEC DECLARE C1 CURSOR FOR S1;
CALL SQLEXEC OPEN C1 USING :schema_name;
Tipos de datos SQL soportados en REXX
Determinados tipos de datos de REXX predefinidos corresponden a tipos de
columna de DB2. La tabla siguiente muestra cmo SQLEXEC y SQLDBS
interpretan variables de REXX para convertir su contenido en tipos de datos
de DB2.
Tabla 18. Tipos de columna de SQL correlacionados con declaraciones de REXX
Tipo de columna SQL
1
Tipo de datos de REXX Descripcin del tipo de columna
SQL
SMALLINT (500 501) Un nmero sin coma decimal que va
de -32 768 a 32 767
INTEGER
(496 497)
Un nmero sin coma decimal que va
de -2 147 483 648 a 2 147 483 647
Tabla 18. Tipos de columna de SQL correlacionados con declaraciones de REXX (continuacin)
Tipo de columna SQL
1
SQL
REAL
2
(480 481)
Un nmero en notacin cientfica que
va de -3.40282346 x 10
38
a 3.40282346
x 10
38
Coma flotante de precisin nica
DOUBLE
3
(480 481)
Un nmero en notacin cientfica que
va de -1.79769313 x 10
308
a 1.79769313
x 10
308
Coma flotante de precisin doble
DECIMAL(p,s)(484 485) Un nmero con una coma decimal Decimal empaquetado
CHAR(n)
(452 453)
Una serie con una comilla inicial y
otra final (), cuya longitud es n
despus de eliminar las dos comillas
Una serie de longitud n sin ningn
carcter no numrico, aparte de los
blancos inicial y final o la E en
notacin cientfica
con longitud n, donde n va de 1 a 254
VARCHAR(n)
(448 449)
Equivalente a CHAR(n) Serie de caracteres de longitud
variable con longitud n, donde n va
de 1 a 4000
LONG VARCHAR
(456 457)
variable con longitud n, donde n va
de 1 a 32 700
CLOB(n)
(408 409)
variable y de objeto grande con
longitud n, donde n va de 1 a
2 147 483 647
4
(964 965)
DECLARE :nombre_var LANGUAGE
TYPE CLOB LOCATOR
Identifica las entidades CLOB que
residen en el servidor
CLOB
4
(920 921)
TYPE CLOB FILE
Descriptor de archivo que contiene
datos CLOB
BLOB(n)
(404 405)
Una serie con un apstrofo inicial y
uno final, precedida de BIN, que
contiene n caracteres despus de
eliminar el BIN precedente y los dos
apstrofos.
Serie binaria de longitud variable y
de objeto grande con longitud n,
donde n va de 1 a 2 147 483 647
4
(960 961)
TYPE BLOB LOCATOR
Identifica las entidades BLOB del
servidor
BLOB
4
(916 917)
TYPE BLOB FILE
Descriptor del archivo que contiene
datos BLOB
DATE (384 385) Equivalente a CHAR(10) Serie de caracteres de 10 bytes
TIME (388 389) Equivalente a CHAR(8) Serie de caracteres de 8 bytes
TIMESTAMP (392 393) Equivalente a CHAR(26) Serie de caracteres de 26 bytes
Nota: los tipos de datos siguientes slo estn disponibles en el entorno DBCS.
Tabla 18. Tipos de columna de SQL correlacionados con declaraciones de REXX (continuacin)
Tipo de columna SQL
1
SQL
GRAPHIC(n)
(468 469)
Una serie con un apstrofo inicial y
uno final, precedida de una G o una
N, que contiene n caracteres DBCS
despus de eliminar el carcter
precedente y los dos apstrofos
Serie grfica de longitud fija con
VARGRAPHIC(n)
(464 465)
Equivalente a GRAPHIC(n) Serie grfica de longitud variable con
LONG VARGRAPHIC
(472 473)
Equivalente a GRAPHIC(n) Serie grfica de longitud variable
larga con longitud n, donde n va de 1
a 16 350
DBCLOB(n)
(412 413)
Equivalente a GRAPHIC(n) Serie grfica de longitud variable y de
objeto grande con longitud n, donde
n va de 1 a 1 073 741 823
4
(968 969)
TYPE DBCLOB LOCATOR
Identifica las entidades DBCLOB que
residen en el servidor
Variable de referencia de archivos
DBCLOB
4
(924 925)
TYPE DBCLOB FILE
Descriptor de archivo que contiene
datos DBCLOB
Notas:
indicador para indicar los valores nulos (NULL) o para contener la longitud de una serie truncada.
v FLOAT
v DOUBLE PRECISION
v Cursores en REXX en la pgina 381
Requisitos de ejecucin para REXX
Las siguientes secciones describen los requisitos de ejecucin para aplicaciones
REXX.
Creacin y ejecucin de aplicaciones REXX
Las aplicaciones REXX no se precompilan, compilan ni enlazan. Las
instrucciones siguientes describen cmo crear y ejecutar aplicaciones REXX en
sistemas operativos Windows y en el sistema operativo AIX.
Restricciones:
En plataformas basadas en Windows, el archivo de aplicacin debe tener una
extensin .CMD. Despus de su creacin, puede ejecutar la aplicacin
directamente desde el indicador de mandatos del sistema operativo. En AIX,
el archivo de la aplicacin puede tener cualquier extensin.
Procedimiento:
Cree y ejecute las aplicaciones REXX del siguiente modo:
v En sistemas operativos Windows, el archivo de aplicacin puede tener
cualquier nombre. Despus de su creacin, puede ejecutar la aplicacin
desde el indicador de mandatos del sistema operativo invocando al
intrprete de REXX del modo siguiente:
REXX file_name
v En AIX, puede ejecutar la aplicacin mediante cualquiera de los dos
mtodos siguientes:
En el indicador de mandatos de shell, escriba rexx name donde name es el
nombre del programa REXX.
Si la primera lnea del programa REXX contiene un nmero mgico (#!)
e identifica el directorio en que reside el intrprete de REXX/6000, puede
ejecutar el programa REXX escribiendo su nombre en el indicador de
mandatos del shell. Por ejemplo, si el archivo del intrprete de
REXX/6000 est en el directorio /usr/bin, incluya la informacin
siguiente como primera lnea del programa REXX:
#! /usr/bin/rexx
A continuacin, haga que el programa sea ejecutable escribiendo el
mandato siguiente en el indicador de mandatos del shell:
chmod +x name
Ejecute el programa REXX escribiendo su nombre de archivo en el
indicador de mandatos del shell.
Nota: en AIX, debe establecer la variable de entorno LIBPATH para incluir
el directorio en que est ubicada la biblioteca de SQL para REXX,
db2rexx. Por ejemplo:
export LIBPATH=/lib:/usr/lib:/usr/lpp/db2_08_01/lib
Archivos de vinculacin de REXX
Se proporcionan cinco archivos de vinculacin para el soporte de aplicaciones
REXX. Los nombres de estos archivos estn incluidos en el archivo
DB2UBIND.LST. Cada archivo de vinculacin se ha precompilado utilizando
un nivel de aislamiento distinto; por consiguiente, en la base de datos hay
cinco paquetes diferentes almacenados.
Los cinco archivos de vinculacin son:
DB2ARXCS.BND
Soporta el nivel de aislamiento de estabilidad del cursor.
DB2ARXRR.BND
Soporta el nivel de aislamiento de estabilidad de lectura repetible.
DB2ARXUR.BND
Soporta el nivel de aislamiento de estabilidad de lectura no
confirmada.
DB2ARXRS.BND
Soporta el nivel de aislamiento de estabilidad de lectura.
DB2ARXNC.BND
Soporta el nivel de aislamiento de sin confirmacin. Se utiliza este
nivel de aislamiento cuando se trabaja con algunos servidores de
bases de datos de sistema principal, AS/400 o iSeries. En otras bases
de datos, se comporta como el nivel de aislamiento de lectura no
confirmada.
Nota: en algunos casos, puede que sea necesario vincular de forma explcita
estos archivos a la base de datos.
Cuando se utiliza la rutina SQLEXEC se usa, por omisin, el paquete creado
con estabilidad del cursor. Si necesita uno de los otros niveles de aislamiento,
lo puede cambiar mediante la API SQLDBS CHANGE SQL ISOLATION
LEVEL antes de conectar con la base de datos. Esto ocasionar que las
posteriores llamadas a la rutina SQLEXEC se asocien al nivel de aislamiento
especificado.
Las aplicaciones REXX basadas en Windows no pueden asumir que est en
vigor el nivel de aislamiento por omisin a menos que sepan que ningn otro
programa REXX de la sesin ha cambiado el valor. Antes de conectar con una
base de datos, una aplicacin REXX debe establecer explcitamente el nivel de
aislamiento.
Sintaxis de las API para REXX
Utilice la rutina SQLDBS para llamar a las API de DB2 con la sintaxis
siguiente:
CALL SQLDBS command string
Si no puede llamar a una API de DB2 que desea utilizar mediante la rutina
SQLDBS, puede llamar a la API efectuando una llamada al procesador de
lnea de mandatos (CLP) de DB2 desde dentro de la aplicacin REXX. Sin
embargo, puesto que el CLP de DB2 dirige la salida al dispositivo de salida
estndar o a un archivo especificado, la aplicacin REXX no puede acceder
directamente a la salida de la API de DB2 a la que se ha llamado, ni puede
tomar fcilmente la determinacin de si la API llamada ha resultado
satisfactoria o no. La API SQLDB2 proporciona una interfaz con el CLP de
DB2 que proporciona informacin directa a la aplicacin REXX sobre el xito o
fracaso de cada API llamada, estableciendo la variable compuesta SQLCA de
REXX despus de cada llamada.
Puede utilizar la rutina SQLDB2 para llamar a las API de DB2 utilizando la
sintaxis siguiente:
CALL SQLDB2 command string
donde command string es una serie que puede procesar el procesador de
lnea de mandatos (CLP).
El hecho de llamar a una API de DB2 mediante SQLDB2 es equivalente a
llamar directamente al CLP, excepto en los aspectos siguientes:
v La llamada al ejecutable del CLP se sustituye por la llamada a SQLDB2 (el
resto de opciones y parmetros del CLP se especifican de la misma
manera).
v La variable compuesta SQLCA de REXX se establece despus de llamar a
SQLDB2, pero no se establece despus de llamar al ejecutable del CLP.
v La salida de visualizacin por omisin del CLP se establece como
desactivada cuando se llama a SQLDB2, mientras que se establece como
salida activada cuando se llama al ejecutable del CLP. Observe que puede
activar la salida de visualizacin del CLP pasando las opciones +o o o a
SQLDB2.
Puesto que la nica variable de REXX que se establece despus de llamar a
SQLDB2 es la SQLCA, slo debe utilizar esta rutina para llamar a las API de
DB2 que no devuelvan datos distintos de la SQLCA y que no estn
implementadas actualmente mediante la interfaz SQLDBS. As pues, SQLDB2
nicamente soporta las API de DB2 siguientes:
v Activar base de datos
v Aadir nodo
v Vincular para DB2 Versin 1
(1) (2)
v Vincular para DB2 Versin 2 5
(1)
v Crear base de datos en nodo
v Eliminar base de datos en nodo
v Verificar eliminacin de nodo
v Desactivar base de datos
v Desregistrar
v Cargar
(3)
v Cargar consulta
v Precompilar programa
(1)
v Revincular paquete
(1)
v Redistribuir grupo de particiones de base de datos
v Registrar
v Iniciar gestor de la base de datos
v Detener gestor de la base de datos
Notas sobre las API de DB2 soportadas por SQLDB2:
1. Estos mandatos requieren una sentencia CONNECT a travs de la interfaz
SQLDB2. Las conexiones que utilizan la interfaz SQLDB2 no estn
accesibles para la interfaz SQLEXEC, y las conexiones que utilizan la
interfaz SQLEXEC no estn accesible para la interfaz SQLDB2.
2. Se soporta en plataformas basadas en Windows mediante la interfaz
SQLDB2.
3. El parmetro de salida opcional, pLoadInfoOut para la API Cargar no se
devuelve a la aplicacin en REXX.
Nota: aunque la rutina SQLDB2 ha sido pensada para uso nicamente de las
API de DB2 relacionadas anteriormente, tambin se puede utilizar para
otras API de DB2 que no se soportan a travs de la rutina SQLDBS.
Alternativamente, se puede acceder a las API de DB2 a travs del CLP
desde la aplicacin REXX.
Llamada a procedimientos almacenados desde REXX
Las secciones siguientes describen cmo llamar a procedimientos almacenados
desde aplicaciones REXX.
Procedimientos almacenados en REXX
Las aplicaciones SQL de REXX pueden llamar a procedimientos almacenados
que se encuentren en el servidor de base de datos utilizando la sentencia
CALL de SQL. El procedimiento almacenado puede estar escrito en cualquier
lenguaje soportado en dicho servidor, a excepcin de REXX en los sistemas
AIX. (Las aplicaciones cliente pueden estar escritas en REXX en los sistemas
AIX, pero, al igual que en otros lenguajes, no pueden llamar a un
procedimiento almacenado escrito en REXX en AIX.)
v Llamadas a procedimientos almacenados en REXX en la pgina 387
Llamadas a procedimientos almacenados en REXX
La sentencia CALL permite que una aplicacin cliente pase datos a un
procedimiento almacenado en un servidor, y reciba datos del mismo. La
interfaz para los datos tanto de entrada como de salida es una lista de
variables del lenguaje principal. Puesto que REXX suele determinar el tipo y
el tamao de las variables del lenguaje principal en base a su contenido, las
variables que sean slo de salida y se pasen a CALL se deben inicializar con
datos ficticios, parecidos en tipo y tamao a la salida esperada.
Tambin se pueden pasar datos a los procedimientos almacenados a travs de
las variables SQLDA de REXX, mediante la sintaxis USING DESCRIPTOR de
la sentencia CALL. La tabla siguiente muestra cmo se establece el SQLDA.
En la tabla, ':value' es la raz de una variable del lenguaje principal REXX que
contiene los valores necesarios para la aplicacin. Para DESCRIPTOR, 'n' es un
valor numrico que indica un elemento sqlvar especfico del SQLDA. Los
nmeros que aparecen a la derecha hacen referencia a las notas que siguen a
la tabla.
Tabla 19. SLQDA de REXX de la parte cliente para procedimientos almacenados que utilizan la sentencia
CALL
USING DESCRIPTOR :value.SQLD 1
:value.n.SQLTYPE 1
:value.n.SQLLEN 1
:value.n.SQLDATA 1 2
:value.n.SQLDIND 1 2
Notas:
1. Antes de invocar al procedimiento almacenado, la aplicacin cliente tiene
que inicializar la variable de REXX con los datos apropiados.
Cuando se ejecuta la sentencia CALL de SQL, el gestor de bases de datos
asigna almacenamiento y recupera el valor de la variable de REXX de la
agrupacin de variables de REXX. Para una SQLDA utilizada en una
sentencia CALL, el gestor de bases de datos asigna almacenamiento para
los campos SQLDATA y SQLIND en base a los valores de SQLTYPE y
SQLLEN.
En el caso de un procedimiento almacenado REXX (es decir, en que el
procedimiento al que se llama est escrito en REXX basado en Windows),
los datos pasados por el cliente del tipo de sentencia CALL o de la API
DARI se colocan en la agrupacin de variables de REXX en el servidor de
base de datos, utilizando los nombres siguientes predefinidos:
SQLRIDA
Nombre predefinido para la variable SQLDA de entrada de REXX
SQLRODA
Nombre predefinido para la variable SQLDA de salida de REXX
2. Cuando termina el procedimiento almacenado, el gestor de bases de datos
recupera tambin el valor de las variables del procedimiento almacenado.
Los valores se devuelven a la aplicacin cliente y se colocan en la
agrupacin de variables de REXX del cliente.
v Consideraciones del cliente para llamar a procedimientos almacenados en
REXX en la pgina 389
v Consideraciones del servidor para llamar a procedimientos almacenados
en REXX en la pgina 389
v Recuperacin de valores de precisin y escala (SCALE) de campos
decimales del SQLDA en la pgina 390
v CALL sentencia en el manual Consulta de SQL, Volumen 2
Consideraciones del cliente para llamar a procedimientos almacenados
en REXX
Cuando utilice variables del lenguaje principal en la sentencia CALL, inicialice
cada una de las variables del lenguaje principal con un valor que sea de un
tipo compatible con los datos que se devuelvan a la variable del lenguaje
principal desde el procedimiento del servidor. Debe realizar esta inicializacin
aunque el indicador correspondiente sea negativo.
Cuando utilice descriptores, SQLDATA debe estar inicializada y contener
datos que sean de un tipo compatible con los datos que se devuelvan desde el
procedimiento del servidor. Debe realizar esta inicializacin aunque el campo
SQLIND contenga un valor negativo.
Consideraciones del servidor para llamar a procedimientos almacenados
en REXX
Asegrese de que todos los campos SQLDATA y SQLIND (si es de un tipo
anulable) de la SQLRODA de SQLDA de salida predefinida estn
inicializados. Por ejemplo, si SQLRODA.SQLD es 2, los campos siguientes
deben contener datos (aunque los indicadores correspondientes sean negativos
y no se pasen datos al cliente):
v SQLRODA.1.SQLDATA
v SQLRODA.2.SQLDATA
Recuperacin de valores de precisin y escala (SCALE) de campos
decimales del SQLDA
Para recuperar los valores de precisin y escala para campos decimales de la
estructura SQLDA devuelta por el gestor de bases de datos, utilice los valores
sqllen.scale y sqllen.precision cuando inicialice la salida del SQLDA en el
programa REXX. Por ejemplo:
.
.
.
/* INICIALIZAR UN ELEMENTO DE SQLDA DE SALIDA */
io_sqlda.sqld = 1
io_sqlda.1.sqltype = 485 /* TIPO DE DATOS DECIMAL */
io_sqlda.1.sqllen.scale = 2 /* DGITOS A LA DERECHA DE LA COMA DECIMAL */
io_sqlda.1.sqllen.precision = 7 /* ANCHURA DEL DECIMAL */
io_sqlda.1.sqldata = 00000.00 /* FORMATO DE DATOS DE DEFINICIN DE AYUDAS */
io_sqlda.1.sqlind = -1 /* SIN DATOS DE ENTRADA */
.
.
.
Captulo 14. Cmo escribir aplicaciones mediante IBM OLE
DB Provider para servidores DB2
Objetivo de IBM OLE DB Provider para DB2 391
Tipos de aplicaciones soportados por IBM
OLE DB Provider para DB2 . . . . . . 393
Servicios OLE DB. . . . . . . . . . 393
Modelo de hebras soportado por IBM
OLE DB Provider . . . . . . . . . 393
Manipulacin de objetos grandes con IBM
OLE DB Provider . . . . . . . . . 393
Conjuntos de filas de esquema soportados
por IBM OLE DB Provider . . . . . . 393
Habilitacin automtica de servicios OLE
DB por parte de IBM OLE DB Provider . 396
Servicios de datos. . . . . . . . . . 396
Modalidades de cursor soportadas en
IBM OLE DB Provider . . . . . . . 396
Correlaciones de tipos de datos entre DB2
y OLE DB . . . . . . . . . . . 396
de tipos OLE DB en tipos DB2 . . . . 398
de tipos DB2 en tipos OLE DB . . . . 400
Restricciones de IBM OLE DB Provider . . 402
interfaces y componentes de OLE DB . . . 403
Soporte de IBM OLE DB de propiedades de
OLE DB . . . . . . . . . . . . . 406
Conexiones a fuentes de datos mediante IBM
OLE DB Provider . . . . . . . . . . 409
Aplicaciones ADO . . . . . . . . . 410
Palabras clave de series de conexin de
ADO . . . . . . . . . . . . . 410
Conexiones con fuentes de datos con
aplicaciones ADO Visual Basic . . . . 410
aplicaciones ADO . . . . . . . . . 411
Limitaciones de las aplicaciones ADO . . 411
propiedades y mtodos ADO . . . . . 411
Aplicaciones C y C++ . . . . . . . . 416
Compilacin y enlace de aplicaciones
C/C++ e IBM OLE DB Provider . . . . 416
Conexiones con fuentes de datos en
aplicaciones C/C++ mediante IBM OLE
DB Provider . . . . . . . . . . 416
aplicaciones ATL e IBM OLE DB Provider 417
Transacciones distribuidas MTS y COM+ 417
Soporte de transacciones distribuidas
MTS y COM+ e IBM OLE DB Provider . 417
Habilitacin del soporte de MTS en DB2
Universal Database para aplicaciones
C/C++ . . . . . . . . . . . . 418
Objetivo de IBM OLE DB Provider para DB2
Microsoft OLE DB es un conjunto de interfaces OLE/COM que proporciona a
las aplicaciones acceso uniforme a datos almacenados en distintas fuentes de
informacin. La arquitectura OLE DB define consumidores de OLE DB y
proveedores de OLE DB. Un consumidor de OLE DB es cualquier sistema o
aplicacin que utiliza interfaces OLE DB; un proveedor de OLE DB es un
componente que expone las interfaces OLE DB.
IBM OLE DB Provider para DB2 permite a DB2 actuar como gestor de
recursos para el proveedor de OLE DB. Este soporte ofrece a las aplicaciones
basadas en OLE DB la posibilidad de extraer o consultar datos de DB2
mediante la interfaz OLE. IBM OLE DB Provider para DB2, cuyo nombre de
proveedor es IBMDADB2, permite a los consumidores de OLE DB acceder a
datos en un servidor DB2 Universal Database. Si DB2 Connect est instalado,
estos consumidores de OLE DB tambin pueden acceder a datos en sistemas
principales DBMS como DB2 para MVS, DB2 para VM/VSE o SQL/400.
IBM OLE DB Provider para DB2 ofrece las siguientes funciones:
v Nivel de soporte 0 de la especificacin de proveedor de OLE DB, incluidas
algunas interfaces adicionales de nivel 1.
v Una implantacin del proveedor de hebras libres, que permite a la
aplicacin crear componentes en una hebra y utilizar dichos componentes
en cualquier otra hebra.
v Un Servicio de bsqueda de errores que devuelve mensajes de error de
DB2.
Tenga en cuenta que IBM OLE DB Provider reside en el cliente y es distinto
de las funciones de tabla de OLE DB, que tambin reciben soporte de DB2
UDB.
Las siguientes secciones de este documento describen la implantacin
especfica de IBM OLE DB Provider para DB2. Para obtener ms informacin
sobre la especificacin OLE DB 2.0 de Microsoft, consulte el manual Microsoft
OLE DB 2.0 Programmers Reference and Data Access SDK, disponible en
Microsoft Press.
Cumplimiento de versiones:
IBM OLE DB Provider para DB2 cumple con la Versin 2.5 de la
especificacin OLE DB de Microsoft.
Requisitos del sistema:
Consulte la carta de anuncio correspondiente a IBM OLE DB Provider para
DB2 Servers para ver los sistemas operativos Windows soportados.
Para instalar IBM OLE DB Provider para DB2, primero tiene que ejecutar uno
de los sistemas operativos soportados mencionados anteriormente. Tambin
tiene que instalar DB2 Application Development Client, as como Microsoft
Data Access Components (MDAC) Versin 2.7, o superior, que estaba
disponible en el momento de escribir este documento en el siguiente sitio:
http://www.microsoft.com/data.
v Soporte de IBM OLE DB Provider de interfaces y componentes de OLE
DB en la pgina 403
Tipos de aplicaciones soportados por IBM OLE DB Provider para DB2
Con IBM OLE DB Provider para DB2, puede crear los siguientes tipos de
aplicaciones:
v Aplicaciones ADO, que incluyen:
Aplicaciones Microsoft Visual Studio C++
Aplicaciones Microsoft Visual Basic
v Aplicaciones C/C++ que acceden a IBMDADB2 directamente mediante las
interfaces OLE DB, incluidas aplicaciones ATL cuyos Objetos de consumidor
de acceso a datos se han generado mediante ATL COM AppWizard.
Servicios OLE DB
Las secciones siguientes describen los servicios OLE DB.
Modelo de hebras soportado por IBM OLE DB Provider
IBM OLE DB Provider para DB2 da soporte al modelo de hebras libres, que
permite a las aplicaciones crear componentes en una hebra y utilizar dichos
componentes en cualquier otra hebra.
Manipulacin de objetos grandes con IBM OLE DB Provider
Para obtener y establecer datos como objetos de almacenamiento
(DBTYPE_IUNKNOWN) con IBMDADB2, utilice la interfaz ISequentialStream
del siguiente modo:
v Para vincular un objeto de almacenamiento a un parmetro, DBOBJECT en
la estructura DBBINDING slo puede contener el valor STGM_READ para
el campo dwFlag. IBMDADB2 ejecutar el mtodo Read de la interfaz
ISequentialStream del objeto vinculado.
v Para obtener datos de un objeto de almacenamiento, la aplicacin debe
ejecutar un mtodo Read en la interfaz ISequentialStream del objeto de
almacenamiento.
v Cuando se obtienen datos, el valor de la parte de longitud es la longitud de
los datos reales, no la longitud del puntero IUnknown.
Conjuntos de filas de esquema soportados por IBM OLE DB Provider
La tabla siguiente muestra los conjuntos de filas de esquema soportados por
IDBSchemaRowset. Tenga que cuenta que las columnas no soportadas se
establecern en nulo en los conjuntos de filas.
Captulo 14. Cmo escribir aplicaciones mediante IBM OLE DB Provider para servidores DB2 393
Tabla 20. Conjuntos de filas soportados por IBM OLE DB Provider para DB2
GUID soportados Restricciones soportadas Columnas soportadas Notas
DBSCHEMA
_COLUMN_PRIVILEGES
COLUMN_NAME
TABLE_NAME
TABLE_SCHEMA
COLUMN_NAME
GRANTEE
GRANTOR
IS_GRANTABLE
PRIVILEGE_TYPE
TABLE_NAME
TABLE_SCHEMA
DB_SCHEMA_COLUMNS COLUMN_NAME
TABLE_NAME
TABLE_SCHEMA
CHARACTER_MAXIMUM_LENGTH
CHARACTER_OCTET_LENGTH
COLUMN_DEFAULT
COLUMN_FLAGS
COLUMN_HASDEFAULT
COLUMN_NAME
DATA_TYPE
DESCRIPTION
IS_NULLABLE
NUMERIC_PRECISION
NUMERIC_SCALE
ORDINAL_POSITION
TABLE_NAME
TABLE_SCHEMA
DBSCHEMA_FOREIGN_KEYS FK_TABLE_NAME
FK_TABLE_SCHEMA
PK_TABLE_NAME
PK_TABLE_SCHEMA
DEFERRABILITY
DELETE_RULE
FK_COLUMN_NAME
FK_NAME
FK_TABLE_NAME
FK_TABLE_SCHEMA
ORDINAL
PK_COLUMN_NAME
PK_NAME
PK_TABLE_NAME
PK_TABLE_SCHEMA
UPDATE_RULE
Se debe especificar al
menos una de las
siguientes restricciones:
PK_TABLE_NAME o
FK_TABLE_NAME
No se permiten
caracteres comodn %.
DBSCHEMA_INDEXES TABLE_NAME
TABLE_SCHEMA
CARDINALITY
CLUSTERED
COLLATION
COLUMN_NAME
INDEX_NAME
INDEX_SCHEMA
ORDINAL_POSITION
PAGES
TABLE_NAME
TABLE_SCHEMA
TYPE
UNIQUE
No se permite ningn
orden de clasificacin. El
orden de clasificacin, si
se especifica, se pasar
por alto.
DBSCHEMA_PRIMARY_KEYS TABLE_NAME
TABLE_SCHEMA
COLUMN_NAME
ORDINAL
PK_NAME
TABLE_NAME
TABLE_SCHEMA
Se debe especificar al
menos la siguiente
restriccin:
TABLE_NAME
No se permiten
caracteres comodn %.
Tabla 20. Conjuntos de filas soportados por IBM OLE DB Provider para DB2 (continuacin)
GUID soportados Restricciones soportadas Columnas soportadas Notas
DBSCHEMA
_PROCEDURE_PARAMETERS
PARAMETER_NAME
PROCEDURE_NAME
PROCEDURE_SCHEMA
CHARACTER_MAXIMUM_LENGTH
CHARACTER_OCTET_LENGTH
DATA_TYPE
DESCRIPTION
IS_NULLABLE
NUMERIC_PRECISION
NUMERIC_SCALE
ORDINAL_POSITION
PARAMETER_DEFAULT
PARAMETER_HASDEFAULT
PARAMETER_NAME
PARAMETER_TYPE
PROCEDURE_NAME
PROCEDURE_SCHEMA
TYPE_NAME
DBSCHEMA_PROCEDURES PROCEDURE_NAME
PROCEDURE_SCHEMA
DESCRIPTION
PROCEDURE_NAME
PROCEDURE_SCHEMA
PROCEDURE_TYPE
DBSCHEMA_PROVIDER_TYPES (NONE) AUTO_UNIQUE_VALUE
BEST_MATCH
CASE_SENSITIVE
CREATE_PARAMS
COLUMN_SIZE
DATA_TYPE
FIXED_PREC_SCALE
IS_FIXEDLENGTH
IS_LONG
IS_NULLABLE
LITERAL_PREFIX
LITERAL_SUFFIX
LOCAL_TYPE_NAME
MINIMUM_SCALE
MAXIMUM_SCALE
SEARCHABLE
TYPE_NAME
UNSIGNED_ATTRIBUTE
DBSCHEMA_STATISTICS TABLE_NAME
TABLE_SCHEMA
CARDINALITY
TABLE_NAME
TABLE_SCHEMA
No se permite ningn
orden de clasificacin. El
orden de clasificacin, si
se especifica, se pasar
por alto.
DBSCHEMA
_TABLE_PRIVILEGES
TABLE_NAME
TABLE_SCHEMA
GRANTEE
GRANTOR
IS_GRANTABLE
PRIVILEGE_TYPE
TABLE_NAME
TABLE_SCHEMA
DBSCHEMA_TABLES TABLE_NAME
TABLE_SCHEMA
TABLE_TYPE
DESCRIPTION
TABLE_NAME
TABLE_SCHEMA
TABLE_TYPE
Habilitacin automtica de servicios OLE DB por parte de IBM OLE DB
Provider
Por omisin, IBM OLE DB Provider para DB2 habilita de forma automtica
todos los servicios OLE DB, aadiendo una entrada de registro
OLEDB_SERVICES bajo el ID de clase (CLSID) del proveedor con el valor
0xFFFFFFFF para DWORD. El significado de este valor es el siguiente:
Tabla 21. Servicios OLE DB
Servicios habilitados Valor de DWORD
Todos los servicios (valor por omisin) 0xFFFFFFFF
Todos excepto agrupacin y AutoEnlistment 0xFFFFFFFE
Todos excepto cursor del cliente 0xFFFFFFFB
Todos excepto agrupacin, alistamiento y cursor 0xFFFFFFF0
Ningn servicio 0x000000000
Servicios de datos
Las secciones siguientes describen consideraciones sobre los servicios de
datos.
Modalidades de cursor soportadas en IBM OLE DB Provider
IBM OLE DB Provider para DB2 da soporte de forma nativa a cursores de
solo lectura y de solo avance, denominados Cursores del servidor. Para cursores
desplazables actualizables, la aplicacin debe utilizar el componente Cursor
Service de OLE DB, conocido como Cursor del cliente. Las aplicaciones OLE
DB nativas tendrn cursores actualizables y desplazables disponibles cuando
se utilicen las interfaces principales de OLE DB IDataInitialize o
IDBPromptInitialize para conectar con la base de datos. Esto se debe a que
estas interfaces activan de forma automtica el componente Cursor Service de
OLE DB.
Correlaciones de tipos de datos entre DB2 y OLE DB
IBM OLE DB Provider da soporte a las correlaciones de tipos de datos entre
tipos de datos DB2 y tipos de datos OLE DB. La tabla siguiente proporciona
una lista completa de correlaciones soportadas y nombres disponibles para
indicar los tipos de datos de columnas y parmetros.
Tabla 22. Correlaciones de tipos de datos entre tipos de datos DB2 y tipos de datos OLE DB
Tipos de
datos DB2
Indicadores de tipos de datos OLE
DB
Nombres de tipos estndar de OLE
DB
Nombres especficos
de DB2
SMALLINT DBTYPE_I2 DBTYPE_I2 SMALLINT
INTEGER DBTYPE_I4 DBTYPE_I4 INTEGER o INT
BIGINT DBTYPE_I8 DBTYPE_I8 BIGINT
REAL DBTYPE_R4 DBTYPE_R4 REAL
FLOAT DBTYPE_R8 DBTYPE_R8 FLOAT
DOUBLE DBTYPE_R8 DBTYPE_R8 DOUBLE o
DOUBLE
PRECISION
DECIMAL DBTYPE_NUMERIC DBTYPE_NUMERIC DEC o DECIMAL
NUMERIC DBTYPE_NUMERIC DBTYPE_NUMERIC NUM o
NUMERIC
DATE DBTYPE_DBDATE DBTYPE_DBDATE DATE
TIME DBTYPE_DBTIME DBTYPE_DBTIME TIME
TIMESTAMP DBTYPE_DBTIMESTAMP DBTYPE_DBTIMESTAMP TIMESTAMP
CHAR DBTYPE_STR DBTYPE_CHAR CHAR o
CHARACTER
VARCHAR DBTYPE_STR DBTYPE_VARCHAR VARCHAR
LONG
VARCHAR
DBTYPE_STR DBTYPE_LONGVARCHAR LONG VARCHAR
CLOB DBTYPE_STR
y DBCOLUMNFLAGS_ISLONG
o DBPARAMFLAGS_ISLONG
DBTYPE_CHAR
DBTYPE_VARCHAR
DBTYPE_LONGVARCHAR
CLOB
GRAPHIC DBTYPE_WSTR DBTYPE_WCHAR GRAPHIC
VARGRAPHIC DBTYPE_WSTR DBTYPE_WVARCHAR VARGRAPHIC
LONG
VARGRAPHIC
DBTYPE_WSTR DBTYPE_WLONGVARCHAR LONG
VARGRAPHIC
DBCLOB DBTYPE_WSTR
DBTYPE_WCHAR
DBTYPE_WVARCHAR
DBTYPE_WLONGVARCHAR
DBCLOB
CHAR(n) FOR
BIT DATA
DBTYPE_BYTES DBTYPE_BINARY
VARCHAR(n)
FOR BIT
DATA
DBTYPE_BYTES DBTYPE_VARBINARY
LONG
VARCHAR
FOR BIT
DATA
DBTYPE_BYTES DBTYPE_LONGVARBINARY
Tabla 22. Correlaciones de tipos de datos entre tipos de datos DB2 y tipos de datos OLE
DB (continuacin)
Tipos de
datos DB2
Indicadores de tipos de datos OLE
DB
Nombres de tipos estndar de OLE
DB
Nombres especficos
de DB2
BLOB DBTYPE_BYTES
DBTYPE_BINARY
DBTYPE_VARBINARY
DBTYPE_LONGVARBINARY
BLOB
DATA LINK DBTYPE_STR DBTYPE_CHAR DATA LINK
Conversin de datos para establecer datos de tipos OLE DB en tipos DB2
IBM OLE DB Provider da soporte a las conversiones de datos para establecer
datos de tipos OLE DB en tipos DB2. Tenga en cuenta que es posible que se
trunquen datos en algunos casos, en funcin de los tipos y del valor de los
datos.
Tabla 23. Conversin de datos de tipos OLE DB a tipos DB2
Indicador de tipo OLE DB
Tipos de datos DB2
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
R
E
A
L
F
L
O
A
T
D
O
U
B
L
E
D
E
C
I
M
A
L
N
U
M
E
R
I
C
D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
C
L
O
B
G
R
A
P
H
I
C
V
A
R
G
R
A
P
H
I
C
L
O
N
G
V
A
R
G
R
A
P
H
I
C
D
B
C
L
O
B
For Bit
Data
B
L
O
B
D
A
T
A
L
I
N
K
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
DBTYPE_EMPTY
DBTYPE_NULL
DBTYPE_RESERVED
DBTYPE_I1 X X X X X X X X
DBTYPE_UI1 X X X X X X X X
Tabla 23. Conversin de datos de tipos OLE DB a tipos DB2 (continuacin)
Tipos de datos DB2
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
R
E
A
L
F
L
O
A
T
D
O
U
B
L
E
D
E
C
I
M
A
L
N
U
M
E
R
I
C
D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
C
L
O
B
G
R
A
P
H
I
C
V
A
R
G
R
A
P
H
I
C
L
O
N
G
V
A
R
G
R
A
P
H
I
C
D
B
C
L
O
B
For Bit
Data
B
L
O
B
D
A
T
A
L
I
N
K
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
DBTYPE_R4 X X X X X X X X
DBTYPE_R8 X X X X X X X X
DBTYPE_CY
DBTYPE_DECIMAL X X X X X X X X
DBTYPE_NUMERIC X X X X X X X X
DBTYPE_DATE
DBTYPE_BOOL X X X X X X X X
DBTYPE_BYTES X X X X X X X X X
DBTYPE_BSTR
por determinar
DBTYPE_STR X X X X X X X X X X X X X X X X X X X
DBTYPE_WSTR X X X
DBTYPE_VARIANT
por determinar
DBTYPE_IDISPATCH
DBTYPE_IUNKNOWN X X X X X X X X X X X
DBTYPE_GUID
DBTYPE_ERROR
DBTYPE_BYREF
DBTYPE_ARRAY
DBTYPE_VECTOR
DBTYPE_UDT
DBTYPE_DBDATE X X X X
DBTYPE_DBTIME X X X X
DBTYPE_DBTIMESTAMP X X X X X
DBTYPE_FILETIME
Tabla 23. Conversin de datos de tipos OLE DB a tipos DB2 (continuacin)
Tipos de datos DB2
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
R
E
A
L
F
L
O
A
T
D
O
U
B
L
E
D
E
C
I
M
A
L
N
U
M
E
R
I
C
D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
C
L
O
B
G
R
A
P
H
I
C
V
A
R
G
R
A
P
H
I
C
L
O
N
G
V
A
R
G
R
A
P
H
I
C
D
B
C
L
O
B
For Bit
Data
B
L
O
B
D
A
T
A
L
I
N
K
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
DBTYPE_PROP_VARIANT
DBTYPE_HCHAPTER
DBTYPE_VARNUMERIC
v Conversin de datos para establecer datos de tipos DB2 en tipos OLE DB
en la pgina 400
Conversin de datos para establecer datos de tipos DB2 en tipos OLE DB
Para obtener datos, IBM OLE DB Provider permite conversiones de datos de
tipos DB2 a tipos OLE DB. Tenga en cuenta que es posible que se trunquen
datos en algunos casos, en funcin de los tipos y del valor de los datos.
Tabla 24. Conversiones de datos de tipos DB2 a tipos OLE DB
Tipos de datos DB2
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
R
E
A
L
F
L
O
A
T
D
O
U
B
L
E
D
E
C
I
M
A
L
N
U
M
E
R
I
C
D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
C
L
O
B
G
R
A
P
H
I
C
V
A
R
G
R
A
P
H
I
C
L
O
N
G
V
A
R
G
R
A
P
H
I
C
D
B
C
L
O
B
For Bit
Data
B
L
O
B
D
A
T
A
L
I
N
K
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
DBTYPE_EMPTY
DBTYPE_NULL
DBTYPE_RESERVED
DBTYPE_I1 X X X X X X X X X X X X X X X
DBTYPE_I8 X X X X X X X X X X X X X X X X
DBTYPE_UI1 X X X X X X X X X X X X X X X
DBTYPE_UI8 X X X X X X X X X X X X X X X X
DBTYPE_R4 X X X X X X X X X X X X X X X
DBTYPE_R8 X X X X X X X X X X X X X X X
DBTYPE_CY X X X X X X X X X X X X X X X
DBTYPE_DECIMAL X X X X X X X X X X X X X X X
DBTYPE_NUMERIC X X X X X X X X X X X X X X X
DBTYPE_DATE X X X X X X X X X X X X X X
DBTYPE_BOOL X X X X X X X X X X X X X X X
DBTYPE_BYTES X X X X X X X X X X X X X X X X X X
DBTYPE_BSTR X X X X X X X X X X X X X X X X X X X
DBTYPE_STR X X X X X X X X X X X X X X X X X X X
DBTYPE_WSTR X X X X X X X X X X X X X X X X X X X
DBTYPE_VARIANT X X X X X X X X X X X X X X X X X X X
DBTYPE_IDISPATCH
DBTYPE_IUNKNOWN X X X X X X X X X X X X X X X X X X X X X X
DBTYPE_GUID X X X X X X X X X X
Tabla 24. Conversiones de datos de tipos DB2 a tipos OLE DB (continuacin)
Tipos de datos DB2
S
M
A
L
L
I
N
T
I
N
T
E
G
E
R
B
I
G
I
N
T
R
E
A
L
F
L
O
A
T
D
O
U
B
L
E
D
E
C
I
M
A
L
N
U
M
E
R
I
C
D
A
T
E
T
I
M
E
T
I
M
E
S
T
A
M
P
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
C
L
O
B
G
R
A
P
H
I
C
V
A
R
G
R
A
P
H
I
C
L
O
N
G
V
A
R
G
R
A
P
H
I
C
D
B
C
L
O
B
For Bit
Data
B
L
O
B
D
A
T
A
L
I
N
K
C
H
A
R
V
A
R
C
H
A
R
L
O
N
G
V
A
R
C
H
A
R
DBTYPE_ERROR
DBTYPE_BYREF
DBTYPE_ARRAY
DBTYPE_VECTOR
DBTYPE_UDT
DBTYPE_DBDATE X X X X X X X X X X X X X
DBTYPE_DBTIME X X X X X X X X X X
DBTYPE_DBTIMESTAMP X X X X X X X X X X X X X
DBTYPE_FILETIME X X X X X X X X X X X X X X
DBTYPE_PROP_VARIANT X X X X X X X X X X X X X X X
DBTYPE_HCHAPTER
DBTYPE_VARNUMERIC
Nota: cuando la aplicacin realiza una operacin ISequentialStream::Read para obtener los datos del objeto de
almacenamiento, el formato de los datos devueltos depende del tipo de datos de la columna:
v Para tipos de datos binarios y que no sean de tipo carcter, los datos de la columna se exponen como una
secuencia de bytes que representan dichos valores en el sistema operativo.
v Para tipos de datos de carcter, primero los datos se convierten a DBTYPE_STR.
v Para DBCLOB, primero los datos se convierten a DBTYPE_WCHAR.
v Conversin de datos para establecer datos de tipos OLE DB en tipos DB2
en la pgina 398
Restricciones de IBM OLE DB Provider
A continuacin se describen las restricciones de IBM OLE DB Provider:
v IBMDADB2 da soporte al mbito de transacciones de confirmacin
automtica y controladas por el usuario con la interfaz ITransactionLocal.
El mbito de transacciones de confirmacin automtica es el mbito por
omisin. Las transacciones anidadas no reciben soporte.
v ISQLErrorInfo no recibe soporte. Las interfaces IErrorLookUp, IErrorInfo y
IErrorRecords reciben soporte.
v RestartPosition no recibe soporte si el texto del mandato contiene
parmetros.
v IBMDADB2 no pone entre comillas nombres de tablas que se pasan a
travs de parmetros de DBID, que son los parmetros que utiliza la
interfaz IOpenRowset. En su lugar, el consumidor de OLE DB debe aadir
comillas a los nombres de tablas cuando sea necesario.
v Slo se da soporte a un solo conjunto de parmetros. Todava no se da
soporte a varios conjuntos de parmetros.
v IBM OLE DB Provider no da soporte a parmetros con nombre. Cuando se
llama a ICommandWithParameters::MapParameterNames, siempre se devuelve
DB_S_ERRORSOCCURRED. Los nombres de parmetros se pasan por alto
en ICommandWithParameters::GetParameterInfo y
ICommandWithParameters::SetParameterInfo, puesto que slo se utilizan
ordinales.
Soporte de IBM OLE DB Provider de interfaces y componentes de OLE DB
La tabla siguiente contiene las interfaces y componentes de OLE DB que
reciben soporte de IBM OLE DB Provider y de Microsoft OLE DB Provider
para ODBC.
Tabla 25. Comparacin de interfaces y componentes de OLE DB soportados por IBM OLE DB Provider
para DB2 y Microsoft OLE DB Provider para ODBC
Interfaz DB2 ODBC Provider
BLOB
ISequentialStream S S
Mandato
IAccessor S S
ICommand S S
ICommandPersist No No
ICommandPrepare S S
ICommandProperties S S
ICommandText S S
ICommandWithParameters S S
para DB2 y Microsoft OLE DB Provider para ODBC (continuacin)
IColumnsInfo S S
IColumnsRowset No S
IConvertType S S
ISupportErrorInfo S S
Fuente de datos
IConnectionPoint No S
IDBAsynchNotify (consumer) No No
IDBAsynchStatus No No
IDBConnectionPointContainer No S
IDBCreateSession S S
IDBDataSourceAdmin No No
IDBInfo S S
IDBInitialize S S
IDBProperties S S
IPersist S No
IPersistFile No S
Enumerador
IDBInitialize S S
IDBProperties S S
IParseDisplayName S No
ISourcesRowset S S
Servicio de bsqueda de errores
IErrorLookUp S S
Objeto Error
IErrorInfo S No
IErrorRecords S No
ISQLErrorInfo (custom) No No
Varios resultados
IMultipleResults S S
Conjunto de filas
IAccessor S S
IColumnsRowset No S
IColumnsInfo S S
IConvertType S S
IChapteredRowset No No
IConnectionPointContainer No S
IDBAsynchStatus No No
IParentRowset No No
IRowset S S
IRowsetChange Componente Servicio de
cursor
S
IRowsetChapterMember No No
IRowsetFind No No
IRowsetIdentity S S
IRowsetIndex No No
IRowsetInfo S S
IRowsetLocate Componente Servicio de
cursor
S
IRowsetNotify (consumer) No No
IRowsetRefresh Componente Servicio de
cursor
S
IRowsetResynch Componente Servicio de
cursor
S
IRowsetScroll Componente Servicio de
cursor
S
IRowsetUpdate Componente Servicio de
cursor
S
IRowsetView No No
Sesiones
IAlterIndex No No
IAlterTable No No
IDBCreateCommand S S
IDBSchemaRowset S S
IGetDataSource S S
IIndexDefinition No No
IOpenRowset S S
ISessionProperties S S
ITableDefinition No No
ITableDefinitionWithConstraints No No
ITransaction S S
ITransactionJoin S S
ITransactionLocal S S
ITransactionObject No No
ITransactionOptions No S
Objetos Vista
IViewChapter No No
IViewFilter No No
IViewRowset No No
IViewSort No No
Soporte de IBM OLE DB de propiedades de OLE DB
La tabla siguiente muestra las propiedades de OLE DB que reciben soporte de
IBM OLE DB Provider:
Tabla 26. Propiedades soportadas por IBM OLE DB Provider para DB2
Grupo de
propiedades
Conjunto de propiedades Propiedades Valor por omisin R/W
Fuente de
datos
DBPROPSET_DATASOURCE DBPROP_MULTIPLECONNECTIONS VARIANT_FALSE R
DBPROP_RESETDATASOURCE DBPROPVAL_RD_RESETALL R
Informacin
de fuente de
datos
DBPROPSET
_DATASOURCEINFO
DBPROP_ACTIVESESSIONS 0 R
DBPROP_ASYNCTXNABORT VARIANT_FALSE R
Tabla 26. Propiedades soportadas por IBM OLE DB Provider para DB2 (continuacin)
Grupo de
propiedades
DBPROP_ASYNCTXNCOMMIT VARIANT_FALSE R
DBPROP_BYREFACCESSORS VARIANT_FALSE R
DBPROP_COLUMNDEFINITION DBPROPVAL_CD_NOTNULL R
DBPROP_CONCATNULLBEHAVIOR DBPROPVAL_CB_NULL R
DBPROP_CONNECTIONSTATUS DBPROPVAL_CS_INITIALIZED R
DBPROP_DATASOURCENAME N/D R
DBPROP_DATASOURCEREADONLY VARIANT_FALSE R
DBPROP_DBMSNAME N/D R
DBPROP_DBMSVER N/D R
DBPROP_DSOTHREADMODEL DBPROPVAL_RT_FREETHREAD R
DBPROP_GROUPBY DBPROPVAL_GB_CONTAINS_SELECT R
DBPROP_IDENTIFIERCASE DBPROPVAL_IC_UPPER R
DBPROP_MAXINDEXSIZE 0 R
DBPROP_MAXROWSIZE 0 R
DBPROP_MAXROWSIZEINCLUDESBLOB VARIANT_TRUE R
DBPROP_MAXTABLEINSELECT 0 R
DBPROP_MULTIPLEPARAMSETS VARIANT_FALSE R
DBPROP_MULTIPLERESULTS DBPROPVAL_MR_SUPPORTED R
DBPROP_MULTIPLESTORAGEOBJECTS VARIANT_TRUE R
DBPROP_MULTITABLEUPDATE VARIANT_FALSE R
DBPROP_NULLCOLLATION DBPROPVAL_NC_LOW R
DBPROP_OLEOBJECTS DBPROPVAL_OO_BLOB R
DBPROP_ORDERBYCOLUMNSINSELECT VARIANT_FALSE R
DBPROP
_OUTPUTPARAMETERAVAILABILITY
DBPROPVAL_OA_ATEXECUTE R
DBPROP_PERSISTENTIDTYPE DBPROPVAL_PT_NAME R
DBPROP_PREPAREABORTBEHAVIOR DBPROPVAL_CB_DELETE R
DBPROP_PROCEDURETERM PROCEDIMIENTO ALMACENADO R
DBPROP_PROVIDERFRIENDLYNAME Servidores IBM OLE DB Provider para DB2 R
DBPROP_PROVIDERNAME IBMDADB2.DLL R
DBPROP_PROVIDEROLEDBVER 02.00 R
DBPROP_PROVIDERVER 08.01.0000 R
DBPROP_QUOTEIDENTIFIERCASE DBPROPVAL_IC_SENSITIVE R
DBPROP
_ROWSETCONVERSIONSONCOMMAND
VARIANT_TRUE R
DBPROP_SCHEMATERM ESQUEMA R
DBPROP_SCHEMAUSAGE DBPROPVAL_SU_DML_STATEMENTS |
DBPROPVAL_SU_TABLE_DEFINITION |
DBPROPVAL_SU_INDEX_DEFINITION |
DBPROPVAL_SU_PRIVILEGE_DEFINITION
R
DBPROP_SQLSUPPORT DBPROPVAL_SQL_ODBC_EXTENDED |
DBPROPVAL_SQL_ESCAPECLAUSES |
DBPROPVAL_SQL_ANSI92_ENTRY
R
DBPROP_SERVERNAME N/D R
DBPROP_STRUCTUREDSTORAGE DBPROPVAL_SS_ISEQUENTIALSTREAM R
DBPROP_SUBQUERIES DBPROPVAL_SQ_CORRELATEDSUBQUERIES |
DBPROPVAL_SQ_COMPARISON |
DBPROPVAL_SQ_EXISTS |
DBPROPVAL_SQ_IN |
DBPROPVAL_SQ_QUANTIFIED |
R
Grupo de
propiedades
DBPROP_SUPPORTEDTXNDDL DBPROPVAL_TC_ALL R
DBPROP_SUPPORTEDTXNISOLEVELS DBPROPVAL_TI_CURSORSTABILITY |
DBPROPVAL_TI_READCOMMITTED |
DBPROPVAL_TI_READUNCOMMITTED |
DBPROPVAL_TI_SERIALIZABLE |
R
DBPROP_SUPPORTEDTXNISORETAIN DBPROPVAL_TR_COMMIT_DC |
DBPROPVAL_TR_ABORT_NO |
R
DBPROP_TABLETERM TABLA R
DBPROP_USERNAME N/D R
Inicializacin DBPROPSET_DBINIT DBPROP_AUTH_PASSWORD N/D R/W
DBPROP_AUTH_USERID N/D R/W
DBPROP_INIT_DATASOURCE N/D R/W
DBPROP_INIT_HWND N/D R/W
DBPROP_INIT_MODE DB_MODE_READWRITE R/W
DBPROP_INIT_OLEDBSERVICES 0xFFFFFFFF R/W
DBPROP_INIT_PROMPT DBPROMPT_NOPROMPT R/W
DBPROP_INIT_PROVIDERSTRING N/D R/W
Conjunto de
filas
DBPROPSET_ROWSET DBPROP_ABORTPRESERVE VARIANT_FALSE R
DBPROP_ACCESSORDER DBPROPVAL_AO_RANDOM R
DBPROP_BLOCKINGSTORAGEOBJECTS VARIANT_FALSE R
DBPROP_CACHEDEFERRED VARIANT_FALSE R/W
DBPROP_CANHOLDROWS VARIANT_FALSE R
DBPROP_COMMITPRESERVE VARIANT_TRUE R/W
DBPROP_COMMANDTIMEOUT 0 R/W
DBPROP_DEFERRED VARIANT_FALSE R
DBPROP_IAccessor VARIANT_TRUE R
DBPROP_IColumnsInfo VARIANT_TRUE R
DBPROP_IColumnsRowset VARIANT_TRUE R
DBPROP_IConvertType VARIANT_TRUE R
DBPROP_IMultipleResults VARIANT_TRUE R
DBPROP_IRowset VARIANT_TRUE R
DBPROP_IRowChange VARIANT_FALSE R
DBPROP_IRowsetFind VARIANT_FALSE R
DBPROP_IRowsetIdentity VARIANT_TRUE R
DBPROP_IRowsetInfo VARIANT_TRUE R
DBPROP_IRowsetLocate VARIANT_FALSE R
DBPROP_IRowsetScroll VARIANT_FALSE R
DBPROP_IRowsetUpdate VARIANT_FALSE R
DBPROP_ISequentialStream VARIANT_TRUE R
DBPROP_ISupportErrorInfo VARIANT_TRUE R
DBPROP_LITERALIDENTITY VARIANT_TRUE R
DBPROP_LOCKMODE DBPROPVAL_LM_SINGLEROW R/W
DBPROP_MAXOPENROWS 0 R/W
DBPROP_MAXROWS 0 R/W
DBPROP_QUICKRESTART VARIANT_FALSE R/W
DBPROP_ROWTHREADMODEL DBPROPVAL_RT_FREETHREAD R
DBPROP_SERVERCURSOR VARIANT_TRUE R
Grupo de
propiedades
DBPROP_UNIQUEROWS VARIANT_FALSE R
DBPROPSET_DB2ROWSET DBPROP_OPENROWSETSUPPORT DBPROPVAL_ORS_TABLE R
DBPROP_ISLONGMINLENGTH 32000 R/W
Sesin DBPROPSET_SESSION DBPROP_SESS_AUTOCOMMITISOLEVELS DBPROPVAL_TI_CURSORSTABILITY R/W
Conexiones a fuentes de datos mediante IBM OLE DB Provider
Los siguientes ejemplos muestran cmo conectar con una fuente de datos DB2
mediante IBM OLE DB Provider para DB2:
Ejemplo 1: Aplicacin Visual Basic que utiliza ADO:
Dim db As ADODB.Connection
Set db = New ADODB.Connection
db.Provider = IBMDADB2
db.CursorLocation = adUseClient
...
Ejemplo 2: Aplicacin C/C++ que utiliza IDBPromptInitialize y Data
Links:
// Crear DataLinks
hr = CoCreateInstance (
CLSID_DataLinks,
NULL,
CLSCTX_INPROC_SERVER,
IID_IDBPromptInitialize,
(void**)&pIDBPromptInitialize);
// Invocar la UI DataLinks para seleccionar el proveedor y la fuente de datos
hr = pIDBPromptInitialize>PromptDataSource (
NULL,
GetDesktopWindow(),
DBPROMPTOPTIONS_PROPERTYSHEET,
0,
NULL,
NULL,
IID_IDBInitialize,
(IUnknown**)&pIDBInitialize);
Ejemplo 3: Aplicacin C/C++ que utiliza IDataInitialize y el componente de
servicio:
hr = CoCreateInstance (
CLSID_MSDAINITIALIZE,
NULL,
IID_IDataInitialize,
(void**)&pIDataInitialize);
hr = pIDataInitialize>CreateDBInstance(
CLSID_IBMDADB2, // ClassID de IBMDADB2
NULL,
NULL,
IID_IDBInitialize,
(IUnknown**)&pIDBInitialize);
Aplicaciones ADO
Las siguientes secciones describen consideraciones sobre aplicaciones ADO.
Palabras clave de series de conexin de ADO
Para especificar palabras clave de series de conexin de ADO (Objetos de
datos ActiveX), especifique la palabra clave con el formato palabra
clave=valor en la serie (conexin) del proveedor. Delimite varias palabras
clave con un punto y coma (;).
La tabla siguiente describe las palabras clave a las que da soporte IBM OLE
DB Provider para DB2:
Tabla 27. Palabras clave a las que da soporte IBM OLE DB Provider para DB2
Palabra clave Valor Significado
DSN Nombre del alias de la base
de datos
El alias de la base de datos DB2 en el
directorio de bases de datos.
UID ID de usuario El ID de usuario que se utiliza para
conectar con el servidor DB2.
PWD Contrasea de UID Contrasea correspondiente al ID de
usuario utilizado para conectar con el
servidor DB2.
Hay otras palabras clave de configuracin de CLI de DB2 que tambin afectan
al comportamiento de IBM OLE DB Provider.
v CLI/ODBC Configuration Keywords Listing by Category en el manual
Conexiones con fuentes de datos con aplicaciones ADO Visual Basic
Para conectar con una fuente de datos DB2 mediante IBM OLE DB Provider
para DB2, especifique el nombre de proveedor IBMDADB2.
v Conexiones a fuentes de datos mediante IBM OLE DB Provider en la
pgina 409
v Creacin de aplicaciones ADO con Visual Basic en el manual Gua de
Cursores desplazables actualizables en aplicaciones ADO
Puesto que IBM OLE DB Provider para DB2 da soporte de forma nativa a
cursores de solo lectura y de solo avance, una aplicacin ADO que desee
acceder a cursores desplazables actualizables debe establecer como ubicacin
del cursor el valor adUseClient.
Limitaciones de las aplicaciones ADO
A continuacin se describen las limitaciones de las aplicaciones ADO:
v Las aplicaciones ADO que llaman a procedimientos almacenados deben
crear y vincular de forma explcita sus parmetros. El mtodo
Parameters.Refresh para generar parmetros automticamente an no
recibe soporte.
v No se da soporte a valores por omisin de parmetros.
v Para aplicaciones ADO Visual Basic, los controles de datos no reciben
soporte para cursores del servidor. Sin embargo, hay cursores de datos
disponibles para aplicaciones de cursor del cliente.
v La palabra clave WithEvents no se puede utilizar en declaraciones del objeto
de conjunto de registros para aplicaciones ADO Visual Basic que utilizan el
cursor del servidor de solo lectura/solo avance; es decir, cuando se
especifica para Cursor Location el valor adUseServer.
Soporte de IBM OLE DB Provider de propiedades y mtodos ADO
IBM OLE DB Provider da soporte a los siguientes mtodos y propiedades
ADO:
Tabla 28. Mtodos y propiedades ADO soportados por IBM OLE DB Provider para DB2
ADO Mtodo/Propiedad Interfaz/Propiedad OLE DB Soporte de IBM OLE
DB
Mtodos de
mandato
Cancel ICommand S
CreateParameter S
Execute S
Propiedades de
mandato
ActiveConnection (Especfico de ADO)
Tabla 28. Mtodos y propiedades ADO soportados por IBM OLE DB Provider para DB2 (continuacin)
DB
Command Text ICommandText S
Command Timeout ICommandProperties::SetProperties
DBPROP_COMMANDTIMEOUT
S
CommandType (Especfico de ADO)
Prepared ICommandPrepare S
State (Especfico de ADO)
Grupo de
mandatos
Parameters ICommandWithParameter
DBSCHEMA
S
Properties ICommandProperties
IDBProperties
S
Mtodos de
conexin
BeginTrans
CommitTrans
RollbackTrans
ITransactionLocal S (pero no anidado)
S (pero no anidado)
S (pero no anidado)
Execute ICommand
IOpenRowset
S
Open IDBCreateSession
IDBInitialize
S
OpenSchema
adSchemaColumnPrivileges
adSchemaColumns
adSchemaForeignKeys
adSchemaIndexes
adSchemaPrimaryKeys
adSchemaProcedureParam
adSchemaProcedures
adSchemaProviderType
adSchemaStatistics
adSchemaTablePrivileges
adSchemaTables
IDBSchemaRowset
S
S
S
S
S
S
S
S
S
S
S
Cancel S
Propiedades de
conexin
Attributes
adXactCommitRetaining
adXactRollbackRetaining
ITransactionLocal
S
S
CommandTimeout ICommandProperties
DBPROP_COMMAND_TIMEOUT
S
ConnectionString (Especfico de ADO)
ConnectionTimeout IDBProperties
DBPROP_INIT_TIMEOUT
No
CursorLocation:
adUseClient
adUseNone
adUseServer
(Utilizar Servicio de cursor de OLE DB)
(No utilizado)
(No actualizable slo en avance)
S
NoS
DB
DefaultDataBase IDBProperties
DBPROP_CURRENTCATALOG
No
IsolationLevel ITransactionLocal
DBPROP_SESS
_AUTOCOMMITSOLEVELS
S
Mode
adModeRead
adModeReadWrite
adModeShareDenyNone
adModeShareDenyRead
adModeShareDenyWrite
adModeShareExclusive
adModeUnknown
adModeWrite
IDBProperties
DBPROP_INIT_MODE NoS
NoNoNoNoNoNo
Provider ISourceRowset::GetSourceRowset S
Version (Especfico de ADO)
Grupos de
conexiones
Errors IErrorRecords S
Properties IDBProperties S
Propiedades de
error
Description
NativeError
Number
Source
SQLState
IErrorRecords S
S
S
S
No
HelpContext
HelpFile
No
No
Mtodos de
campo
AppendChunk
GetChunk
ISequentialStream S
S
Propiedades de
campo
Actual Size IAccessor
IRowset
S
Attributes
DataFormat
DefinedSize
Name
NumericScale
Precision
Type
IColumnInfo
S
S
S
S
S
S
OriginalValue IRowsetUpdate S (Servicio de cursor)
UnderlyingValue IRowsetRefresh
IRowsetResynch
S
(Servicio de cursor)
S
(Servicio de cursor)
DB
Value IAccessor
IRowset
S
Grupo de
campos
Properties IDBProperties
IRowsetInfo
S
Mtodos de
parmetro
AppendChunk ISequentialStream S
Attributes
Direction
Name
NumericScale
Precision
Scale
Size
Type
ICommandWithParameter
DBSCHEMA
S
No
S
S
S
S
S
Value IAccessor
ICommand
S
Grupo de
parmetros
Properties S
Mtodos
RecordSet
AddNew IRowsetChange S (Servicio de cursor)
Cancel S
CancelBatch IRowsetUpdate::Undo S (Servicio de cursor)
CancelUpdate S (Servicio de cursor)
Clone IRowsetLocate S (Servicio de cursor)
Close IAccessor
IRowset
S
CompareBookmarks No
Delete IRowsetChange S (Servicio de cursor)
GetRows IAccessor
IRowset
S (Servicio de cursor)
Move IRowset
IRowsetLocate
Cursor de servidor:
slo en avance
Servicio de cursor:
desplazable
MoveFirst IRowset
IRowsetLocate
MoveNext IRowset
IRowsetLocate
MoveLast IRowsetLocate S (Servicio de cursor)
MovePrevious IRowsetLocate S (Servicio de cursor)
NextRecordSet IMultipleResults S
DB
Open ICommand
IOpenRowset
S
Requery ICommand
IOpenRowset
S
Resync IRowsetRefresh S (Servicio de cursor)
Supports IRowsetInfo S
Update
UpdateBatch
IRowsetChange
IRowsetUpdate
Propiedades de
RecordSet
AbsolutePage IRowsetLocate
IRowsetScroll
AbsolutePosition IRowsetLocate
IRowsetScroll
ActiveConnection IDBCreateSession
IDBInitialize
S
BOF (Especfico de ADO)
Bookmark IAccessor
IRowsetLocate
CacheSize cRows in IRowsetLocate
IRowset
S
CursorType
adOpenDynamic
adOpenForwardOnly
adOpenKeySet
adOpenStatic
ICommandProperties
No
S
No
EditMode IRowsetUpdate S (Servicio de cursor)
EOF (Especfico de ADO)
Filter IRowsetLocate
IRowsetView
IRowsetUpdate
IViewChapter
IViewFilter
No
LockType ICommandProperties No
MarshallOption No
MaxRecords ICommandProperties
IOpenRowset
S
PageCount IRowsetScroll S (Servicio de cursor)
PageSize (Especfico de ADO)
Sort (Especfico de ADO)
Source (Especfico de ADO)
Status IRowsetUpdate S (Servicio de cursor)
DB
Grupo de
RecordSet
Fields IColumnInfo S
Properties IDBProperties
IRowsetInfo::GetProperties
S
Aplicaciones C y C++
Las secciones siguientes describen consideraciones sobre aplicaciones C y C++.
Compilacin y enlace de aplicaciones C/C++ e IBM OLE DB Provider
Las aplicaciones C/C++ que utilizan la constante CLSID_IBMDADB2 deben
incluir el archivo ibmdadb2.h, que se encuentra en el directorio
SQLLIB\include. Estas aplicaciones deben definir DBINITCONSTANTS antes
de la sentencia include. El siguiente ejemplo muestra la secuencia correcta de
sentencias:
#define DBINITCONSTANTS
#include "ibmdadb2.h"
Conexiones con fuentes de datos en aplicaciones C/C++ mediante IBM
OLE DB Provider
Para conectar con una fuente de datos DB2 mediante IBM OLE DB Provider
para DB2 en una aplicacin C/C++, utilice una de las dos interfaces
principales de OLE DB, IDBPromptInitialize o IDataInitialize. El hecho de
conectar con la fuente de datos de este modo garantiza el acceso de la
aplicacin a cursores desplazables actualizables, en lugar de a los cursores de
solo lectura y de solo avance disponibles de forma nativa. Si IBMDADB2 se
crea directamente llamando a la API COM CoCreateInstance, los cursores
disponibles sern de solo lectura y de solo avance. El componente OLE DB
Service expone la interfaz IDataInitialize y el componente Data Links
expone la interfaz IDBPromptInitialize.
v Conexiones a fuentes de datos mediante IBM OLE DB Provider en la
pgina 409
v Creacin de aplicaciones ADO con Visual C++ en el manual Gua de
Cursores desplazables actualizables en aplicaciones ATL e IBM OLE DB
Provider
Si una aplicacin ATL (Active Template Library) necesita cursores
desplazables actualizables y su Objeto Consumidor de acceso a datos se ha
generado mediante ATL COM AppWizard, la aplicacin debe utilizar el
mtodo OpenWithServiceComponents en lugar de la llamada al mtodo Open
(que es la que el asistente genera por omisin). Si se utiliza el mtodo Open,
los cursores disponibles sern de solo lectura y de solo avance. El siguiente
ejemplo muestra cmo utilizar el mtodo OpenWithServiceComponents:
// La siguiente lnea la genera el asistente en el mtodo OpenDataSource
// hr = db.Open(_T(IBMDADB2), &dbinit);
// Sustityala por lo siguiente:
hr = db.OpenWithServiceComponents(_T(IBMDADB2), &dbinit);
Transacciones distribuidas MTS y COM+
Las secciones siguientes describen consideraciones sobre las transacciones
distribuidas MTS y COM+.
Soporte de transacciones distribuidas MTS y COM+ e IBM OLE DB
Provider
Las aplicaciones OLE DB que se ejecutan en un entorno Microsoft Transaction
Server (MTS) en Windows NT o en un entorno Component Services (COM+)
en Windows 2000 pueden utilizar la interfaz ITransactionJoin para participar
en transacciones distribuidas con varios servidores de bases de datos DB2
Universal Database, de sistema principal y iSeries, as como otros gestores de
recursos que cumplan con las especificaciones MTS/COM+.
Requisitos previos:
Para poder utilizar el soporte de transacciones distribuidas MTS o COM+ que
ofrece IBM OLE DB Provider para DB2, asegrese de que el servidor cumple
los siguientes requisitos previos.
Nota: estos requisitos slo afectan a la mquina Windows en la que est
instalado el cliente DB2.
v Windows NT con MTS al nivel de Versin 2.0 con Microsoft Hotfix 0772 o
posterior, o Windows 2000
MTS Versin 2.0 para Windows NT est disponible como parte de Windows
NT 4.0 Option Pack. Puede bajar el Option Pack de:
http://www.microsoft.com/ntserver/nts/downloads/recommended/NT4OptPk/
Habilitacin del soporte de MTS en DB2 Universal Database para
aplicaciones C/C++
Para ejecutar una aplicacin C o C++ en modalidad transaccional MTS o
COM+, puede crear la instancia de fuente de datos IBMDABD2 mediante la
interfaz DataLink. Tambin podra utilizar CoCreateInstance, obtener un
objeto de sesin y utilizar JoinTransaction. Consulte la descripcin sobre
cmo conectar una aplicacin C o C++ a una fuente de datos para obtener
ms informacin.
Para ejecutar una aplicacin ADO en modalidad transaccional MTS o COM+,
consulte la descripcin sobre cmo conectar una aplicacin C o C++ a una
fuente de datos.
Para utilizar un componente de un paquete MTS o COM+ en modalidad
transaccional, establezca para la propiedad Transactions del componente uno
de los siguientes valores:
v Required
v Required New
v Supported
Para obtener informacin sobre estos valores, consulte la documentacin de
MTS.
Parte 5. Conceptos generales sobre aplicaciones DB2
Captulo 15. Soporte de idiomas nacionales
Visin general del orden de clasificacin . . 421
rdenes de clasificacin . . . . . . 422
Comparaciones de caracteres basadas en
rdenes de clasificacin . . . . . . . 424
Comparaciones que no dependen de
maysculas y minsculas mediante la
funcin TRANSLATE . . . . . . . 424
Diferencias entre los rdenes de
clasificacin de EBCDIC y ASCII . . . . 426
Orden de clasificacin especificado
cuando se crea la base de datos . . . . 427
rdenes de clasificacin de ejemplo. . . 429
Pginas de cdigos y entornos locales . . . 430
Derivacin de valores de pgina de
cdigos . . . . . . . . . . . . 430
Derivacin de entornos locales en
programas de aplicacin . . . . . . 430
Cmo DB2 deriva entornos locales . . . 431
Consideraciones sobre aplicaciones . . . . 431
Consideraciones sobre el soporte de
idiomas nacionales y sobre el desarrollo
de aplicaciones. . . . . . . . . . 432
Soporte de idiomas nacionales y
sentencias de SQL . . . . . . . . 433
Procedimientos almacenados y UDF
remotos . . . . . . . . . . . . 435
Consideraciones sobre nombres de
paquetes en entornos de pginas de
cdigos combinadas . . . . . . . . 435
Pgina de cdigos activa para
precompilacin y vinculacin . . . . . 436
Pgina de cdigos activa para la ejecucin
de aplicaciones. . . . . . . . . . 436
Conversin de caracteres entre distintas
pginas de cdigos . . . . . . . . 436
Cundo se produce la conversin de
pgina de cdigos . . . . . . . . 437
Sustitucin de caracteres durante
conversiones de pginas de cdigos. . . 438
Conversiones de pginas de cdigos
soportadas . . . . . . . . . . . 438
Factor de expansin de conversin de
pgina de cdigos . . . . . . . . 440
Juegos de caracteres DBCS . . . . . . . 441
Juegos de caracteres de Extended UNIX
Code (EUC). . . . . . . . . . . . 442
Programas CLI, ODBC, JDBC y SQLj en un
entorno DBCS . . . . . . . . . . . 443
Consideraciones sobre los juegos de cdigos
EUC y UCS-2 de japons y chino tradicional . 444
Consideraciones sobre los juegos de
cdigos EUC y UCS-2 de japons y chino
tradicional . . . . . . . . . . . 444
Consideraciones sobre las bases de datos
y los clientes de doble byte con EUC
mixtos . . . . . . . . . . . . 446
Consideraciones sobre la conversin de
caracteres para usuarios de chino
tradicional . . . . . . . . . . . 447
Datos grficos en aplicaciones EUC en
japons o chino tradicional. . . . . . 447
Desarrollo de aplicaciones en situaciones
de pginas de cdigos distintas . . . . 449
Validacin de parmetros basada en
cliente en un entorno de juegos de
cdigos mixtos. . . . . . . . . . 453
Sentencia DESCRIBE en entornos de
juegos de cdigos mixtos . . . . . . 454
Datos de longitud fija y de longitud
variable en entornos de juegos de cdigos
mixtos . . . . . . . . . . . . 456
Desbordamiento de longitud de serie de
conversin de pgina de cdigos en
entornos de juegos de cdigos mixtos . . 457
Aplicaciones conectadas a bases de datos
Unicode . . . . . . . . . . . . 459
Visin general del orden de clasificacin
Las secciones siguientes describen rdenes de clasificacin y cmo se realizan
las comparaciones de caracteres.
rdenes de clasificacin
El gestor de bases de datos compara datos de caracteres utilizando un orden de
clasificacin. Es una clasificacin correspondiente a conjuntos de caracteres que
determina si un determinado carcter se clasifica por encima, por debajo o
igual que otro.
Nota: los datos de series de caracteres definidos con el atributo FOR BIT
DATA y los datos BLOB se clasifican utilizando el orden de clasificacin
binaria.
Por ejemplo, se puede utilizar un orden de clasificacin para indicar que las
versiones en minsculas y en maysculas de un determinado carcter se
tienen que clasificar de igual forma.
El gestor de bases de datos permite que se creen bases de datos con rdenes
de clasificacin personalizados. Las secciones siguientes le ayudan a
determinar y a implantar un determinado orden de clasificacin para una
base de datos.
Cada carcter de un solo byte de una base de datos se representa de forma
interna como un nmero exclusivo comprendido entre 0 y 255 (en notacin
hexadecimal, entre X'00' y X'FF'). Se hace referencia a este nmero como punto
de cdigo del carcter; la asignacin de nmeros a caracteres en un conjunto se
denomina de forma colectiva pgina de cdigos. Un orden de clasificacin es
una correlacin entre el punto de cdigo y la posicin deseada de cada
carcter en un orden clasificado. El valor numrico de la posicin se
denomina peso del carcter en el orden de clasificacin. En el orden de
clasificacin ms sencillo, los pesos son idnticos a los puntos de cdigo. Esto
se denomina el orden de identidad.
Por ejemplo, supongamos que los caracteres B y b tienen los puntos de cdigo
X'42' y X'62' respectivamente. Si (segn la tabla de orden de clasificacin),
ambos tienen un peso de clasificacin de X'42' (B), se clasifican igual. Si el
peso de clasificacin correspondiente a B es X'9E' y el correspondiente a b es
X'9D', b se clasificar antes que B. La tabla de orden de clasificacin especifica
el peso de cada carcter. La tabla es distinta de una pgina de cdigos, la cual
especifica el punto de cdigo de cada carcter.
Supongamos que tenemos el siguiente ejemplo. Los caracteres ASCII
comprendidos entre A y Z se representan mediante los valores comprendidos
entre X'41' y X'5A'. Para describir un orden de clasificacin en el que estos
caracteres se clasifican de forma consecutiva (sin caracteres intermedios),
puede escribir X'41', X'42', ... X'59', X'5A'.
El valor hexadecimal de un carcter de varios bytes tambin se utiliza como el
peso. Por ejemplo, supongamos que los puntos de cdigo correspondientes a
los caracteres de doble byte A y B son X'8260' y X'8261' respectivamente; se
utilizan los pesos de clasificacin correspondientes a X'82', X'60' y X'61' para
clasificar estos dos caracteres se acuerdo con sus puntos de cdigo.
No hace falta que los pesos de un orden de clasificacin sean exclusivos. Por
ejemplo, podra asignar a letras maysculas y a sus equivalentes minsculas
el mismo peso.
La especificacin de un orden de clasificacin se puede simplificar si el orden
de clasificacin proporciona pesos para los 256 puntos de cdigo. El peso de
cada carcter se puede determinar mediante el punto de cdigo del carcter.
En todos los casos, DB2 utiliza la tabla de clasificacin especificada en el
momento de creacin de la base de datos. Si desea que los caracteres de
varios bytes se clasifiquen del modo en que aparecen en su tabla de puntos de
cdigo, debe especificar IDENTITY como el orden de clasificacin al crear la
base de datos.
Nota: para caracteres de doble byte y Unicode en campos GRAPHIC, el orden
de clasificacin siempre es IDENTITY.
Una vez definido un orden de clasificacin, todas las futuras comparaciones
de caracteres correspondientes a dicha base de datos se realizar con este
orden de clasificacin. Excepto para los datos definidos como FOR BIT DATA
o datos BLOB, el orden de clasificacin se utilizar para todas las
comparaciones de SQL y clusulas ORDER BY y tambin al configurar ndices
y estadsticas.
Se pueden producir problemas potenciales en los siguientes casos:
v Una aplicacin fusiona datos clasificados de una base de datos con datos de
aplicacin que se clasificaron utilizando otro orden de clasificacin.
v Una aplicacin fusiona datos clasificados de una base de datos con datos
clasificados de otra, pero las bases de datos tienen distintos rdenes de
clasificacin.
v Una aplicacin realiza supuestos sobre datos clasificados que no resultan
ciertos para el orden de clasificacin relevante. Por ejemplo, que los
nmeros se clasifican por debajo que los caracteres alfabticos puede
resultar o no cierto para un determinado orden de clasificacin.
Un punto final a tener en cuenta es que los resultados de cualquier
clasificacin basada en una comparacin directa de puntos de cdigo de
caracteres slo coincidir con los resultados de consultas que estn clasificados
utilizando un orden de clasificacin de identidad.
Captulo 15. Soporte de idiomas nacionales 423
v conversin de caracteres en el manual Consulta de SQL, Volumen 1
v Comparaciones de caracteres basadas en rdenes de clasificacin en la
pgina 424
Comparaciones de caracteres basadas en rdenes de clasificacin
Una vez establecido un orden de clasificacin, la comparacin de caracteres se
lleva a cabo comparando los pesos de dos caracteres, en lugar de comparando
directamente sus valores de punto de cdigo.
Si se utilizan pesos que no son exclusivos, es posible que caracteres que no
son idnticos se comparen y queden iguales. Por este motivo, la comparacin
de series se puede convertir en un proceso de dos fases:
1. Comparar los caracteres de cada serie segn sus pesos.
2. Si el paso 2 da como resultado igualdad, comparar los caracteres de cada
serie segn sus valores de punto de cdigo.
Si el orden de clasificacin contiene 256 pesos exclusivos, slo hay que llevar
a cabo el primer paso. Si el orden de clasificacin es el orden de identidad,
slo hay que llevar a cabo el segundo paso. En cualquier caso, hay una mejora
del rendimiento.
Comparaciones que no dependen de maysculas y minsculas mediante
la funcin TRANSLATE
Para realizar comparaciones de caracteres que no dependen de maysculas y
minsculas, puede utilizar la funcin TRANSLATE para seleccionar y
comparar datos de columnas de maysculas y minsculas combinadas,
convirtindolos todos a maysculas (slo para la comparacin). Supongamos
que tenemos los datos siguientes:
Abel
abels
ABEL
abel
ab
Ab
La siguiente sentencia SELECT:
SELECT c1 FROM T1 WHERE TRANSLATE(c1) LIKE AB%
devuelve
ab
Ab
abel
Abel
ABEL
abels
Tambin podra especificar la siguiente sentencia SELECT al crear la vista
v1, realizar todas las comparaciones contra la vista en maysculas y solicitar
operaciones INSERT de la tabla en maysculas y minsculas combinadas:
CREATE VIEW v1 AS SELECT TRANSLATE(c1) FROM T1
A nivel de base de datos, puede definir el orden de clasificacin como parte
de la API sqlecrea. - Crear base de datos. Esto le permite decidir si a se
tiene que procesar antes que A, si A se tiene que procesar despus que a
o si se tienen que procesar con el mismo peso. Esto las convertira en iguales
si se realiza la clasificacin mediante la clusula ORDER BY. A siempre ir
antes que a, porque son equivalentes en cualquier sentido. La nica base por
la que clasificar es el valor hexadecimal.
Por lo tanto
SELECT c1 FROM T1 WHERE c1 LIKE ab%
devuelve
ab
abel
abels
y
SELECT c1 FROM T1 WHERE c1 LIKE A%
devuelve
Abel
Ab
ABEL
La sentencia siguiente
SELECT c1 FROM T1 ORDER BY c1
devuelve
ab
Ab
abel
Abel
ABEL
abels
Por lo tanto, quizs desee tener en cuenta la posibilidad de utilizar la funcin
escalar TRANSLATE(), adems de sqlecrea. Tenga en cuenta que slo puede
especificar un orden de clasificacin mediante sqlecrea. No puede especificar
un orden de clasificacin desde el procesador de lnea de mandatos (CLP).
Tambin puede utilizar la funcin UCASE del siguiente modo, pero tenga en
cuenta que DB2 realiza una exploracin de tabla en lugar de utilizar un ndice
para esta operacin select:
SELECT * FROM EMP WHERE UCASE(JOB) = NURSE
v Funcin escalar TRANSLATE en el manual Consulta de SQL, Volumen 1
v Funcin escalar UCASE o UPPER en el manual Consulta de SQL, Volumen
1
Diferencias entre los rdenes de clasificacin de EBCDIC y ASCII
El orden en que se clasifican los datos de una base de datos depende del
orden de clasificacin definido para la base de datos. Por ejemplo,
supongamos que la base de datos A utiliza el orden de clasificacin por
omisin de la pgina de cdigos EBCDIC y que la base de datos B utiliza el
orden de clasificacin por omisin de la pgina de cdigos ASCII. Los rdenes
de clasificacin de estas dos bases de datos diferiran, tal como se muestra en
el siguiente ejemplo:
De forma similar, las comparaciones de caracteres de una base de datos
dependen del orden de clasificacin definido para dicha base de datos. De
este modo, si la base de datos A utiliza el orden de clasificacin por omisin
de la pgina de cdigos EBCDIC y la base de datos B utiliza el orden de
clasificacin por omisin de la pgina de cdigos ASCII, los resultados de
SELECT.....
ORDER BY COL2
Orden clasif. EBCDIC Orden clasif. ASCII
COL2 COL2
---- ----
V1G 7AB
Y2W V1G
7AB Y2W
Figura 7. Ejemplo de cmo difiere un orden de clasificacin basado en EBCDIC de un orden de clasificacin basado
en ASCII
comparaciones de caracteres en las dos bases de datos diferiran. La diferencia
es la siguiente:
Si va a crear una base de datos federada, considere la posibilidad de
especificar que el orden de clasificacin coincida con el orden de clasificacin
de la fuente de datos. Este enfoque maximizar las oportunidades de
empuje y posiblemente aumentar el rendimiento de las consultas.
v Guidelines for analyzing where a federated query is evaluated en el
manual Administration Guide: Performance
Orden de clasificacin especificado cuando se crea la base de datos
El orden de clasificacin correspondiente a una base de datos se especifica en
el momento de creacin de la base de datos. Una vez creada la base de datos,
el orden de clasificacin no se puede cambiar.
La API CREATE DATABASE acepta una estructura de datos denominada
Bloque descriptor de base de datos (SQLEDBDESC). Puede definir su propio
orden de clasificacin dentro de esta estructura.
Nota: slo puede definir su propio orden de clasificacin para una base de
datos de un solo byte.
Para especificar un orden de clasificacin para una base de datos:
v Pase la estructura SQLEDBDESC que desee, o
v Pase un puntero NULL. Se utiliza el orden de clasificacin del sistema
operativo (basado en la pgina de cdigos y la pgina de pas/regin
actuales). Esto equivale a especificar para SQLDBCSS el valor
SQL_CS_SYSTEM (0).
La estructura SQLEDBDESC contiene:
SELECT.....
WHERE COL2 > TT3
Resultados EBCDIC Resultados ASCII
COL2 COL2
---- ----
TW4 TW4
X72 X72
39G
Figura 8. Ejemplo de cmo una comparacin de caracteres en un orden de clasificacin basado en EBCDIC difiere de
una comparacin de caracteres en un orden de clasificacin basado en ASCII
SQLDBCSS Un entero de 4 bytes que indica la fuente del orden de
clasificacin de la base de datos. Los valores vlidos son:
SQL_CS_SYSTEM
Se utiliza el orden de clasificacin del sistema
operativo (basado en la pgina de cdigos y la
pgina de pas/regin actuales).
SQL_CS_SYSTEM_NLSCHAR
Orden de clasificacin del usuario que utiliza
la versin NLS de rutinas de comparacin
para tipos de caracteres
SQL_CS_IDENTITY_16BIT
Una base de datos Unicode se puede crear con
la opcin de clasificacin
SQL_CS_IDENTITY_16BIT.
SQL_CS_IDENTITY_16BIT difiere de la opcin
de clasificacin SQL_CS_NONE por omisin
en que los datos CHAR, VARCHAR, LONG
VARCHAR y CLOB de la base de datos
Unicode se clasificarn utilizando el orden
binario CESU-8 en lugar del orden binario
UTF-8. CESU-8 es un Esquema de codificacin
de compatibilidad para UTF-16: 8 bits y, en lo
que a este documento se refiere, su
especificacin est contenida en el Borrador de
informe tcnico de Unicode nmero 26
disponible en el sitio web de Unidoce
Technical Consortium (www.unicode.org).
CESU-8 es idntico en binario a UTF-8,
excepto los caracteres complementarios de
Unicode, es decir, los caracteres que estn
definidos fuera de Basic Multilingual Plane de
16 bits (BMP o Plane 0). En codificacin
UTF-8, un carcter complementario se
representa mediante una secuencia de 4 bytes,
pero el mismo carcter en CESU-8 necesita
dos secuencias de 3 bytes. En una base de
datos Unicode, los datos CHAR, VARCHAR,
LONG VARCHAR y CLOB se almacenan en
UTF-8 y los datos GRAPHIC, VARGRAPHIC,
LONG VARGRAPHIC y DBCLOB se
almacenan en UCS-2. Para la clasificacin
SQL_CS_NONE, los caracteres no
complementarios en UTF-8 y UCS-2 tienen la
misma clasificacin binaria, pero los caracteres
complementarios en UTF-8 se clasifican de
forma distinta a los mismos caracteres en
UCS-2. SQL_CS_IDENTITY_16BIT asegura que
todos los caracteres, complementarios y no
complementarios, de una base de datos
Unicode DB2 tienen la misma clasificacin
binaria.
SQL_CS_USER
El orden de clasificacin se especifica
mediante el valor del campo SQLDBUDC.
SQL_CS_NONE
El orden de clasificacin es la clasificacin de
identidad. Las series se comparan byte a byte,
empezando por el primer byte, utilizando una
sencilla comparacin de puntos de cdigo.
Nota: estas constantes se definen en el archivo include
SQLENV.
SQLDBUDC Un campo de 256 bytes. El byte nmero n contiene el peso de
clasificacin del carcter nmero n de la pgina de cdigos de
la base de datos. Si SQLDBCSS no es igual a SQL_CS_USER,
este campo se pasa por alto.
rdenes de clasificacin de ejemplo
Se proporcionan varios rdenes de clasificacin de ejemplo (como archivos
include) para facilitar la creacin de bases de datos utilizando los rdenes de
clasificacin EBCDIC en lugar del orden de clasificacin por omisin de la
estacin de trabajo.
Los rdenes de clasificacin de estos archivos include se pueden especificar en
el campo SQLDBUDC de la estructura SQLEDBDESC. Tambin se pueden
utilizar como modelos para la construccin de otros rdenes de clasificacin.
Hay archivos include que contienen rdenes de clasificacin disponibles para
los siguientes lenguajes principales:
v C/C++
v COBOL
v FORTRAN
v Archivos include para C y C++ en la pgina 177
v Archivos include para COBOL en la pgina 234
v Archivos include para FORTRAN en la pgina 263
Pginas de cdigos y entornos locales
Las secciones siguientes describen pginas de cdigos y cmo se obtienen
pginas de cdigos y entornos locales.
Derivacin de valores de pgina de cdigos
La pgina de cdigos de la aplicacin se deriva del entorno activo cuando se
realiza la conexin con la base de datos. Si la variable de registro
DB2CODEPAGE est definida, se toma este valor como pgina de cdigos de
la aplicacin. Sin embargo, no es necesario definir la variable de registro
DB2CODEPAGE porque DB2 determinar el valor adecuado de pgina de
cdigos a partir del sistema operativo. Si se define para la variable de registro
DB2CODEPAGE un valor incorrecto se pueden producir resultados
inesperados.
La pgina de cdigos de la base de datos se deriva del valor especificado (de
forma explcita o por omisin) en el momento en que se crea la base de datos.
Por ejemplo, lo siguiente define cmo se determina el entorno activo en
distintos sistemas operativos:
UNIX En sistemas operativos basados en UNIX, el entorno activo se
determina a partir del valor de entorno local (locale) que
incluye informacin sobre idioma, territorio y juego de
cdigos.
Para todos los sistemas operativos Windows, si la variable de
entorno DB2CODEPAGE no est definida, la pgina de
cdigos se deriva del valor de pgina de cdigos ANSI del
Registro.
v Supported territory codes and code pages en el manual Administration
Guide: Planning
Derivacin de entornos locales en programas de aplicacin
Los entornos locales se implantan de una manera en sistemas Windows y de
otra en sistemas basados en UNIX. Hay dos entornos locales en sistemas
basados en UNIX:
v El entorno local del entorno le permite especificar el idioma, el smbolo de
moneda, etc. que desea utilizar.
v El entorno local del programa contiene el idioma, smbolo de moneda, etc.
actuales de un programa que se est ejecutando.
En sistemas Windows, las preferencias culturales se pueden definir mediante
Configuracin regional en el Panel de control. Sin embargo, no hay ningn
entorno local del entorno como el de sistemas basados en UNIX.
Cuando se inicia el programa, obtiene un entorno local C por omisin. No
obtiene una copia del entorno local del entorno. Si define como entorno local
del programa cualquier entorno local que no sea C, DB2 Universal Database
utiliza el entorno local del programa actual para determinar los valores de
pgina de cdigos y de territorio correspondientes al entorno de la aplicacin.
Si no es as, estos valores se obtienen del entorno del sistema operativo. Tenga
en cuenta que setlocale() no est libre de hebras y que si emite setlocale()
desde dentro de la aplicacin, el nuevo entorno local se establece para el
proceso entero.
Cmo DB2 deriva entornos locales
En sistemas basados en UNIX, el entorno local activo que utiliza DB2 se
determina a partir de la parte LC_CTYPE del valor del entorno local. Para ver
detalles, consulte la documentacin de NLS correspondiente a su sistema
operativo.
v Si LC_CTYPE del entorno local del programa tiene un valor distinto de C,
DB2 utilizar este valor para determinar la pgina de cdigos de la
aplicacin, correlacionndolo con su pgina de cdigos correspondiente.
v Si LC_CTYPE tiene el valor C (el entorno local C), DB2 definir el entorno
local del programa de acuerdo con el entorno local del entorno, mediante la
funcin setlocale().
v Si LC_CTYPE sigue teniendo el valor C, DB2 adoptar el valor por omisin
de entorno Ingls EE.UU. y la pgina de cdigos 819 (ISO 8859-1).
v Si LC_CTYPE ya no tiene el valor C, se utilizar su nuevo valor para
correlacionarlo con una pgina de cdigos correspondiente.
Guide: Planning
Consideraciones sobre aplicaciones
Las secciones siguientes describen consideraciones que debe tener en cuenta al
codificar una aplicacin.
Consideraciones sobre el soporte de idiomas nacionales y sobre el
desarrollo de aplicaciones
Las series de caracteres constantes en sentencias de SQL esttico se convierten
en el momento de la vinculacin de la pgina de cdigos de la aplicacin a la
pgina de cdigos de la base de datos, y luego se utilizan en el momento de
la ejecucin en esta representacin de pgina de cdigos de la base de datos.
Para evitar estas conversiones si no se desean, puede utilizar variables del
lenguaje principal en lugar de constantes de series.
Si el programa contiene series de caracteres constantes, debe precompilar,
vincular, compilar y ejecutar la aplicacin utilizando la misma pgina de
cdigos. Para una base de datos Unicode, debe utilizar variables del lenguaje
principal en lugar de utilizar constantes de series. La razn de esta
recomendacin es que las conversiones de datos que realiza el servidor se
pueden producir en la fase de vinculacin y en la de ejecucin. Esto puede
resultar un problema si se utilizan series de caracteres contantes dentro del
programa. Estas series incorporadas se convierten en el momento de la
vinculacin segn la pgina de cdigos que est en vigor durante la fase de
vinculacin. Los caracteres ASCII de siete bits son comunes a todas las
pginas de cdigos soportadas por DB2 Universal Database y no ocasionan
problemas. Para caracteres no ASCII, los usuarios se deben asegurar de que se
utilizan las mismas tablas de conversin durante la vinculacin y la ejecucin
con la misma pgina de cdigos activa.
Se supone que cualquier dato externo que obtiene la aplicacin est en la
pgina de cdigos de la aplicacin. Esto incluye datos obtenidos de un
archivo o de entrada del usuario. Asegrese de que los datos procedentes de
fuentes externas a la aplicacin utilizan la misma pgina de cdigos que la
aplicacin.
Si utiliza variables del lenguaje principal que utilizan datos grficos en
aplicaciones C o C++, hay temas especiales relacionados con el precompilador,
el rendimiento de la aplicacin y el diseo de la aplicacin que debe tener en
cuenta. Si utiliza juegos de cdigos EUC en las aplicaciones, consulte los
temas relacionados para ver las directrices generales.
Cuando desarrolle una aplicacin, debe revisar los temas que siguen a este. Si
no sigue las recomendaciones que se describen en estos temas, se pueden
producir condiciones inesperadas. Estas condiciones las puede detectar el
gestor de bases de datos, as que emitir un mensaje de error o de aviso. Por
ejemplo, una aplicacin C contiene las siguientes sentencias de SQL que
operan contra una tabla T1 con una columna definida como C1 CHAR(20):
(0) EXEC SQL CONNECT TO GLOBALDB;
(1) EXEC SQL INSERT INTO T1 VALUES (a-constant);
strcpy(sqlstmt, "SELECT C1 FROM T1 WHERE C1=a-constant);
(2) EXEC SQL PREPARE S1 FROM :sqlstmt;
Donde:
pgina de cdigos de la aplicacin en el momento de la vinculacin = x
pgina de cdigos de la aplicacin en el momento de la ejecucin = y
pgina de cdigos de la base de datos = z
En el momento de la vinculacin 'a-constant' en la sentencia (1) se convierte de
la pgina de cdigos x a la pgina de cdigos z. Esta conversin se representa
como (xz).
En el momento de la ejecucin, 'a-constant' (xz) se inserta en la tabla cuando
se ejecuta la sentencia (1). Sin embargo, la clusula WHERE de la sentencia (2)
se ejecutar con 'a-constant' (yz). Si los puntos de cdigo de la constante son
tales que las dos conversiones (xz e yz) generan resultados diferentes, la
operacin SELECT de la sentencia (2) no podr recuperar los datos insertados
por la sentencia (1).
v Derivacin de valores de pgina de cdigos en la pgina 430
Soporte de idiomas nacionales y sentencias de SQL
La codificacin de sentencias de SQL no depende del idioma. Las palabras
clave de SQL se deben escribir tal como se muestra, aunque se pueden
escribir en maysculas, en minsculas o en una combinacin de ambas. Los
caracteres de los nombres de objetos de base de datos, variables del lenguaje
principal y etiquetas de programa que aparecen en una sentencia de SQL
deben recibir soporte de la pgina de cdigos de la aplicacin.
El servidor no convierte nombres de archivo. Para codificar un nombre de
archivo, puede utilizar el juego invariante ASCII o proporcionar la va de
acceso en los valores hexadecimales que estn fsicamente almacenados en el
sistema de archivos.
En un entorno de varios bytes, hay cuatro caracteres que se consideran
especiales que no pertenecen al juego de caracteres invariante. Estos caracteres
son:
v Los caracteres de porcentaje de doble byte y de subrayado de doble byte
que se utilizan en proceso LIKE.
v El carcter de espacio de doble byte que se utiliza, entre otras cosas, para
rellenar con blancos series grficas.
v El carcter de sustitucin de doble byte, que se utiliza como sustitucin
durante la conversin de pgina de cdigos cuando no existe ninguna
correlacin entre una pgina de cdigos fuente y una pgina de cdigos de
destino.
Los puntos de cdigo para cada uno de estos caracteres, por pgina de
cdigos, son los siguientes:
Tabla 29. Puntos de cdigo para caracteres especiales de doble byte
Pgina de
cdigos
Porcentaje de
doble byte
Subrayado de
doble byte
Espacio de
doble byte
Carcter de
sustitucin de
doble byte
932 X'8193' X'8151' X'8140' X'FCFC'
938 X'8193' X'8151' X'8140' X'FCFC'
942 X'8193' X'8151' X'8140' X'FCFC'
943 X'8193' X'8151' X'8140' X'FCFC'
948 X'8193' X'8151' X'8140' X'FCFC'
949 X'A3A5' X'A3DF' X'A1A1' X'AFFE'
950 X'A248' X'A1C4' X'A140' X'C8FE'
954 X'A1F3' X'A1B2' X'A1A1' X'F4FE'
964 X'A2E8' X'A2A5' X'A1A1' X'FDFE'
970 X'A3A5' X'A3DF' X'A1A1' X'AFFE'
1381 X'A3A5' X'A3DF' X'A1A1' X'FEFE'
1383 X'A3A5' X'A3DF' X'A1A1' X'A1A1'
13488 X'FF05' X'FF3F' X'3000' X'FFFD'
1363 X'A3A5' X'A3DF' X'A1A1' X'A1E0'
1386 X'A3A5' X'A3DF' X'A1A1' X'FEFE'
5039 X'8193' X'8151' X'8140' X'FCFC'
Para bases de datos Unicode, el espacio GRAPHIC es X'0020', que es distinto
del espacio GRAPHIC X'3000' que se utiliza para bases de datos euc-Japan y
euc-Taiwan. Tanto X'0020' como X'3000' son caracteres de espacio en estndar
Unicode. La diferencia en los puntos de cdigo de espacio GRAPHIC se debe
tener en cuenta cuando se comparan datos procedentes de estas bases de
datos EUC con datos procedentes de una base de datos Unicode.
v Predicado LIKE en el manual Consulta de SQL, Volumen 1
v Juegos de caracteres de Extended UNIX Code (EUC) en la pgina 442
Procedimientos almacenados y UDF remotos
Cuando se codifican procedimientos almacenados que se van a ejecutar de
forma remota, se deben tener en cuenta las siguientes consideraciones:
v Los datos de un procedimiento almacenado deben estar en la pgina de
cdigos de la base de datos.
v Los datos que se pasan a un procedimiento almacenado o que se reciben de
este mediante una SQLDA con un tipo de datos de carcter deben contener
realmente datos de carcter. Los datos numricos y las estructuras de datos
nunca se deben pasar con un tipo de carcter si la pgina de cdigos de la
aplicacin cliente es distinta de la pgina de cdigos de la base de datos. El
motivo es que el servidor convertir todos los datos de carcter de una
SQLDA. Para evitar la conversin de caracteres, puede pasar datos
definindolos en formato de serie binaria utilizando un tipo de datos BLOB
o definiendo los datos de carcter como FOR BIT DATA.
Por omisin, cuando se invocan UDF y procedimientos almacenados DARI de
DB2, estos se ejecutan bajo un entorno de idioma nacional por omisin, que
puede no coincidir con el entorno de idioma nacional de la base de datos. Por
lo tanto, la utilizacin de operaciones especficas de pas/regin o de pgina
de cdigos, como funciones y variables del lenguaje principal grficas wchar_t
de C, puede no funcionar segn lo esperado. Se tiene que asegurar de que, si
es necesario, se inicialice el entorno correcto cuando invoque el procedimiento
almacenado o UDF.
Consideraciones sobre nombres de paquetes en entornos de pginas de
cdigos combinadas
Los nombres de paquetes se determinan cuando se invoca la API o mandato
PRECOMPILE PROGRAM. Por omisin, se generan tomando los ocho
primeros bytes del archivo fuente del programa de aplicacin (sin la extensin
de archivos) y se convierten a maysculas. Tambin se puede definir un
nombre de forma explcita. Independientemente del origen de un nombre de
paquete, si trabaja en un entorno de pginas de cdigos que no son iguales,
los caracteres de los nombres de paquetes deben estar en un juego de
caracteres invariante. De lo contrario pueden producirse problemas
relacionados con la modificacin del nombre de paquete. El gestor de bases de
datos no podr encontrar el paquete correspondiente a la aplicacin o una
herramienta del cliente no mostrar el nombre correcto del paquete.
Se producir una modificacin de nombre de paquete debida a conversin de
caracteres si alguno de los caracteres del nombre del paquete no se
correlaciona directamente con un carcter vlido de la pgina de cdigos de la
base de datos. En estos casos, un carcter de sustitucin sustituye al carcter
que no se ha convertido. Tras dicha modificacin, es posible que el nombre
del paquete, cuando se vuelve a convertir a la pgina de cdigos de la
aplicacin, no coincida con el nombre original del paquete. Un ejemplo de un
caso en que no se desea este comportamiento es cuando utiliza el Centro de
control para listar paquetes y para trabajar con los mismos. Es posible que los
nombres de paquetes que se muestran no coincidan con los nombres
esperados.
Para evitar problemas de conversin con nombres de paquetes, asegrese de
que slo se utilizan caracteres que son vlidos para la pgina de cdigos de la
aplicacin y para la de la base de datos.
Pgina de cdigos activa para precompilacin y vinculacin
En el momento de la precompilacin/vinculacin, el precompilador es la
aplicacin que se ejecuta. Se utiliza la pgina de cdigos activa cuando se
realiz la conexin con la base de datos antes de la peticin de
precompilacin para sentencias precompiladas y para los datos que se
devuelven en la SQLCA.
v Pgina de cdigos activa para la ejecucin de aplicaciones en la pgina
436
Pgina de cdigos activa para la ejecucin de aplicaciones
En el momento de la ejecucin, la pgina de cdigos activa de la aplicacin de
usuario cuando se realiza la conexin con la base de datos permanece en
vigor mientras dura la conexin. Todos los datos se interpretan segn esta
pgina de cdigos; esto incluye sentencias de SQL dinmico, datos de entrada
del usuario, datos de salida del usuario y campos de caracteres de la SQLCA.
v Pgina de cdigos activa para precompilacin y vinculacin en la pgina
436
Conversin de caracteres entre distintas pginas de cdigos
Lo ideal para conseguir un rendimiento ptimo sera que las aplicaciones
utilizaran siempre la misma pgina de cdigos que la base de datos. Sin
embargo, esto no siempre es posible o resulta prctico. Los productos DB2
proporcionan soporte para la conversin de pgina de cdigos que permite
que la aplicacin y la base de datos utilicen distintas pginas de cdigos. Los
caracteres de una pgina de cdigos se deben correlacionar con la otra pgina
de cdigos para mantener la integridad de los datos.
Cundo se produce la conversin de pgina de cdigos
La conversin de pgina de cdigos se puede producir en las siguientes
situaciones:
v Cuando un cliente o aplicacin que accede a una base de datos se ejecuta
en una pgina de cdigos distinta de la de la base de datos:
Esta conversin se producir en el cliente de aplicacin para ambas
conversiones, de la pgina de cdigos de la aplicacin a la de la base de
datos y de la pgina de cdigos de la base de datos a la de la aplicacin.
En algunas situaciones puede minimizar o eliminar la conversin de
caracteres cliente/servidor. Por ejemplo, puede:
Crear una base de datos en Windows NT que utilice la pgina de
cdigos 850 para que coincida con un entorno de aplicaciones cliente de
Windows que utiliza predominantemente la pgina de cdigos 850.
Si se utiliza una aplicacin ODBC de Windows con el controlador ODBC
de DB2 de IBM en el cliente de bases de datos de Windows, este
problema se puede mitigar utilizando las palabras clave
TRANSLATEDLL y TRANSLATEOPTION en el archivo odbc.ini o
db2cli.ini.
Crear una base de datos en AIX que utilice la pgina de cdigos 850 para
que coincida con un entorno de aplicaciones cliente que utiliza
predominantemente la pgina de cdigos 850.
v Cuando un cliente o aplicacin que importa un archivo PC/IXF se ejecuta
en una pgina de cdigos distinta de la del archivo que se va a importar.
Esta conversin de datos se producir en la mquina cliente de bases de
datos antes de que el cliente acceda al servidor de bases de datos. Es
posible que se lleve a cabo una conversin de datos adicional si la
aplicacin se ejecuta en una pgina de cdigos distinta de la de la base de
datos (tal como se ha indicado en el punto anterior).
La conversin de datos, si se realiza, tambin depende del modo en que se
haya llamado al programa de utilidad de importacin.
v Cuando se utiliza DB2 Connect para acceder a datos en un sistema
principal, AS/400 o servidor iSeries. En este caso, el receptor de los datos
convierte los datos de caracteres. Por ejemplo, DB2 para MVS/ESA
convierte al identificador de juego de caracteres codificados (CCSID)
adecuado de MVS los datos que se envan a DB2 para MVS/ESA. DB2
Connect convierte los datos que se envan a la mquina DB2 Connect desde
DB2 para MVS/ESA.
No se producir conversin de caracteres para:
v Nombres de archivos. Debe utilizar el juego invariable ASCII para nombres
de archivos o debe proporcionar el nombre de archivo en los valores
hexadecimales que estn fsicamente almacenados en el sistema de archivos.
Tenga en cuenta que, si incluye un nombre de archivo como parte de una
sentencia de SQL, se convierte como parte de la conversin de la sentencia.
v Los datos destinados a una columna que tiene asignado el atributo FOR BIT
DATA o que proceden de sta o los datos que se utilizan en una operacin
de SQL cuyo resultado es datos FOR BIT o BLOB. En estos casos, los datos
se tratan como una corriente de bytes y no se produce ninguna conversin.
Nota: un literal insertado en una columna definida como FOR BIT DATA se
podra convertir si dicho literal formara parte de una sentencia de
SQL que se ha convertido.
v Un producto o plataforma DB2 que no d soporte, o que no tenga el
soporte instalado, a la combinacin deseada de pginas de cdigos. En este
caso, se devuelve un SQLCODE -332 (SQLSTATE 57017) si intenta ejecutar
la aplicacin.
Sustitucin de caracteres durante conversiones de pginas de cdigos
Si la aplicacin realiza una conversin de una pgina de cdigos a otra, es
posible que uno o ms caracteres no estn representados en la pgina de
cdigos de destino. Si esto sucede, DB2 inserta un carcter de sustitucin en la
serie de destino en lugar del carcter que no tiene representacin. El carcter
de sustitucin se considera una parte vlida de la serie. En situaciones en las
que se produce una sustitucin, el indicador SQLWARN10 de la SQLCA
adopta el valor W.
Nota: cualquier otra conversin de caracteres resultante del uso de la opcin
del precompilador WCHARTYPE CONVERT no marcarn un aviso si
se realiza alguna sustitucin.
Conversiones de pginas de cdigos soportadas
Cuando se produce una conversin de datos, la conversin tiene lugar de una
pgina de cdigos fuente a una pgina de cdigos de destino.
La pgina de cdigos fuente se determina a partir de la fuente de los datos;
los datos procedentes de la aplicacin tienen una pgina de cdigos fuente
igual a la pgina de cdigos de la aplicacin y los datos procedentes de la
base de datos tienen una pgina de cdigos fuente igual a la pgina de
cdigos de la base de datos.
La determinacin de la pgina de cdigos de destino es ms complicada; hay
que tener en cuenta dnde se van a colocar los datos, incluidas las normas
correspondientes a operaciones intermedias:
v Si los datos se mueven directamente desde una aplicacin a una base de
datos, sin que intervengan operaciones, la pgina de cdigos de destino es
la de la base de datos.
v Si los datos se importan en una base de datos desde un archivo PC/IXF,
hay dos pasos de conversin de caracteres:
1. Desde la pgina de cdigos del archivo PC/IXF (pgina de cdigos
fuente) a la pgina de cdigos de la aplicacin (pgina de cdigos de
destino)
2. Desde la pgina de cdigos de la aplicacin (pgina de cdigos fuente)
a la pgina de cdigos de la base de datos (pgina de cdigos de
destino)
Debe tener cuidado en situaciones en las que se pueden producir dos pasos
de conversin. Para evitar una posible prdida de datos de caracteres,
asegrese de seguir las conversiones de caracteres soportadas. Adems,
dentro de cada grupo, solo los caracteres que existen en ambas pginas de
cdigos, fuente y destino, tienen conversiones significativas. Se utilizan
otros caracteres como sustituciones y slo resultan tiles para convertir
desde la pgina de cdigos de destino de nuevo a la pgina de cdigos
fuente (y no necesariamente proporcionan conversiones significativas en el
proceso de conversin de dos pasos mencionado anteriormente). Estos
problemas se pueden evitar si la pgina de cdigos de la aplicacin
coincide con la de la base de datos.
v Si los datos se derivan de operaciones realizadas en datos de caracteres, en
los que la fuente puede ser la pgina de cdigos de la aplicacin, la de la
base de datos, FOR BIT DATA o datos BLOB, la conversin de datos se basa
en un conjunto de normas. Es posible que algunos de los elementos de
datos, o todos ellos, se tengan que convertir a un resultado intermedio
antes de que se pueda determinar la pgina de cdigos de destino final.
Nota: las conversiones de pginas de cdigos entre pginas de cdigos de
varios bytes, por ejemplo DBCS y EUC, pueden dar como resultado un
aumento o reduccin de la longitud de la serie.
436
Guide: Planning
Factor de expansin de conversin de pgina de cdigos
Si la aplicacin completa satisfactoriamente un intento de establecer conexin
con un servidor de base de datos DB2, debe tener en cuenta los siguientes
campos en la SQLCA que se devuelve:
v El segundo smbolo del campo SQLERRMC (los smbolos se separan
mediante X'FF') indica la pgina de cdigos de la base de datos. El noveno
smbolo del campo SQLERRMC indica la pgina de cdigos de la
aplicacin. Al consultar la pgina de cdigos de la aplicacin y compararla
con la pgina de cdigos de la base de datos se indica a la aplicacin si ha
establecido una conexin que experimentar conversiones de caracteres.
v La primera y segunda entrada de la matriz SQLERRD. SQLERRD(1)
contiene un valor entero igual al factor mximo esperado de expansin o
contraccin correspondiente a la longitud de datos de caracteres mixtos
(tipos de datos CHAR) cuando se convierten a la pgina de cdigos de la
base de datos desde la pgina de cdigos de la aplicacin. SQLERRD(2)
contiene un valor entero igual al factor mximo esperado de expansin o
contraccin correspondiente a la longitud de datos de caracteres mixtos
(tipos de datos CHAR) cuando se convierten a la pgina de cdigos de la
aplicacin desde la pgina de cdigos de la base de datos. Un valor 0 1
indica que no hay expansin; un valor mayor que 1 indica una posible
expansin de la longitud; un valor negativo indica una posible contraccin.
Las consideraciones correspondientes a datos de series grficas no deberan
tenerse en cuenta en situaciones de pginas de cdigos distintas. Cada serie
tiene siempre el mismo nmero de caracteres, independientemente de si los
datos estn en la pgina de cdigos de la aplicacin o en la de la base de
datos.
v Desarrollo de aplicaciones en situaciones de pginas de cdigos distintas
en la pgina 449
Juegos de caracteres DBCS
Cada pgina de cdigos combinada de juego de caracteres de un solo byte
(SBCS) o de juego de caracteres de doble byte (DBCS) permite puntos de
cdigo de caracteres de un solo byte y de doble byte. Esto se suele conseguir
reservando un subconjunto de los 256 puntos de cdigos disponibles de una
tabla de cdigos mixta para caracteres de un solo byte, con el resto de puntos
de cdigo no definidos o asignados al primer byte de puntos de cdigo de
doble byte. Estos puntos de cdigo se muestran en la tabla siguiente.
Tabla 30. Puntos de cdigo de juegos de caracteres mixtos
Pas/Regin Pgina de cdigos
mixta soportada
Puntos de cdigo
para caracteres de
un solo byte
Puntos de cdigo
para el primer byte
de caracteres de
doble byte
Japn 932, 943 X'00'-X'7F',
X'A1'-X'DF'
X'81'-X'9F',
X'E0'-X'FC'
Japn 942 X'00'-X'80',
X'A0'-X'DF',
X'FD'-X'FF'
X'81'-X'9F',
X'E0'-X'FC'
Taiwn 938 (*) X'00'-X'7E' X'81'-X'FC'
Taiwn 948 (*) X'00'-X'80', X'FD',
X'FE'
X'81'-X'FC'
Corea 949 X'00'-X'7F' X'8F'-X'FE'
Taiwn 950 X'00'-X'7E' X'81'-X'FE'
China 1381 X'00'-X'7F' X'8C'-X'FE'
Corea 1363 X'00'-X'7F' X'81'-X'FE'
China 1386 X'00' X'81'-X'FE'
Nota: (*) esta es una pgina de cdigos antigua que ya no se recomienda.
Los puntos de cdigo que no estn asignados a ninguna de estas categoras
no estn definidos y se procesan como puntos de cdigo no definidos de un
solo byte.
Dentro de cada tabla de cdigos DBCS implcita, hay 256 puntos de cdigo
disponibles como el segundo byte para cada primer byte vlido. Los valores
de segundo byte pueden adoptar cualquier valor comprendido entre X'40' y
X'7E' y entre X'80' y X'FE'. Tenga en cuenta que, en entornos DBCS, DB2 no
realiza la comprobacin de validez de caracteres individuales de doble byte.
Juegos de caracteres de Extended UNIX Code (EUC)
Cada pgina de cdigos EUC permite puntos de cdigo de caracteres de un
solo byte y un mximo de tres juegos diferentes de puntos de cdigo de
caracteres de varios bytes. Este soporte se consigue reservando un
subconjunto de los 256 puntos de cdigo disponibles de cada identificador de
pgina de cdigos SBCS relacionado para caracteres de un solo byte. El resto
de los puntos de cdigo son indefinidos, estn asignados como un elemento
de un carcter de varios bytes o estn asignados como un introductor de un
solo desplazamiento de un carcter de varios bytes. Estos puntos de cdigo se
muestran en las tablas siguientes.
Tabla 31. Puntos de cdigo EUC japons
Grupo 1er byte 2 byte 3er byte 4 byte
G0 X'20'-X'7E' n/d n/d n/d
G1 X'A1'-X'FE' X'A1'-X'FE' n/d n/d
G2 X'8E' X'A1'-X'FE' n/d n/d
G3 X'8E' X'A1'-X'FE' X'A1'-X'FE' n/d
Tabla 32. Puntos de cdigo EUC coreano
G0 X'20'-X'7E' n/d n/d n/d
G2 n/d n/d n/d n/d
G3 n/d n/d n/d n/d
Tabla 33. Puntos de cdigo EUC chino tradicional
G0 X'20'-X'7E' n/d n/d n/d
G2 X'8E' X'A1'-X'FE' X'A1'-X'FE' X'A1'-X'FE'
G3 n/d n/d n/d n/d
Tabla 34. Puntos de cdigo EUC chino simplificado
G0 X'20'-X'7E' n/d n/d n/d
G2 n/d n/d n/d n/d
Tabla 34. Puntos de cdigo EUC chino simplificado (continuacin)
G3 n/d n/d n/d n/d
Los puntos de cdigo que no estn asignados a ninguna de estas categoras
no estn definidos y se procesan como puntos de cdigo no definidos de un
solo byte.
Programas CLI, ODBC, JDBC y SQLj en un entorno DBCS
Los programas JDBC y SQLj acceden a DB2 mediante el controlador
CLI/ODBC de DB2 y por lo tanto utilizan el mismo archivo de configuracin
(db2cli.ini). Se deben aadir las siguientes entradas a este archivo de
configuracin si se ejecutan programas Java que acceden a DB2 Universal
Database en un entorno DBCS:
PATCH1 = 65536
Impone que el controlador inserte manualmente una G delante de
los literales de caracteres que de hecho sean literales grficos. Este
valor de PATCH1 se debe establecer siempre que se trabaje en un
entorno de doble byte.
PATCH1 = 64
Impone que el controlador termine en NULL las series de salida
grficas. Es necesario para Microsoft Access en un entorno de doble
byte. Si tambin tiene que utilizar este valor de PATCH1, deber
aadir los dos valores juntos (64+65536 = 65600) y establecer
PATCH1=65600. Consulte la nota 2 en la pgina 444 siguiente para
obtener ms informacin sobre cmo especificar valores de PATCH1.
PATCH2 = 7
Impone que el controlador correlacione todos los tipos de datos de
columnas de grficos con el tipo de datos de columna de caracteres.
Este valor de PATCH2 es necesario en un entorno de doble byte.
PATCH2 = 10
Slo se debe utilizar en un entorno EUC (Extended Unix Code). Este
valor de PATCH2 asegura que el controlador CLI proporciona datos
correspondientes a variables de caracteres (CHAR, VARCHAR, etc.) en
el formato adecuado para el controlador JDBC. Los datos de estos
tipos de caracteres no se podrn utilizar en JDBC sin este valor.
Notas:
1. Cada una de estas palabras clave se establece en cada seccin especfica de
base de datos del archivo db2cli.ini. Si desea establecerlas para varias
bases de datos, reptalas para cada seccin de base de datos de db2cli.ini.
2. Para establecer varios valores de PATCH1, aada los valores individuales
y utilice la suma. Para establecer PATCH1 en 64 y 65536, establezca
PATCH1=65600 (64+65536). Si ya tiene establecidos otros valores de
PATCH1, sustituya el nmero existente por la suma de dicho nmero y los
nuevos valores de PATCH1 que desee aadir.
3. Para establecer varios valores de PATCH2, especifquelos en una serie
delimitada por comas (a diferencia de la opcin PATCH1). Para establecer
los valores 1 y 7 para PATCH2, establezca PATCH2=1,7
Consideraciones sobre los juegos de cdigos EUC y UCS-2 de japons y chino
tradicional
Las secciones siguientes describen las consideraciones a tener en cuenta para
los juegos de cdigos EUC y UCS-2 de japons y chino tradicional.
Consideraciones sobre los juegos de cdigos EUC y UCS-2 de japons y
chino tradicional
Extended UNIX Code (EUC) indica un conjunto de normas generales de
codificacin que pueden soportar entre uno y cuatro juegos de caracteres en
los entornos operativos basados en UNIX. Las normas de codificacin se
basan en la definicin ISO 2022 para la codificacin de datos de 7 bits y de 8
bits, en los que se utilizan caracteres de control para separar algunos de los
juegos de caracteres. Un juego de cdigos basado en EUC se ajusta a las
normas de codificacin de EUC, pero tambin identifica los juegos de
caracteres especficos asociados a las instancias concretas. Por ejemplo, el
juego de cdigos IBM-eucJP para japons hace referencia a la codificacin de
caracteres en Japanese Industrial Standard segn las normas de codificacin
de EUC.
El soporte de datos grficos (caracteres puros de doble byte) por parte de la
base de datos y de la aplicacin cliente, mientras se ejecutan bajo pginas de
cdigos EUC con una codificacin de caracteres de longitud superior a dos
bytes, es limitado. Los productos DB2 Universal Database implementan
normas estrictas para los datos grficos que requieren que todos los caracteres
contengan exactamente dos bytes. Estas normas no admiten muchos caracteres
de las pginas de cdigos EUC del japons ni del chino tradicional. Para
vencer esta situacin, se proporciona soporte, tanto a nivel de aplicacin como
a nivel de base de datos, para representar los datos grficos EUC en japons y
en chino tradicional utilizando otro esquema de codificacin.
Una base de datos creada bajo EUC de japons o de chino tradicional
realmente almacenar y manipular los datos grficos utilizando el juego de
cdigos Unicode UCS-2, esquema de codificacin de doble byte que
constituye un subconjunto adecuado del repertorio completo de caracteres
Unicode. De forma parecida, una aplicacin que se ejecute bajo estas pginas
de cdigos enviar los datos grficos a la base de datos en forma de datos
codificados en UCS-2. Mediante este soporte, las aplicaciones que se ejecutan
bajo pginas de cdigos EUC pueden acceder a los mismos tipos de datos que
las que se ejecutan bajo pginas de cdigos DBCS. El identificador de pgina
de cdigos definido por IBM asociado a UCS-2 es 1200, y el nmero de
CCSID para la misma pgina de cdigos es 13488. Los datos grficos de una
base de datos eucJP o eucTW utilizan el nmero de CCSID 13488. En una base
de datos Unicode, utilice el CCSID 1200 para los datos GRAPHIC (grficos).
DB2 Universal Database soporta todos los caracteres Unicode que se pueden
codificar utilizando UCS-2, pero no realiza ninguna composicin,
descomposicin ni normalizacin de los caracteres. Puede encontrar ms
informacin acerca del estndar Unicode en el sitio de Unicode Consortium,
www.unicode.org, y en la ltima edicin de la publicacin sobre el estndar
Unicode publicada por Addison Wesley Longman, Inc.
Si trabaja con aplicaciones o bases de datos que utilizan estos juegos de
caracteres, es posible que tenga que considerar la posibilidad de utilizar datos
codificados UCS-2. Cuando se convierten datos grficos UCS-2 a la pgina de
cdigos EUC de la aplicacin, existe la posibilidad de que se incremente la
longitud de los datos. Si se visualizan grandes cantidades de datos, puede que
sea necesario asignar almacenamientos intermedios, convertir y visualizar los
datos en una serie de fragmentos.
En los apartados siguientes se explica cmo manejar los datos en este entorno.
En estas secciones, el trmino EUC se utiliza nicamente para hacer referencia
a los juegos de caracteres EUC del japons y del chino tradicional. Observe
que las explicaciones no se aplican al soporte por parte de DB2 de EUC del
coreano y del chino simplificado, puesto que los datos grficos de estos juegos
de caracteres se representan utilizando la codificacin EUC.
v Desbordamiento de longitud de serie de conversin de pgina de cdigos
en entornos de juegos de cdigos mixtos en la pgina 457
Guide: Planning
v Juegos de caracteres de Extended UNIX Code (EUC) en la pgina 442
Consideraciones sobre las bases de datos y los clientes de doble byte
con EUC mixtos
La administracin de objetos de base de datos en entornos con pginas mixtas
de cdigos EUC y de doble byte resulta complicada por la posible expansin
o contraccin de la longitud de los nombres de objeto como consecuencia de
conversiones entre la pgina de cdigos del cliente y la de la base de datos.
En concreto, muchos mandatos de administracin y programas de utilidad
tienen documentados lmites en la longitud de las series de caracteres que
pueden tomar como parmetros de entrada o salida. Estos lmites se suelen
imponer en el cliente, a no ser que se documente lo contrario. Por ejemplo, el
lmite para un nombre de tabla es de 128 bytes. Es posible que una serie de
caracteres que contiene 128 bytes bajo una pgina de cdigos de doble byte
sea mayor, pongamos de 135 bytes, bajo una pgina de cdigos EUC. Los
mandatos tales como REORGANIZE TABLE no consideraran vlido este
hipottico nombre de tabla de 135 bytes si se utiliza como parmetro de
entrada, a pesar de que sea vlido en la base de datos de doble byte de
destino. De forma parecida, la longitud mxima permitida para los
parmetros de salida se puede exceder, despus de una conversin de la
pgina de cdigos de la base de datos a la pgina de cdigos de la aplicacin.
Esto puede ocasionar un error de conversin o que se produzca un
truncamiento de los datos de salida.
Si prev que va a hacer un amplio uso de mandatos de administracin y
programas de utilidad en un entorno mixto con EUC y doble byte, debe
definir los objetos de base de datos y los datos asociados a los mismos con la
posibilidad de que la longitud supere los lmites soportados. La
administracin de una base de datos EUC desde un cliente de doble byte
impone menos restricciones que la administracin de una base de datos de
doble byte desde un cliente EUC. Normalmente, las series de caracteres de
doble byte son iguales o ms cortas que las series de caracteres EUC
correspondientes. Esta caracterstica generalmente conducir a que se
produzcan menos problemas debidos a la imposicin de los lmites en la
longitud de las series de caracteres.
Nota: en el caso de las sentencias de SQL, la validacin de los parmetros de
entrada no se lleva a cabo hasta que se ha convertido la sentencia
completa a la pgina de cdigos de la base de datos. As, se pueden
utilizar series de caracteres que pueden ser tcnicamente ms largas de
lo permitido cuando se representen en la pgina de cdigos del cliente,
pero que se ajusten a los requisitos de longitud cuando se representen
en la pgina de cdigos de la base de datos.
Consideraciones sobre la conversin de caracteres para usuarios de
chino tradicional
Debido a la definicin de estndares para el chino tradicional, existe un efecto
colateral con que se puede encontrar cuando convierta algunos caracteres de
pginas de cdigos EUC o de doble byte y UCS-2. Existen 189 caracteres (que
consisten en 187 radicales y 2 nmeros) que comparten el mismo elemento de
cdigo UCS-2, cuando se convierten, que otro carcter del juego de cdigos.
Cuando estos caracteres se vuelven a convertir a EUC o doble byte, se
convierten al elemento de cdigo del mismo ideograma UCS-2, en lugar del
elemento de cdigo original. Cuando se visualizan, los caracteres parecen
iguales, pero tienen un elemento de cdigo distinto. Segn el diseo de la
aplicacin, es posible que deba tener en cuenta este comportamiento.
Como ejemplo, considere lo que sucede con el elemento de cdigo A7A1 en la
pgina de cdigos EUC 964, cuando se convierte a UCS-2 y luego se vuelve a
convertir a la pgina de cdigos original, EUC 946:
EUC 946 UCS-2 EUC 946
A7A1
C4A1
UCS-2 C4A1
As, los elementos de cdigo originales A7A1 y C4A1 terminan siendo C4A1
despus de la conversin.
Si necesita las tablas de conversin de pginas de cdigos correspondientes a
las pginas de cdigos EUC EUC 946 (EUC de chino tradicional) o 950 (Big-5
de chino tradicional) y UCS-2, consulte el recurso en lnea Product and
Service Technical Library.
Datos grficos en aplicaciones EUC en japons o chino tradicional
La informacin siguiente describe consideraciones sobre el desarrollo de
aplicaciones EUC para datos grficos, que incluyen constantes grficas, datos
grficos en UDF, procedimientos almacenados, archivos DBCLOB y
clasificacin:
v Constantes grficas
Las constantes grficas, o literales, se clasifican realmente como datos
mixtos de tipo carcter, puesto que forman parte de una sentencia de SQL.
El servidor de base de datos convierte implcitamente a la codificacin de
grficos cualquier constante grfica de una sentencia de SQL procedente de
un cliente EUC japons o chino tradicional. En las aplicaciones SQL se
pueden utilizar caracteres grficos compuestos por caracteres codificados en
EUC. Un servidor de base de datos EUC convertir dichos literales al juego
de cdigos de la base de datos grficos, que ser UCS-2. Las constantes
grficas procedentes de los clientes EUC nunca deben contener caracteres
de una sola anchura, como por ejemplo los caracteres ASCII CS0 de 7 bits o
los caracteres en japons EUC CS2 (Katakana).
v UDF
Se invoca a las UDF en el servidor de base de datos y estn destinadas a
tratar con datos codificados en el mismo juego de cdigos que la base de
datos. En el caso de las bases de datos que se ejecutan bajo los juegos de
caracteres del japons o del chino tradicional, los datos mixtos de tipo
carcter se codifican utilizando el juego de cdigos EUC bajo el que se crea
la base de datos. Los datos grficos se codifican utilizando UCS-2. Las UDF
tienen que reconocer y manejar datos grficos codificados con UCS-2.
Por ejemplo, supongamos que crea una UDF denominada VARCHAR y la
UDF convierte una serie grfica en una serie de caracteres mixtos. Si la base
de datos se crea bajo el juego de cdigos EUC, la funcin VARCHAR tendr
que convertir una serie grfica codificada como UCS-2 en una
representacin EUC.
Un procedimiento almacenado que se ejecute bajo un juego de cdigos EUC
del japons o del chino tradicional debe ser capaz de reconocer y manejar
datos grficos codificados utilizando UCS-2. Con estos juegos de cdigos,
los datos grficos recibidos o devueltos a travs del SQLDA de
entrada/salida del procedimiento almacenado se codifican utilizando
UCS-2.
v Archivos DBCLOB
Las consideraciones importantes que deben tenerse en cuenta para archivos
DBCLOB son:
Se supone que un archivo de datos DBCLOB est en la pgina de
cdigos EUC de la aplicacin. Para los archivos DBCLOB en EUC, los
datos se convierten a UCS-2 en el cliente cuando se produce una lectura,
y de UCS-2 en el cliente cuando se trata de una grabacin.
El nmero de bytes ledos o grabados en el servidor se devuelve en el
campo de longitud de datos de la variable de referencia a archivo. El
nmero de bytes se basa en el nmero de caracteres codificados en
UCS-2 que se leen del archivo o que se graban en el mismo. El nmero
de bytes que realmente se lee del archivo o que se graba en el mismo
puede ser mayor que lo que el servidor graba en el campo de longitud
de datos.
v Clasificacin
Los datos grficos se clasifican en secuencia binaria. Los datos mixtos se
clasifican en la secuencia de clasificacin de la base de datos aplicada en
cada byte. Debido a las posibles diferencias en la clasificacin de caracteres
en un juego de cdigos EUC y en un juego de cdigos DBCS para el mismo
pas/regin, se pueden obtener resultados distintos cuando se clasifican los
mismos datos en una base de datos EUC y en una base de datos DBCS.
v Funcin escalar GRAPHIC en el manual Consulta de SQL, Volumen 1
v SELECT sentencia en el manual Consulta de SQL, Volumen 2
v Series grficas en el manual Consulta de SQL, Volumen 1
Desarrollo de aplicaciones en situaciones de pginas de cdigos
distintas
En funcin de los esquemas de codificacin de caracteres utilizados por la
pgina de cdigos de la aplicacin y la pgina de cdigos de la base de datos,
se puede producir o no producir un cambio en la longitud de una serie
cuando sta se convierte de la pgina de cdigos de origen a la pgina de
cdigos de destino. Un cambio en la longitud se suele asociar a conversiones
entre pginas de cdigos de mltiples bytes con distintos esquemas de
codificacin, por ejemplo DBCS y EUC.
Generalmente, un posible incremento de la longitud es ms grave que una
posible disminucin de sta, puesto que una sobreasignacin de memoria
resulta menos problemtica que una subasignacin. Hay que tratar por
separado las consideraciones sobre las aplicaciones para enviar o recuperar
datos en funcin del lugar en que se puede producir la posible expansin.
Tambin es importante observar las diferencias entre una situacin de mejor
caso y de peor caso cuando se indica una expansin o contraccin de la
longitud. Los valores positivos, que indican una posible expansin, darn el
factor de multiplicacin del peor caso. Por ejemplo, un valor de 2 para el
campo SQLERRD(1) o SQLERRD(2) significa que se necesitar un
almacenamiento mximo del doble de la longitud de la serie para manejar los
datos despus de la conversin. ste es un indicador del peor caso. En este
ejemplo, el mejor caso sera que, tras la conversin, la longitud no variara.
Los valores negativos para SQLERRD(1) o SQLERRD(2), que indican una
posible contraccin, tambin proporcionan el factor de expansin del peor caso.
Por ejemplo, un valor de -1 significa que el almacenamiento mximo
necesario es igual a la longitud de la serie antes de la conversin. Claro que es
posible que se necesite menos almacenamiento, pero prcticamente esto tiene
poca utilidad, a no ser que la aplicacin receptora sepa por adelantado cmo
estn estructurados los datos de origen.
Para asegurarse de que siempre tendr asignado suficiente almacenamiento
para abarcar la mxima expansin posible despus de una conversin de
caracteres, debe asignar un almacenamiento igual al valor de
max_target_length obtenido del clculo siguiente:
1. Determine el factor de expansin de los datos.
Para las transferencias de datos desde la aplicacin a la base de datos:
expansion_factor = ABS[SQLERRD(1)]
if expansion_factor = 0
expansion_factor = 1
Para las transferencias de datos desde la base de datos a la aplicacin:
expansion_factor = ABS[SQLERRD(2)]
if expansion_factor = 0
expansion_factor = 1
En los clculos anteriores, ABS hace referencia al valor absoluto.
La comprobacin de expansion_factor = 0 es necesaria, puesto que
algunos productos DB2 Universal Database devuelven 0 en SQLERRD(1) y
en SQLERRD(2). Estos servidores no soportan conversiones de pgina de
cdigos que tengan como resultado una expansin o una merma de los
datos; esto se representa mediante un factor de expansin de 1.
2. Clculo intermedio de la longitud.
temp_target_length = actual_source_length * expansion_factor
3. Determine la longitud mxima para el tipo de datos de destino.
Tipo de datos de destino Longitud mxima del tipo
(type_maximum_lenght)
CHAR 254
VARCHAR 32.672
LONG VARCHAR 32.700
CLOB 2.147.483.647
4. Determine la longitud mxima de destino.
1 if temp_target_length < actual_source_length
max_target_length = type_maximum_length
else
2 if temp_target_length > type_maximum_length
max_target_length = type_maximum_length
else
3 max_target_length = temp_target_length
Todas las comprobaciones anteriores son necesarias para tener en cuenta
los desbordamientos que se puedan producir durante el clculo de la
longitud. Las comprobaciones especficas son:
1 Se produce un desbordamiento numrico durante el clculo de
temp_target_length en el paso 2.
Si el resultado de multiplicar dos valores positivos juntos es mayor
que el valor mximo para el tipo de datos, el resultado se reinicia y
se devuelve un valor menor que el mayor de los dos.
Por ejemplo, el valor mximo de un entero de 2 bytes con signo
(que se utiliza para la longitud de los tipos de datos que no son
CLOB) es 32.767. Si actual_source_length es 25.000 y el factor de
expansin es 2, temp_target_lenght es, tericamente, 50.000. Este
valor es demasiado alto para el entero de 2 bytes con signo, por lo
que se reinicia y se devuelve -15.536.
Para el tipo de datos CLOB, se utiliza para la longitud un entero
de 4 bytes con signo. El valor mximo de un entero de 4 bytes con
signo es 2.147.483.647.
2 temp_target_length es demasiado grande para el tipo de datos.
La longitud de un tipo de datos no puede superar los valores
listados en el paso 3.
Si la conversin requiere ms espacio del que hay disponible en el
tipo de datos, puede existir la posibilidad de utilizar un tipo de
datos ms grande para que contenga el resultado. Por ejemplo, si
un valor CHAR(250) requiere 500 bytes para contener la serie
convertida, sta no cabr en un valor CHAR porque la longitud
mxima es de 254 bytes. Sin embargo, existe la posibilidad de
utilizar VARCHAR(500) para contener el resultado despus de la
conversin. Consulte el tema sobre desbordamiento de longitud de
serie en conversin de pgina de cdigos en entornos de juegos de
cdigos mixtos para obtener ms informacin sobre lo que sucede
cuando los datos convertidos sobrepasan el lmite correspondiente
a un tipo de datos.
3 temp_target_lenght es la longitud correcta para el resultado.
Utilizando los valores de SQLERRD(1) y SQLERRD(2) devueltos al conectar
con la base de datos y los clculos anteriores, puede determinar si existen
posibilidades de que la longitud de una serie aumente o disminuya como
consecuencia de la conversin de caracteres. En general, un valor de 0 1
indica que no se producir ninguna expansin; un valor superior a 1 indica
una posible expansin de la longitud; un valor negativo indica una posible
contraccin. Observe que los valores de 0 slo provendrn de productos DB2
Universal Database de versiones anteriores. Asimismo, estos valores no estn
definidos para otros productos de servidor de base de datos. La tabla
siguiente contiene los valores a esperar para diversas combinaciones de
pgina de cdigos de aplicacin y pgina de cdigos de base de datos cuando
se utiliza DB2 Universal Database.
Tabla 35. Valores de SQLCA.SQLERRD en CONNECT
Pgina de cdigos
de la aplicacin
Pgina de cdigos
de la base de datos
SQLERRD(1) SQLERRD(2)
SBCS SBCS +1 +1
DBCS DBCS +1 +1
eucJP eucJP +1 +1
eucJP DBCS -1 +2
DBCS eucJP +2 -1
eucTW eucTW +1 +1
eucTW DBCS -1 +2
DBCS eucTW +2 -1
eucKR eucKR +1 +1
eucKR DBCS +1 +1
DBCS eucKR +1 +1
eucCN eucCN +1 +1
eucCN DBCS +1 +1
DBCS eucCN +1 +1
Si los valores SQLERRD(1) o SQLERRD(2) indican una expansin en el
servidor de base de datos o en el cliente de aplicacin, debe tener en cuenta lo
siguiente:
v Expansin en el servidor de base de datos
Si la entrada SQLERRD(1) indica una expansin en el servidor de base de
datos, la aplicacin debe contemplar la posibilidad de que los datos de tipo
carcter dependientes de la longitud que sean vlidos en el cliente no lo
sean en el servidor de base de datos, despus de que se hayan convertido.
Por ejemplo, los productos DB2 requieren que los nombres de columna no
tengan una longitud superior a 128 bytes. Es posible que una serie de
caracteres que tenga una longitud de 128 bytes codificada bajo una pgina
de cdigos DBCS se expanda sobrepasando el lmite de 128 bytes cuando se
convierta a una pgina de cdigos EUC. Esta posibilidad implica que
pueden existir actividades que sean vlidas cuando la pgina de cdigos de
la aplicacin y la pgina de cdigos de la base de datos sean iguales y no lo
sean cuando sean distintas. Cuando disee bases de datos EUC y DBCS
para situaciones de pginas de cdigos distintas, proceda con precaucin.
v Expansin en la aplicacin
Si la entrada SQLERRD(1) indica una expansin en la aplicacin cliente, la
aplicacin debe contemplar la posibilidad de que los datos de tipo carcter
dependientes de la longitud vern expandida su longitud una vez que se
hayan convertido. Por ejemplo, se recupera una fila con una columna
CHAR(128). Si las pginas de cdigos de la base de datos y de la aplicacin
son iguales, la longitud de los datos devueltos es de 128 bytes. Sin
embargo, en una situacin de pginas de cdigos distintos, 128 bytes de
datos codificados bajo una pgina de cdigos DBCS se pueden expandir
hasta sobrepasar 128 bytes cuando se conviertan a una pgina de cdigos
EUC. As, es posible que haya que asignar almacenamiento adicional para
recuperar la serie completa.
Validacin de parmetros basada en cliente en un entorno de juegos de
cdigos mixtos
Un efecto colateral importante de una potencial expansin o contraccin de
los datos de tipo carcter entre el cliente y el servidor implica la validacin de
los datos que se pasen entre la aplicacin cliente y el servidor de base de
datos. En una situacin de pginas de cdigos desiguales, es posible que los
datos que se determine que son vlidos en el cliente sean realmente no
vlidos en el servidor de base de datos despus de una conversin de pginas
de cdigos. Y, a la inversa, los datos que no son vlidos en el cliente pueden
serlo en el servidor de base de datos tras la conversin.
Existe la posibilidad de que cualquier aplicacin de usuario final o biblioteca
de API no sea capaz de manejar todas las posibilidades en una situacin de
pginas de cdigos desiguales. Adems, mientras que algunas validaciones de
parmetros, como por ejemplo la longitud de las series, se realizan en el
cliente para los mandatos y las API, las seales internas de las sentencias de
SQL no se verifican hasta que se han convertido a la pgina de cdigos de la
base de datos. Esta verificacin puede conducir a situaciones en que sea
posible utilizar una sentencia de SQL en un entorno de pginas de cdigos
desiguales para acceder a un objeto de base de datos, como por ejemplo una
tabla, pero que no sea posible acceder al mismo objeto utilizando una API o
un mandato determinados.
Piense en una aplicacin que devuelva datos contenidos en una tabla
proporcionada por un usuario final y compruebe que el nombre de tabla no
tiene una longitud superior a 128 bytes. Considere ahora los escenarios
siguientes para esta aplicacin:
1. Se crea una base de datos DBCS. Desde un cliente DBCS, se crea una tabla
(t1) con un nombre de tabla que tiene una longitud de 128 bytes. El
nombre de tabla incluye varios caracteres que constaran de ms de dos
bytes si se convirtiera la serie a EUC, lo que dara como resultado que la
representacin EUC del nombre de tabla tuviera una longitud total de 131
bytes. Puesto que no existe ninguna expansin para las conexiones de
DBCS a DBCS, el nombre de tabla tendra 128 bytes en el entorno de la
base de datos y la sentencia CREATE TABLE sera satisfactoria.
2. Un cliente EUC se conecta a la base de datos DBCS. Crea una tabla (t2)
cuyo nombre de tabla tiene una longitud de 120 bytes cuando se codifica
como EUC y de 100 bytes cuando se convierte a DBCS. El nombre de tabla
en la base de datos DBCS tiene 100 bytes. La sentencia CREATE TABLE es
satisfactoria.
3. El cliente EUC crea una tabla (t3) cuyo nombre de tabla contiene 64
caracteres EUC (131 bytes). Cuando se convierte este nombre a DBCS, su
longitud se reduce hasta el lmite de 128 bytes. La sentencia CREATE
TABLE es satisfactoria.
4. El cliente EUC invoca a la aplicacin para cada una de las tablas (t1, t2 y
t3) de la base de datos DBCS, que da el resultado siguiente:
Tabla Resultado
t1 La aplicacin considera que el nombre de tabla no es
vlido porque tiene una longitud de 131 bytes.
t2 Visualiza resultados correctos.
t3 La aplicacin considera que el nombre de tabla no es
vlido porque tiene una longitud de 131 bytes.
5. Se utiliza el cliente EUC para consultar la base de datos DBCS desde el
CLP. Aunque el nombre de tabla tenga una longitud de 131 bytes en el
cliente, las consultas resultan satisfactorias porque el nombre de tabla tiene
una longitud de 128 bytes en el servidor.
Sentencia DESCRIBE en entornos de juegos de cdigos mixtos
Una sentencia DESCRIBE realizada para una base de datos EUC devolver
informacin sobre columnas mixtas de caracteres y grficos (GRAPHIC) en
base a la definicin de dichas columnas en la base de datos. Esta informacin
se basa en la pgina de cdigos del servidor antes de que se convierta a la
pgina de cdigos del cliente.
Cuando se ejecuta una sentencia DESCRIBE para un elemento de una lista de
seleccin que se resuelve en el contexto de la aplicacin (por ejemplo, VALUES
SUBSTR(?,1,2)) para cualquier dato de tipo carcter o grfico implicado, se
debe evaluar el valor de SQLLEN devuelto, junto con la pgina de cdigos
devuelta. Si la pgina de cdigos devuelta es la misma que la pgina de
cdigos de la aplicacin, no se produce ninguna expansin. Si la pgina de
cdigos devuelta es la misma que la pgina de cdigos de la base de datos, es
posible que se produzca una expansin. Los elementos de lista de seleccin
que son FOR BIT DATA (pgina de cdigos 0), o si en la pgina de cdigos de
la aplicacin no se convierten al devolverlos a la aplicacin, no se produce
ninguna expansin ni contraccin de la longitud informada.
Las consideraciones son distintas para una aplicacin EUC que accede a una
base de datos DBCS, en comparacin con una aplicacin DBCS que accede a
una base de datos EUC:
v Aplicacin EUC que accede a una base de datos DBCS
Si la pgina de cdigos de la aplicacin es una pgina de cdigos EUC, y si
sta emite una sentencia DESCRIBE para una base de datos que tiene una
pgina de cdigos DBCS, la informacin devuelta para las columnas CHAR
y GRAPHIC se devuelve en el contexto de la base de datos. Por ejemplo,
una columna CHAR(5) devuelta como parte de una sentencia DESCRIBE
que tiene un valor de cinco en el campo SQLLEN. En el caso de datos que
no son EUC, se asignan cinco bytes de almacenamiento cuando se captan
los datos de esta columna. Con los datos EUC, el caso puede ser distinto. Si
tiene lugar una conversin de pgina de cdigos de DBCS a EUC, se puede
producir un incremento de la longitud de los datos debido a la codificacin
distinta utilizada para los caracteres de las columnas CHAR. Por ejemplo,
con el juego de caracteres del chino tradicional, el aumento mximo es el
doble. Es decir, la longitud mxima de un carcter en la codificacin DBCS
es de dos bytes, que puede aumentar hasta una longitud mxima de cuatro
bytes en EUC. Para el juego de cdigos del japons, el incremento mximo
tambin es el doble. Sin embargo, observe que, mientras que la longitud
mxima de un carcter en DBCS del japons es de dos bytes, puede
aumentar hasta un mximo de tres bytes en EUC del japons. Aunque este
incremento slo parece corresponder a un factor de 1,5, los caracteres
Katakana de un solo byte en DBCS del japons tienen slo una longitud de
un byte, mientras que en el EUC del japons tienen una longitud de dos
bytes.
Los cambios posibles en la longitud de los datos como consecuencia de
conversiones de caracteres slo se aplican a los datos mixtos de tipo
carcter. La codificacin de datos de caracteres grficos siempre tiene la
misma longitud, dos bytes, independientemente del esquema de
codificacin. Para evitar una prdida de datos, es necesario evaluar si existe
una situacin de pginas de cdigos desiguales, y si sta se produce entre
una aplicacin EUC y una base de datos DBCS. Puede determinar la pgina
de cdigos de la base de datos y la de la aplicacin mediante las seales de
la SQLCA devuelta por una sentencia CONNECT. Si existe una situacin de
este tipo, es necesario que la aplicacin asigne almacenamiento adicional
para los datos mixtos de tipo carcter en base al factor de expansin
mxima para ese esquema de codificacin.
v Aplicacin DBCS que accede a una base de datos EUC
Si la pgina de cdigos de la aplicacin es una pgina de cdigos DBCS y
emite una sentencia DESCRIBE para una base de datos EUC, la situacin es
parecida a la que se produce cuando una aplicacin EUC accede a una base
de datos DBCS. Sin embargo, en esta situacin es posible que la aplicacin
necesite menos almacenamiento que el indicado por el valor del campo
SQLLEN. El peor caso en esta situacin es que todos los datos sean de un
solo byte o de doble byte bajo EUC, lo cual significa que se requieren
exactamente SQLLEN bytes en el esquema de codificacin DBCS. En
cualquier otra situacin se necesitan menos de SQLLEN bytes, puesto que
se requiere un mximo de dos bytes para almacenar cualquier carcter
EUC.
v Derivacin de valores de pgina de cdigos en la pgina 430
Datos de longitud fija y de longitud variable en entornos de juegos de
cdigos mixtos
Debido a un posible cambio en la longitud de las series cuando se producen
conversiones entre pginas de cdigos DBCS y EUC, debe contemplar la
posibilidad de no utilizar tipos de datos de longitud fija. Segn si necesita o
no que se realice espacios en blanco de relleno, debe considerar la posibilidad
de cambiar el SQLTYPE de una serie de caracteres de longitud fija por una
serie de caracteres de longitud variable despus de ejecutar la sentencia
DESCRIBE. Por ejemplo, si se informa de una conexin de EUC a DBCS de un
factor mximo de expansin de dos para una columna CHAR(5), la aplicacin
debe asignar diez bytes.
Si el SQLTYPE es de longitud fija, la aplicacin EUC recibir la columna como
una corriente de datos EUC convertida a partir de los datos DBCS (que, en s
misma, puede tener hasta cinco bytes de espacios en blanco de relleno) con un
espacio en blanco de relleno adicional si la conversin de pgina de cdigos
no ocasiona que el elemento de datos crezca hasta su tamao mximo. Si el
SQLTYPE es de longitud variable, se mantiene el significado original del
contenido de la columna CHAR(5); no obstante, los cinco bytes de origen
pueden tener un destino de entre cinco y diez bytes. De forma parecida, en
caso de una posible reduccin de los datos (aplicacin DBCS y base de datos
EUC), debe considerar la posibilidad de trabajar con tipos de datos de
longitud variable.
Una alternativa a la asignacin de espacio adicional o a la gestin del tipo de
datos consiste en seleccionar los datos por fragmentos. Por ejemplo, para
seleccionar el mismo VARCHAR(3000), que puede alcanzar 6000 bytes de
longitud despus de la conversin, puede realizar dos selecciones separadas,
SUBSTR(VC3000, 1, LENGTH(VC3000)/2) y SUBSTR(VC3000,
(LENGTH(VC3000)/2)+1), en 2 reas de aplicacin VARCHAR(3000). Este
mtodo constituye la nica solucin posible cuando el tipo de datos ya no se
puede gestionar. Por ejemplo, un CLOB codificado en la pgina de cdigos
DBCS del japons con una longitud mxima de 2 gigabytes, posiblemente
alcanzar dos veces su tamao cuando se codifique en la pgina de cdigos
EUC del japons. Esto significa que los datos se tendrn que dividir en
fragmentos, puesto que no existe soporte para un tipo de datos cuya longitud
supere 2 gigabytes.
Desbordamiento de longitud de serie de conversin de pgina de cdigos
en entornos de juegos de cdigos mixtos
En entornos de pginas de cdigos desiguales EUC y DBCS, despus de que
tenga lugar una conversin se pueden producir situaciones en que en una
columna no haya suficiente espacio asignado para acomodar la serie entera.
En este caso, la expansin mxima ser dos veces la longitud de la serie en
bytes. En los casos en que la expansin supera la capacidad de la columna, se
devuelve SQLCODE -334 (SQLSTATE 22524).
Esto conduce a situaciones que pueden no resultar obvias de inmediato ni
consideradas previamente:
v Una sentencia de SQL no puede tener una longitud superior a 32 765 bytes.
Si la sentencia es suficientemente compleja o utiliza suficientes constantes o
nombres de objetos que puedan estar sujetos a una expansin al
convertirlos, se puede alcanzar este lmite antes de lo esperado.
v Los identificadores de SQL tienen permitido expandirse al convertirlos
hasta su longitud mxima, que es de ocho bytes para los identificadores
cortos y de 128 bytes para los identificadores largos.
v Los identificadores de lenguaje principal tienen permitido expandirse al
convertirlos hasta su longitud mxima, que es de 255 bytes.
v Cuando se convierten los campos de caracteres de la estructura SQLCA,
slo tienen permitido expandirse hasta su longitud mxima definida.
Cuando disee aplicaciones para entornos de juegos de cdigos mixtos, debe
consultar la documentacin adecuada si se encuentra con una de las
siguientes situaciones:
v Columnas de serie correspondientes en selecciones completas con
operaciones de establecimiento (UNION, INTERSECT y EXCEPT)
v Operandos de concatenacin
v Operandos de predicados (con la excepcin de LIKE)
v Expresiones de resultados de una sentencia CASE
v Argumentos de la funcin escalar COALESCE (y VALUE)
v Valores de expresin de la lista IN de un predicado IN
v Expresiones correspondientes de una clusula VALUES de varias filas
En estas situaciones, pueden tener lugar conversiones a la pgina de cdigos
de la aplicacin en lugar de hacerlo a la pgina de cdigos de la base de
datos.
Otras situaciones que debe tener en cuenta son aquellas en las que la
conversin de caracteres da como resultado una longitud de serie que
sobrepasa el lmite correspondiente al tipo de datos y conversiones de pgina
de cdigos en procedimientos almacenados:
v Conversin de caracteres sobrepasa un lmite de tipo de datos
En entornos de pginas de cdigos desiguales EUC y DBCS, despus de
que tenga lugar una conversin se pueden producir situaciones en que la
longitud de una serie de caracteres mixtos o grfica supere la longitud
mxima permitida para ese tipo de datos. Si la longitud de la serie, despus
de una expansin, supera el lmite del tipo de datos, no se produce ninguna
gestin del tipo. En cambio, se devuelve un mensaje de error que indica
que se ha excedido la longitud mxima de expansin permitida. Es ms
probable que se produzca esta situacin mientras se evalan predicados que
durante las inserciones. En las inserciones, la aplicacin conoce ms pronto
la anchura de la columna y el factor de expansin mxima se puede tener
en cuenta enseguida. En muchos casos, se puede evitar este efecto colateral
de la conversin de caracteres cambiando el valor por un tipo de datos
asociado cuya longitud mxima sea mayor. Por ejemplo, la longitud
mxima de un valor CHAR es de 254 bytes, mientras que la longitud
mxima de un VARCHAR es de 32 672 bytes. En los casos en que la
expansin no supera la longitud mxima del tipo de datos, se devuelve
SQLCODE -334 (SQLSTATE 22524).
v Conversin de pgina de cdigos en un procedimiento almacenado
Los datos de caracteres mixtos o grficos especificados en variables de
lenguaje principal y SQLDA en invocaciones a sqleproc() o a CALL de
SQL se convierten en las situaciones en que las pginas de cdigos de la
aplicacin y de la base de datos son distintas. En los casos en que se
produce una expansin de la longitud de la serie como consecuencia de la
conversin, se recibe un SQLCODE -334 (SQLSTATE 22524) si no hay
suficiente espacio asignado para manejar la expansin. As, cuando cree
procedimientos almacenados, se debe asegurar de proporcionar suficiente
espacio para una expansin potencial de las series. Debe utilizar tipos de
datos de longitud variable con un espacio asignado suficiente que permita
la expansin.
v Funcin escalar COALESCE en el manual Consulta de SQL, Volumen 1
v Funcin escalar VALUE en el manual Consulta de SQL, Volumen 1
v Seleccin completa en el manual Consulta de SQL, Volumen 1
v VALUES sentencia en el manual Consulta de SQL, Volumen 2
v Sentencia CASE en el manual Consulta de SQL, Volumen 2
v Predicados en el manual Consulta de SQL, Volumen 1
Aplicaciones conectadas a bases de datos Unicode
Las aplicaciones de cualquier entorno de pgina de cdigos se pueden
conectar a una base de datos Unicode. Para las aplicaciones que se conectan a
una base de datos Unicode, el gestor de bases de datos convierte los datos de
serie de caracteres entre la pgina de cdigos de la aplicacin y la pgina de
cdigos de la base de datos (UTF-8). Para una base de datos Unicode, los
datos GRAPHIC estn en orden UCS-2 big-endian. Sin embargo, cuando se
utiliza el procesador de lnea de mandatos para recuperar datos grficos, los
caracteres grficos tambin se convierten a la pgina de cdigos del cliente.
Esta conversin permite que el procesador de lnea de mandatos visualice
caracteres grficos en el font actual. Se puede producir una prdida de datos
siempre que el gestor de bases de datos convierta caracteres UCS-2 a la
pgina de cdigos de un cliente. Los caracteres que el gestor de bases de
datos no puede convertir en caracteres vlidos en la pgina de cdigos del
cliente se sustituyen por el carcter de sustitucin por omisin de dicha
pgina de cdigos.
Nota: la informacin que se aplica a las aplicaciones en cdigo mixto tambin
se aplica a las aplicaciones que se conectan a bases de datos Unicode.
Cuando DB2 convierte caracteres de una pgina de cdigos a UTF-8, el
nmero total de bytes que representan los caracteres se puede expandir o
reducir, segn la pgina de cdigos y los elementos de cdigo de los
caracteres. Los caracteres ASCII de 7 bits permanecen invariables en UTF-8, y
cada carcter ASCII necesita un byte. Los caracteres que no son ASCII pasan a
ocupar ms de un byte cada uno. Para obtener ms informacin sobre
conversiones UTF-8, consulte los documentos estndar de Unicode.
Para las aplicaciones que se conectan a una base de datos Unicode, los datos
GRAPHIC ya estn en Unicode. Para las aplicaciones que se conectan a bases
de datos DBCS, los datos GRAPHIC se convierten entre la pgina de cdigos
DBCS de la aplicacin y la pgina de cdigos DBCS de la base de datos. Las
aplicaciones Unicode deben llevar a cabo las conversiones necesarias a
Unicode y desde ellas mismas o deben definir la opcin WCHARTYPE
CONVERT y utilizar wchar_t para datos grficos.
v Unicode handling of data types en el manual Administration Guide:
Planning
v String comparisons in a Unicode database en el manual Administration
Guide: Planning
v Consideraciones sobre nombres de paquetes en entornos de pginas de
cdigos combinadas en la pgina 435
v Consideraciones sobre las bases de datos y los clientes de doble byte con
EUC mixtos en la pgina 446
v Validacin de parmetros basada en cliente en un entorno de juegos de
cdigos mixtos en la pgina 453
v Sentencia DESCRIBE en entornos de juegos de cdigos mixtos en la
pgina 454
v Datos de longitud fija y de longitud variable en entornos de juegos de
cdigos mixtos en la pgina 456
Captulo 16. Gestin de transacciones
Unidad de trabajo remota . . . . . . . 461
Consideraciones sobre la actualizacin
mltiple . . . . . . . . . . . . . 461
Actualizacin mltiple . . . . . . . 461
Cundo utilizar la actualizacin mltiple 462
Sentencias de SQL en aplicaciones de
Precompilacin de aplicaciones de
Consideraciones sobre parmetros de
configuracin correspondientes a
aplicaciones de actualizacin mltiple . . 467
Acceso a servidores de sistema principal,
AS/400 o iSeries . . . . . . . . . . 469
Transacciones simultneas . . . . . . . 469
Transacciones simultneas . . . . . . 469
Problemas potenciales con transacciones
simultneas . . . . . . . . . . . 470
Cmo evitar puntos muertos para
transacciones simultneas . . . . . . 471
Consideraciones sobre la programacin de
interfaces XA de X/Open . . . . . . . 472
Enlace de aplicaciones y la interfaz XA de
X/Open . . . . . . . . . . . . . 476
Unidad de trabajo remota
Una unidad de trabajo es una sola transaccin lgica. Consta de una secuencia
de sentencias de SQL en que todas las operaciones se realizan
satisfactoriamente o la secuencia global se considera no satisfactoria.
Una unidad de trabajo remota permite que un usuario o programa de
aplicacin lea o actualice datos que se encuentran en una ubicacin por
unidad de trabajo. Soporta el acceso a una base de datos dentro de una
unidad de trabajo. Mientras que un programa de aplicacin puede acceder a
varias bases de datos remotas, slo puede acceder a una base de datos de una
unidad de trabajo.
Una unidad de trabajo remota tiene las caractersticas siguientes:
v Se soportan varias peticiones por unidad de trabajo.
v Se soportan varios cursores por unidad de trabajo.
v Cada unidad de trabajo slo puede acceder a una base de datos.
v El programa de aplicacin confirma o retrotrae la unidad de trabajo. En
determinadas condiciones de error, el servidor puede retrotraer la unidad
de trabajo.
Consideraciones sobre la actualizacin mltiple
Las secciones siguientes describen las actualizaciones mltiples y cmo
desarrollar aplicaciones que realizan actualizaciones mltiples.
Actualizacin mltiple
Una actualizacin mltiple, tambin conocida como unidad de trabajo
distribuida (DUOW) y como confirmacin en dos fases, es una funcin que
permite que las aplicaciones actualicen datos en varios servidores de bases de
datos remotas con garanta de la integridad. Un buen ejemplo de actualizacin
mltiple es una transaccin bancaria que implica una transferencia monetaria
de una cuenta a otra que se encuentra en otro servidor de base de datos. En
una transaccin de este tipo, es vital que las actualizaciones que implementan
la operacin de cargo en una cuenta no se confirmen a no ser que tambin se
confirmen las actualizaciones necesarias para procesar cargos en la otra
cuenta. Las consideraciones sobre actualizaciones mltiples se aplican cuando
los datos que representan estas cuentas son gestionados por dos servidores de
bases de datos distintos.
Puede utilizar la actualizacin mltiple para leer y actualizar varias bases de
datos DB2 Universal Database en una unidad de trabajo. Si ha instalado DB2
Connect o utiliza la funcin de DB2 Connect que se suministra con DB2
Universal Database Enterprise Edition, tambin puede utilizar la actualizacin
mltiple con servidores de bases de datos iSeries, de sistema principal o
AS/400 como DB2 Universal Database para OS/390 y z/OS y DB2 UDB para
AS/400. Se aplican ciertas restricciones cuando se utiliza DB2 Connect en una
actualizacin mltiple con otros servidores de bases de datos.
Un gestor de transacciones coordina la confirmacin entre varias bases de
datos. Si se utiliza un entorno de supervisor del proceso de transacciones (TP)
tal como TxSeries CICS, el supervisor TP utiliza su propio gestor de
transacciones. De lo contrario, se utiliza el gestor de transacciones
suministrado con DB2. Los sistemas operativos DB2 Universal Database para
UNIX y Windows de 32 bits son gestores de recursos que cumplen con XA
(arquitectura ampliada). Los sistemas principales y los servidores de bases de
datos iSeries a los que se accede con DB2 Connect son gestores de recursos
que se ajustan a XA. Observe tambin que el gestor de transacciones de DB2
Universal Database no es un gestor de transacciones que se ajuste a XA, lo
cual significa que el gestor de transacciones slo puede coordinar bases de
datos DB2.
v X/Open distributed transaction processing model en el manual
Administration Guide: Planning
v Multisite Updates en el manual DB2 Connect Users Guide
Cundo utilizar la actualizacin mltiple
Una actualizacin mltiple es de la mxima utilidad cuando se desea trabajar
con dos o ms bases de datos y mantener la integridad de los datos. Por
ejemplo, si cada sucursal de un banco tiene su propia base de datos, una
aplicacin de transferencia monetaria podra hacer lo siguiente:
1. Conectar con la base de datos del remitente.
2. Leer el saldo de la cuenta del remitente y verificar que tiene suficiente
dinero.
3. Reducir el saldo de la cuenta del remitente en la cantidad transferida.
4. Conectar con la base de datos del receptor.
5. Aumentar el saldo de la cuenta del receptor con la cantidad transferida.
6. Confirmar las bases de datos.
Al realizar la transferencia de fondos dentro de una unidad de trabajo, se
asegurar de que se actualicen ambas bases de datos o no se actualice
ninguna de ellas.
Sentencias de SQL en aplicaciones de actualizacin mltiple
La tabla siguiente le muestra cmo codificar sentencias de SQL para una
actualizacin mltiple. La columna de la izquierda muestra sentencias de SQL
que no utilizan la actualizacin mltiple; la de la derecha, muestra sentencias
parecidas que contienen una actualizacin mltiple.
Tabla 36. Sentencias de RUOW y de SQL con una actualizacin mltiple
Sentencias de RUOW Sentencias de actualizacin mltiple
CONNECT TO D1
SELECT
UPDATE
COMMIT
CONNECT TO D2
INSERT
COMMIT
CONNECT TO D1
SELECT
COMMIT
CONNECT RESET
CONNECT TO D1
SELECT
UPDATE
CONNECT TO D2
INSERT
RELEASE CURRENT
SET CONNECTION D1
SELECT
RELEASE D1
COMMIT
Las sentencias de SQL de la columna de la izquierda slo acceden a una base
de datos por cada unidad de trabajo. sta es una aplicacin de unidad de
trabajo remota (RUOW).
Las sentencias de SQL de la columna de la derecha acceden a ms de una
base de datos en una unidad de trabajo. sta es una aplicacin de
actualizacin mltiple.
Algunas sentencias de SQL se codifican e interpretan de forma distinta en una
aplicacin de actualizacin mltiple:
v No es necesario confirmar ni retrotraer la unidad de trabajo actual antes de
conectar con otra base de datos.
v Cuando se conecta con otra base de datos, no se desconecta la conexin
actual. En cambio, se pone en estado latente. Si la sentencia CONNECT
falla, la conexin actual no se ve afectada.
v No se puede conectar con la clusula USER/USING si ya existe una
conexin actual o latente con la base de datos.
v Puede utilizar la sentencia SET CONNECTION para hacer que una
conexin latente pase a ser la conexin actual.
Se puede lograr el mismo efecto emitiendo una sentencia CONNECT para
la base de datos latente. Este mtodo no est permitido si SQLRULES se
establece en STD. Puede establecer el valor de SQLRULES utilizando una
opcin de precompilador, el mandato SET CLIENT o la API. El valor por
omisin de SQLRULES (DB2) permite conmutar conexiones mediante la
sentencia CONNECT.
v En una seleccin, la posicin del cursor no se ve afectada si se conmuta a
otra base de datos y luego se vuelve a la base de datos original.
v La sentencia CONNECT RESET no desconecta la conexin actual y no
confirma implcitamente la unidad de trabajo actual. En cambio, esta
sentencia es equivalente a una conexin explcita con la base de datos por
omisin (en caso de que se haya definido). Si no se define una conexin
implcita, se devuelve SQLCODE -1024 (SQLSTATE 08003).
v Puede utilizar la sentencia RELEASE para marcar una conexin de forma
que se desconecte en la prxima COMMIT. La sentencia RELEASE
CURRENT se aplica a la conexin actual, la sentencia RELEASE conexin se
aplica a la conexin mencionada y la sentencia RELEASE ALL se aplica a
todas las conexiones.
Una conexin que est marcada para ser liberada se puede seguir
utilizando hasta que se desactive en la prxima sentencia COMMIT. Una
retrotraccin no desactiva la conexin; este comportamiento permite
efectuar un reintento con las conexiones establecidas. Utilice la sentencia
DISCONNECT (o una opcin de precompilador) para desactivar las
conexiones despus de una confirmacin o retrotraccin.
v La sentencia COMMIT confirma todas las bases de datos de la unidad de
trabajo (actual o latente).
v La sentencia ROLLBACK retrotrae todas las bases de datos de la unidad de
trabajo y cierra los cursores retenidos para todas las bases de datos, tanto si
se accede a ellos en la unidad de trabajo como si no es as.
v Todas las conexiones (incluidas las latentes y las marcadas para su
liberacin) se desconectan cuando termina el proceso de la aplicacin.
v Despus de cualquier conexin satisfactoria (incluyendo una sentencia
CONNECT sin opciones, que slo consulta la conexin actual) se devolver
un nmero en los campos SQLERRD(3) y SQLERRD(4) de la SQLCA.
El campo SQLERRD(3) devuelve informacin sobre si la base de datos con
la que se ha conectado se puede actualizar actualmente en una unidad de
trabajo. Los valores posibles de este campo son:
1 Se puede actualizar.
2 Slo es de lectura.
El campo SQLERRD(4) devuelve la informacin siguiente sobre las
caractersticas actuales de la conexin:
0 No es aplicable. Este estado slo es posible si se ejecuta desde un
cliente de nivel inferior que utiliza la confirmacin de una fase y es
un actualizador.
1 Confirmacin de una fase.
2 Confirmacin de una fase (slo lectura). Este estado slo se aplica a
servidores de bases de datos de sistema principal, AS/400 o iSeries
a los que accede con DB2 Connect sin iniciar el gestor de puntos de
sincronismo de DB2 Connect.
3 Confirmacin de dos fases.
Si est escribiendo herramientas o programas de utilidad, es posible que
desee emitir un mensaje a los usuarios en caso de que la conexin slo sea
de lectura.
Precompilacin de aplicaciones de actualizacin mltiple
Cuando precompile una aplicacin de actualizacin mltiple, debe establecer
la conexin del CLP en una conexin de tipo 1; de lo contrario, recibir un
SQLCODE 30090 (SQLSTATE 25000) cuando intente precompilar la aplicacin.
Cuando se precompila una aplicacin que utiliza actualizaciones mltiples, se
utilizan las opciones de precompilador siguientes:
CONNECT (1 | 2)
Especifique CONNECT 2 para indicar que esta aplicacin utiliza la
sintaxis de SQL para las aplicaciones de actualizacin mltiple. El
valor por omisin, CONNECT 1, significa que se aplican a la
aplicacin las reglas normales (RUOW) para la sintaxis de SQL.
SYNCPOINT (ONEPHASE | TWOPHASE | NONE)
Si especifica SYNCPOINT TWOPHASE y DB2 coordina la transaccin,
DB2 necesita una base de datos para mantener la informacin de
estado de la transaccin. Cuando despliegue la aplicacin, debe
definir esta base de datos configurando el parmetro de configuracin
del gestor de bases de datos tm_database.
SQLRULES (DB2 | STD)
Especifica si en las aplicaciones de actualizacin mltiple se deben
utilizar las reglas de DB2 o las reglas estndar (STD) basadas en
ISO/ANSI SQL92. Las reglas de DB2 permiten emitir una sentencia
CONNECT para una base de datos latente; las reglas STD no lo
permiten.
DISCONNECT (EXPLICIT | CONDITIONAL | AUTOMATIC)
Especifica qu conexiones de base de datos se deben desconectar
cuando se ejecute COMMIT: slo las bases de datos que estn
marcadas para su liberacin con una sentencia RELEASE (EXPLICIT),
todas las bases de datos que no tienen cursores WITH HOLD abiertos
(CONDITIONAL) o todas las conexiones (AUTOMATIC).
Las opciones de precompilador de la actualizacin mltiple entran en vigor
cuando se realiza la primera conexin con una base de datos. Puede utilizar la
API SET CLIENT para sustituir los valores de conexin cuando no exista
ninguna conexin (antes de que se establezca alguna conexin o despus de
que se desconecten todas ellas). Puede utilizar la API QUERY CLIENT para
consular los valores de conexin actuales del proceso de la aplicacin.
Si un objeto al que se hace referencia en el programa de aplicacin no existe,
el enlazador falla. Existen tres maneras posibles de tratar las aplicaciones de
actualizacin mltiple:
v Puede dividir la aplicacin en varios archivos, cada uno de los cuales
acceder a una sola base de datos. Luego prepare y enlace lgicamente cada
archivo a la nica base de datos a que accede.
v Puede asegurarse de que exista cada tabla en cada base de datos. Por
ejemplo, en las sucursales de un banco pueden haber bases de datos cuyas
tablas sean idnticas (a excepcin de los datos).
v Puede utilizar nicamente SQL dinmico.
v Sentencias de SQL en aplicaciones de actualizacin mltiple en la pgina
463
v sqlesetc - Set Client en el manual Administrative API Reference
v sqleqryi - Query Client Information en el manual Administrative API
Reference
Consideraciones sobre parmetros de configuracin correspondientes a
aplicaciones de actualizacin mltiple
Los parmetros de configuracin siguientes afectan a las aplicaciones que
realizan actualizaciones mltiples. A excepcin de locktimeout, los parmetros
de configuracin son parmetros de configuracin del gestor de bases de
datos. locktimeout es un parmetro de configuracin de la base de datos.
tm_database
Especifica qu base de datos va a actuar como gestor de transacciones
para las confirmaciones de dos fases.
resync_interval
Especifica el nmero de segundos que el sistema esperar entre
intentos para tratar de resincronizar una transaccin dudosa. (Una
transaccin dudosa es una transaccin que completa
satisfactoriamente la primera fase de una confirmacin en dos fases
pero falla durante la segunda fase.)
locktimeout
Especifica el nmero de segundos antes de que se exceda el tiempo de
espera de un bloqueo y se retrotraiga la transaccin actual para una
base de datos determinada. La aplicacin debe emitir una sentencia
ROLLBACK explcita para retrotraer todas las bases de datos que
participan en la actualizacin mltiple. locktimeout es un parmetro de
configuracin de la base de datos.
tp_mon_name
Especifica el nombre del supervisor TP, si lo hay.
spm_resync_agent_limit
Especifica el nmero de agentes simultneos que pueden realizar
operaciones de resincronizacin con el servidor de sistema principal,
AS/400 o iSeries utilizando SNA.
spm_name
v Si se utiliza el gestor de puntos de sincronismo con una conexin
TCP/IP de confirmacin en dos fases, spm_name debe ser un
identificador exclusivo dentro de la red. Cuando se crea una
instancia de DB2, DB2 deduce el valor por omisin de spm_name a
partir del nombre de sistema principal TCP/IP. El usuario puede
modificar este valor si no resulta aceptable en su entorno. Para la
conectividad de TCP/IP con los servidores de bases de datos de
sistema principal, el valor por omisin debe resultar aceptable. Para
las conexiones SNA con servidores de bases de datos de sistema
principal, AS/400 o iSeries, este valor debe coincidir con un perfil
de LU SNA definido en el producto SNA.
v Si se utiliza el gestor de puntos de sincronismo con una conexin
SNA de confirmacin en dos fases, el nombre del gestor de puntos
de sincronismo debe tener el valor LU_NAME que se utiliza para la
confirmacin en dos fases.
v Si se utiliza el gestor de puntos de sincronismo tanto para TCP/IP
como para SNA, se debe utilizar el valor de LU_NAME que se
utiliza para la confirmacin en dos fases.
Nota: las actualizaciones mltiples en un entorno con servidores de
bases de datos de sistema principal, AS/400 o iSeries pueden
necesitar el gestor de puntos de sincronismo.
spm_log_size
El nmero de pginas de 4 kilobytes de cada archivo de registro
primario y secundario utilizado por el gestor de puntos de
sincronismo para registrar informacin sobre las conexiones, el estado
de las conexiones actuales, etc.
Hay otras consideraciones que deben tenerse en cuenta si la aplicacin realiza
actualizaciones mltiples que coordina un gestor de transacciones XA con
conexiones a una base de datos de sistema principal, AS/400 o iSeries.
v Multisite Updates en el manual DB2 Connect Users Guide
v Multisite update and sync point manager en el manual DB2 Connect
Users Guide
v Enabling Multisite Updates using the Control Center en el manual DB2
Connect Users Guide
v Sync Point Manager Log File Path configuration parameter -
spm_log_path en el manual Administration Guide: Performance
v Transaction Resync Interval configuration parameter - resync_interval en
el manual Administration Guide: Performance
v Transaction Manager Database Name configuration parameter -
tm_database en el manual Administration Guide: Performance
v Transaction Processor Monitor Name configuration parameter -
tp_mon_name en el manual Administration Guide: Performance
v Lock Timeout configuration parameter - locktimeout en el manual
v Sync Point Manager Name configuration parameter - spm_name en el
manual Administration Guide: Performance
v Sync Point Manager Log File Size configuration parameter -
spm_log_file_sz en el manual Administration Guide: Performance
v Sync Point Manager Resync Agent Limit configuration parameter -
spm_max_resync en el manual Administration Guide: Performance
Acceso a servidores de sistema principal, AS/400 o iSeries
Procedimiento:
Si desea crear aplicaciones que accedan a sistemas de bases de datos
diferentes (o los actualicen), debe:
1. Utilizar sentencias de SQL y opciones de precompilacin/vinculacin que
se soporten en todos los sistemas de bases de datos a los que vayan a
acceder las aplicaciones. Por ejemplo, los procedimientos almacenados no
se soportan en todas las plataformas.
Para productos IBM, consulte la documentacin de SQL antes de empezar
a codificar.
2. Si es posible, hacer que las aplicaciones comprueben SQLSTATE en lugar
de SQLCODE.
Si las aplicaciones van a utilizar DB2 Connect y desea utilizar los
SQLCODE, considere la posibilidad de utilizar el recurso de correlacin
que brinda DB2 Connect para correlacionar las conversiones de SQLCODE
entre bases de datos distintas.
3. Pruebe la aplicacin con las bases de datos de sistema principal, AS/400 o
iSeries (tales como DB2 Universal Database para OS/390 y z/OS, OS/400
o DB2 para VSE y VM) que pretenda soportar.
v Aplicaciones en entornos de sistema principal o iSeries en la pgina 527
Transacciones simultneas
Las secciones siguientes describen las transacciones simultneas y cmo evitar
problemas con las mismas.
Transacciones simultneas
Algunas veces, resulta de utilidad para una aplicacin tener varias conexiones
independientes denominadas transacciones simultneas. Mediante la utilizacin
de transacciones simultneas, una aplicacin puede conectar con varias bases
de datos al mismo tiempo, y puede establecer varias conexiones distintas con
la misma base de datos.
Las API de contexto que se utilizan para el acceso a bases de datos de varias
hebras permiten que una aplicacin utilice transacciones simultneas. Cada
contexto creado en una aplicacin es independiente de los otros contextos.
Esto significa que se crea un contexto, se conecta con una base de datos
utilizando el contexto y se ejecutan sentencias de SQL para la base de datos
sin que se vean afectadas por actividades de otros contextos, tales como la
ejecucin de sentencias COMMIT o ROLLBACK.
Por ejemplo, suponga que est creando una aplicacin que permite que un
usuario ejecute sentencias de SQL para una base de datos, y que mantiene un
registro de las actividades realizadas en una segunda base de datos. Puesto
que el registro se debe mantener actualizado, es necesario emitir una sentencia
COMMIT despus de cada actualizacin del mismo, pero no se desea que las
sentencias de SQL del usuario se vean afectadas por las confirmaciones del
registro. sta es una situacin perfecta para las transacciones simultneas. En
la aplicacin, cree dos contextos: uno conectar con la base de datos del
usuario y se utilizar para todo el SQL del usuario; el otro conectar con la
base de datos del registro y se utilizar para actualizar el registro. Mediante
este diseo, cuando confirme un cambio efectuado en la base de datos del
registro, no afectar a la unidad de trabajo actual del usuario.
Otro beneficio de las transacciones simultneas es que, si se retrotrae el
trabajo sobre los cursores de una conexin, esto no tiene ningn efecto sobre
los cursores de otras conexiones. Despus de la retrotraccin de la primera
conexin, en las otras conexiones se mantienen tanto el trabajo realizado como
las posiciones de los cursores.
v Objetivo del acceso a base de datos de varias hebras en la pgina 227
Problemas potenciales con transacciones simultneas
Una aplicacin que utiliza transacciones simultneas se puede encontrar con
algunos problemas que no pueden surgir cuando se escribe una aplicacin
que utiliza una sola conexin. Cuando escriba una aplicacin con
transacciones simultneas, tenga cuidado con los aspectos siguientes:
v Dependencias de base de datos entre dos o ms contextos.
Cada contexto de una aplicacin tiene sus propios recursos de base de
datos, incluidos los bloqueos sobre objetos de base de datos. Estos
conjuntos distintos de recursos posibilitan que dos contextos, si estn
accediendo al mismo objeto de base de datos, lleguen a un punto muerto.
El gestor de bases de datos detectar el punto muerto, uno de los contextos
recibir SQLCODE -911 y se retrotraer la unidad de trabajo del mismo.
v Dependencias de aplicaciones entre dos o ms contextos.
La conmutacin de contextos dentro de una sola hebra crea dependencias
entre los contextos. Si los contextos tambin tienen dependencias de base de
datos, es posible que se produzca un punto muerto. Puesto que algunas de
las dependencias se producen fuera del gestor de bases de datos, no se
detectar el punto muerto y se suspender la aplicacin.
Como ejemplo de este tipo de problema, piense en la aplicacin siguiente:
contexto 1
UPDATE TAB1 SET COL = :new_val
contexto 2
SELECT * FROM TAB1
COMMIT
contexto 1
COMMIT
Suponga que el primer contexto ejecuta satisfactoriamente la sentencia
UPDATE. La actualizacin establece bloqueos sobre todas las filas de TAB1.
Ahora, el contexto 2 intenta seleccionar todas las filas de TAB1. Puesto que
los dos contextos son independientes, el contexto 2 espera a causa de los
bloqueos mantenidos por el contexto 1. Sin embargo, el contexto 1 no
puede liberar sus bloqueos hasta que termina la ejecucin del contexto 2. La
aplicacin est ahora en un punto muerto, pero el gestor de bases de datos
no sabe que el contexto est esperando al contexto 2, por lo que no
impondr que se retrotraiga uno de los contextos. La dependencia no
resuelta deja la aplicacin suspendida.
v Cmo evitar puntos muertos para transacciones simultneas en la pgina
471
Cmo evitar puntos muertos para transacciones simultneas
Puesto que el gestor de bases de datos no puede detectar puntos muertos
entre contextos, debe disear y codificar la aplicacin de forma que impida (o,
como mnimo, permita que se eviten) los puntos muertos. Supongamos que
tenemos el siguiente ejemplo, que puede dar lugar a una situacin de punto
muerto:
contexto 1
UPDATE TAB1 SET COL = :new_val
contexto 2
SELECT * FROM TAB1
COMMIT
contexto 1
COMMIT
Suponga que el primer contexto ejecuta satisfactoriamente la sentencia
UPDATE. La actualizacin establece bloqueos sobre todas las filas de TAB1.
Ahora, el contexto 2 intenta seleccionar todas las filas de TAB1. Puesto que los
dos contextos son independientes, el contexto 2 espera a causa de los
bloqueos mantenidos por el contexto 1. Sin embargo, el contexto 1 no puede
liberar sus bloqueos hasta que termina la ejecucin del contexto 2. La
aplicacin est ahora en un punto muerto, pero el gestor de bases de datos no
sabe que el contexto est esperando al contexto 2, por lo que no impondr
que se retrotraiga uno de los contextos. La dependencia no resuelta deja la
aplicacin suspendida.
Puede evitar el punto muerto del ejemplo de varias formas:
v Libere todos los bloqueos mantenidos antes de conmutar contextos.
Cambie el cdigo de forma que el contexto 1 realice su confirmacin antes
de conmutar al contexto 2.
v No acceda a un objeto determinado desde ms de un contexto a la vez.
Cambie el cdigo de forma que tanto la actualizacin como la seleccin se
realicen desde el mismo contexto.
v Establezca el parmetro de configuracin de la base de datos locktimeout en
un valor distinto de -1.
Aunque un valor distinto de -1 no impedir el punto muerto, permitir que
se reanude la ejecucin. Eventualmente, se retrotraer el contexto 2, puesto
que no puede obtener el bloqueo solicitado. Cuando se retrotraiga el
contexto 2, el contexto 1 podr continuar la ejecucin (con lo cual liberar
los bloqueos) y el contexto 2 podr reintentar su trabajo.
Aunque las tcnicas para evitar puntos muertos se describen en trminos del
ejemplo, las puede aplicar a todas las aplicaciones que utilizan transacciones
simultneas.
v Problemas potenciales con transacciones simultneas en la pgina 470
v Lock Timeout configuration parameter - locktimeout en el manual
Consideraciones sobre la programacin de interfaces XA de X/Open
La Interfaz XA de es un estndar abierto para coordinar cambios en varios
recursos, mientras que se asegura la integridad de dichos cambios.
Normalmente, los productos de software conocidos como supervisores del
proceso de transacciones utilizan la interfaz XA y, puesto que DB2 soporta esta
interfaz, se puede acceder simultneamente a una o ms bases de datos DB2
como recursos en un entorno de este tipo.
DB2 requiere una consideracin especial cuando funciona en un entorno de
proceso de transacciones distribuidas (DTP) que utiliza la interfaz XA, puesto
que se utiliza un modelo distinto para el proceso de transacciones, en
comparacin con las aplicaciones que se ejecutan de forma independiente de
un supervisor TP. Las caractersticas de este modelo de proceso de
transacciones son:
v Dentro de una transaccin se pueden modificar varios tipos de recursos
recuperables (como, por ejemplo, bases de datos DB2).
v Los recursos se actualizan utilizando una confirmacin en dos fases para
cerciorarse de la integridad de las transacciones que se ejecutan.
v Los programas de aplicacin envan peticiones para confirmar o retrotraer
una transaccin al producto supervisor TP, en lugar de hacerlo a los
gestores de los recursos. Por ejemplo, en un entorno CICS, una aplicacin
emitir EXEC CICS SYNCPOINT para confirmar una transaccin, y una emisin
de EXEC SQL COMMIT a DB2 no sera vlida y resultara innecesaria.
v El supervisor TP filtra la autorizacin para ejecutar transacciones y el
software relacionado, por lo que los gestores de recursos tales como DB2
tratan el supervisor TP como nico usuario autorizado. Por ejemplo,
cualquier uso de una transaccin CICS debe ser autentificado por CICS, y
se debe otorgar a CICS el privilegio de acceso a la base de datos, en lugar
de al usuario final que invoca a la aplicacin CICS.
v Normalmente, muchos programas (transacciones) se ponen en cola y se
ejecutan en un servidor de base de datos (que aparece ante DB2 como un
solo programa de aplicacin de ejecucin prolongada).
Debido a la naturaleza exclusiva de este entorno, DB2 tiene un
comportamiento y unos requisitos especiales para las aplicaciones codificadas
para que se ejecuten en l:
v Dentro de una unidad de trabajo se puede conectar con varias bases de
datos, y actualizarlas, sin tener en cuenta las opciones de precompilador o
los valores del cliente de la unidad de trabajo distribuida.
v La sentencia DISCONNECT no est permitida y, de intentarla, se rechazar
con SQLCODE -30090 (SQLSTATE 25000).
v La sentencia RELEASE no recibe soporte y se rechazar con -30090.
v Las sentencias COMMIT y ROLLBACK no estn permitidas dentro de los
procedimientos almacenados a los que accede una transaccin de
supervisor TP.
v Cuando se inhabilitan explcitamente los flujos de confirmacin en dos fases
para una transaccin (que se denomina transaccin LOCAL en la
terminologa de la Interfaz XA), dentro de esta transaccin slo se puede
acceder a una base de datos. Esta base de datos no puede ser una base de
datos de sistema principal, AS/400 ni iSeries a la que se acceda utilizando
la conectividad SNA. Se soportan transacciones locales para DB2 para
OS/390 Versin 5 que utilizan la conectividad TCP/IP.
v Las transacciones LOCALES deben emitir SQL COMMIT o SQL
ROLLBACK al final de cada transaccin; de lo contrario, se considerar que
la transaccin forma parte de la prxima transaccin que se procese.
v La conmutacin entre conexiones de base de datos simultneas se realiza
mediante el uso de SQL CONNECT o de SQL SET CONNECTION. La
autorizacin utilizada para una conexin no se puede cambiar especificando
un ID de usuario o una contrasea en la sentencia CONNECT.
v Si un objeto de base de datos, tal como una tabla, una vista o un ndice, no
se califica completamente en una sentencia de SQL dinmico, se calificar
implcitamente con el ID de autentificacin simple bajo el que se ejecute el
supervisor TP, en lugar de hacerlo con el ID del usuario.
v Cualquier uso de las sentencias COMMIT o ROLLBACK de DB2 para
transacciones que no sean LOCALES ser rechazado. Se devolvern los
cdigos siguientes:
SQLCODE -925 (SQLSTATE 2D521) para una COMMIT esttica
SQLCODE -926 (SQLSTATE 2D521) para una ROLLBACK esttica
SQLCODE -426 (SQLSTATE 2D528) para una COMMIT dinmica
SQLCODE -427 (SQLSTATE 2D529) para una ROLLBACK dinmica
v Las peticiones de COMMIT o ROLLBACK por parte de la CLI tambin son
rechazadas.
v Manejo de retrotracciones iniciadas por una base de datos:
En un entorno DTP, si un RM ha iniciado una retrotraccin (por ejemplo,
debido a un error del sistema o a una situacin de punto muerto) para
terminar su propia ramificacin de una transaccin global, no debe procesar
ninguna otra peticin del mismo proceso de aplicacin hasta que se
produzca una peticin de punto de sincronismo iniciada por el gestor de
transacciones. Esto incluye los puntos muertos que se producen dentro de
un procedimiento almacenado. Para el gestor de bases de datos, esto
significa que se rechacen todas las peticiones de SQL posteriores con
SQLCODE -918 (SQLSTATE 51021), para informar al usuario de que debe
retrotraer la transaccin global con el servicio de puntos de sincronismo del
gestor de transacciones, por ejemplo utilizando el mandato CICS
SYNCPOINT ROLLBACK en un entorno CICS. En cambio si, por algn
motivo, se solicita al TM que confirme la transaccin, el RM informar al
TM sobre la retrotraccin y har que el TM retrotraiga de todas formas los
otros RM.
v Cursores declarados WITH HOLD:
Los cursores declarados WITH HOLD se soportan en entornos XA/DTP
para supervisores del proceso de transacciones CICS.
En los casos en que no se soporten cursores declarados WITH HOLD, una
sentencia OPEN ser rechazada con SQLCODE -30090 (SQLSTATE 25000),
cdigo de razn 03.
Es responsabilidad de las transacciones asegurarse de que los cursores
especificados como WITH HOLD se cierren explcitamente cuando ya no
sean necesarios; de lo contrario, es posible que otras transacciones los
hereden, lo cual ocasionar conflictos o un uso innecesario de recursos.
Si el supervisor TP da soporte a cursores HOLD, xa_commit, xa_rollback y
xa_prepare se deben emitir en la misma conexin que la transaccin global.
v Las sentencias que actualizan o cambian una base de datos no estn
permitidas para las bases de datos que no soportan flujos de peticiones de
confirmacin en dos fases. Por ejemplo, el acceso a servidores de bases de
datos de sistema principal, AS/400 o iSeries en entornos en los que el nivel
2 del protocolo DRDA (DRDA2) no recibe soporte.
v Durante la ejecucin, se puede determinar si una base de datos soporta
actualizaciones en un entorno XA emitiendo una sentencia CONNECT. El
tercer smbolo SQLERRD tendr el valor 1 si la base de datos se puede
actualizar; de lo contrario, tendr el valor 2.
v Si estn restringidas las actualizaciones, slo se permitirn las sentencias de
SQL siguientes:
CONNECT
DECLARE
DESCRIBE
EXECUTE IMMEDIATE (en que el primer smbolo o palabra clave es SET pero
no SET CONSTRAINTS)
OPEN CURSOR
FETCH CURSOR
CLOSE CURSOR
PREPARE (en que el primer smbolo o palabra clave no es un blanco ni
un parntesis izquierdo es SET (que no sea SET CONSTRAINTS,
SELECT, WITH ni VALUES)
SELECT...INTO
VALUES...INTO
Cualquier otro intento ser rechazado con SQLCODE -30090 (SQLSTATE
25000).
La sentencia PREPARE slo se podr utilizar para preparar sentencias
SELECT. La sentencia EXECUTE IMMEDIATE tambin est permitida para
ejecutar sentencias SET de SQL que no devuelvan ningn valor de salida,
como por ejemplo la sentencia SET SQLID de DB2 Universal Database para
OS/390 y z/OS.
v Restricciones de las API:
Las API que emiten internamente una confirmacin en la base de datos y
eluden el proceso de confirmacin en dos fases sern rechazadas con
SQLCODE -30090 (SQLSTATE 25000). Para ver una lista de estas API,
consulte el apartado sobre restricciones en aplicaciones de actualizacin
mltiple. Estas API no se soportan en una actualizacin mltiple (Connect
Tipo 2).
v DB2 da soporte a un entorno XA/DTP de varias hebras.
Observe que las restricciones anteriores se aplican a las aplicaciones que se
ejecutan en un entorno de supervisor TP que utiliza la interfaz XA. Si las
bases de datos DB2 no estn definidas para que se utilicen con la interfaz XA,
no se aplican estas restricciones; no obstante, sigue siendo necesario
asegurarse de que las transacciones se codifiquen de manera que no dejen
DB2 en un estado que afecte adversamente a la prxima transaccin que se
vaya a ejecutar.
v Security considerations for XA transaction managers en el manual
v Configuration considerations for XA transaction managers en el manual
v XA function supported by DB2 UDB en el manual Administration Guide:
Planning
v Actualizacin mltiple con DB2 Connect en la pgina 539
v Updating host or iSeries database servers with an XA-compliant
transaction manager en el manual Administration Guide: Planning
Enlace de aplicaciones y la interfaz XA de X/Open
Para producir una aplicacin ejecutable, es necesario que enlace los objetos de
la aplicacin con las bibliotecas de lenguajes, las bibliotecas del sistema
operativo, las bibliotecas normales del gestor de bases de datos y las
bibliotecas del supervisor TP y de los productos gestores de transacciones.
Captulo 17. Consideraciones sobre programacin para
entornos de bases de datos particionadas
Cursores FOR READ ONLY en un entorno
de bases de datos particionadas . . . . . 477
DDS dirigida y elusin local . . . . . . 477
DDS dirigida y elusin local en entornos
de bases de datos particionadas . . . . 477
DDS dirigida en entornos de bases de
Elusin local en entornos de bases de
Inserciones colocadas en almacenamiento
intermedio . . . . . . . . . . . . 479
Inserciones en almacenamiento
intermedio en entornos de bases de datos
particionadas . . . . . . . . . . 480
Consideraciones sobre la utilizacin de
intermedio . . . . . . . . . . . 483
Restricciones en la utilizacin de
intermedio . . . . . . . . . . . 486
Ejemplo de extraccin un gran volumen de
datos en una base de datos particionada . . 487
Creacin de un entorno simulado de bases
de datos particionadas . . . . . . . . 493
Resolucin de problemas . . . . . . . 493
Consideraciones sobre el manejo de
errores en entornos de bases de datos
particionadas . . . . . . . . . . 493
Errores graves en entornos de bases de
Varias estructuras SQLCA fusionadas . . 495
Particin que devuelve el error . . . . 496
Aplicaciones en bucle o suspendidas . . 496
Cursores FOR READ ONLY en un entorno de bases de datos particionadas
Si declara un cursor desde el cual slo pretende leer, incluya FOR READ
ONLY o FOR FETCH ONLY en la declaracin del OPEN CURSOR. (FOR
READ ONLY y FOR FETCH ONLY son sentencias equivalentes.) Los cursores
FOR READ ONLY permiten que la particin coordinadora recupere varias
filas a la vez, mejorando en gran medida el rendimiento de las sentencias
FETCH posteriores. Cuando los cursores no se declaran explcitamente como
FOR READ ONLY, la particin coordinadora los trata como cursores
actualizables. Los cursores actualizables incurren en un gasto considerable,
puesto que requieren que la particin coordinadora slo recupere una nica
fila por cada FETCH.
DDS dirigida y elusin local
utilizar DDS dirigida y elusin local en entornos de bases de datos
particionadas.
DDS dirigida y elusin local en entornos de bases de datos particionadas
Para optimizar las aplicaciones de proceso de transacciones en lnea (OLTP),
es posible que desee evitar las sentencias simples de SQL que requieran un
proceso en todas las particiones de bases de datos. Debe disear la aplicacin
de forma que las sentencias de SQL puedan recuperar datos de particiones de
bases de datos nicas. Las tcnicas de subseccin distribuida dirigida (DSS) y
de elusin local evitan el gasto en que incurre la particin coordinadora al
comunicar con una o con todas las particiones asociadas.
v DDS dirigida en entornos de bases de datos particionadas en la pgina
478
v Elusin local en entornos de bases de datos particionadas en la pgina
479
DDS dirigida en entornos de bases de datos particionadas
Una subseccin distribuida (DSS) es la accin de enviar subsecciones a la
particin de base de datos que necesita realizar trabajo para una consulta
paralela. Tambin describe la iniciacin de subsecciones mediante la
invocacin de valores especficos, como por ejemplo valores de variables en
un entorno OLTP. Una DDS dirigida utiliza la clave de particionamiento de
tabla para dirigir una consulta a una sola particin. Utilice este tipo de
consulta en la aplicacin para evitar la actividad general de la particin
coordinadora necesaria para difundir una consulta a todas las particiones.
A continuacin mostramos un fragmento de una sentencia SELECT de
ejemplo que se puede aprovechar de las DSS dirigidas:
SELECT ... FROM t1
WHERE PARTKEY=:hostvar
Cuando la particin coordinadora recibe la consulta, determina qu particin
de base de datos contiene el subconjunto de datos para :hostvar y dirige la
consulta, especficamente, a dicha particin de base de datos.
Para optimizar la aplicacin utilizando DSS dirigidas, divida las consultas
complejas en varias consultas simples. Por ejemplo, en la consulta siguiente la
particin coordinadora compara la clave de particionamiento con varios
valores. Dado que los datos que se ajustan a la consulta residen en varias
particiones de base de datos, la particin coordinadora difunde la consulta a
todas las particiones de base de datos:
SELECT ... FROM t1
WHERE PARTKEY IN (:hostvar1, :hostvar2)
En lugar de esto, divida la consulta en varias sentencias SELECT (cada una de
ellas con una sola variable del lenguaje principal) o utilice una nica sentencia
SELECT con UNION para lograr el mismo resultado. La particin
coordinadora se puede aprovechar de sentencias SELECT ms sencillas para
utilizar DSS dirigidas a fin de comunicar nicamente con las particiones de
base de datos necesarias. La consulta optimizada tiene el aspecto siguiente:
SELECT ... AS res1 FROM t1
WHERE PARTKEY=:hostvar1
UNION
SELECT ... AS res2 FROM t1
WHERE PARTKEY=:hostvar2
Observe que la tcnica anterior slo mejorar el rendimiento si el nmero de
selecciones de UNION es significativamente menor que el nmero de
particiones.
Elusin local en entornos de bases de datos particionadas
Una forma especializada de la consulta DSS dirigida accede a los datos
almacenados nicamente en la particin coordinadora. Esto se denomina
elusin local porque la particin coordinadora completa la consulta sin tener
que comunicar con otra particin.
Si es posible, la elusin local se habilita automticamente, pero el usuario
puede incrementar su uso dirigiendo transacciones a la particin de base de
datos que contiene los datos correspondientes a dicha transaccin. Una tcnica
para hacerlo consiste en hacer que un cliente remoto mantenga conexiones
con cada una de las particiones de bases de datos. Luego una transaccin
puede utilizar la conexin correcta segn la clave de particionamiento de
entrada. Otra tcnica consiste en agrupar las transacciones por particiones de
bases de datos y disponer de un servidor de aplicaciones separado para cada
particin de base de datos.
Para determinar el nmero de la particin de base de datos en la que residen
los datos de la transaccin, puede utilizar la API sqlugrpn (Obtener nmero
de particionamiento de filas). Esta API permite que una aplicacin calcule con
eficacia el nmero de particin de una fila, dada la clave de particionamiento.
Otra alternativa consiste en utilizar el programa de utilidad db2atld para
dividir los datos de entrada por nmero de particin y ejecutar una copia de
la aplicacin en cada particin de base de datos.
v sqlugrpn - Get Row Partitioning Number en el manual Administrative API
Reference
v db2atld - Mandato Cargador automtico en el manual Consulta de
mandatos
Inserciones colocadas en almacenamiento intermedio
utilizar inserciones colocadas en almacenamiento intermedio en entornos de
bases de datos particionadas.
Captulo 17. Consideraciones sobre programacin para entornos de bases de datos particionadas 479
Inserciones en almacenamiento intermedio en entornos de bases de
datos particionadas
Una insercin en almacenamiento intermedio es una sentencia de insercin
que se aprovecha de las colas de tablas para poner en el almacenamiento
intermedio las filas que se insertan, obteniendo as una mejora significativa en
el rendimiento. Para utilizar una insercin en almacenamiento intermedio, una
aplicacin se debe preparar o enlazar lgicamente con la opcin INSERT BUF.
Las inserciones en almacenamiento intermedio pueden tener como
consecuencia una mejora sustancial en el rendimiento de las aplicaciones que
realizan inserciones. Normalmente, se puede utilizar una insercin en
almacenamiento intermedio en las aplicaciones en que se utiliza una sola
sentencia de insercin (y ninguna otra sentencia de modificacin de bases de
datos) dentro de un bucle para insertar muchas filas, y si el origen de los
datos es una clusula VALUES de la sentencia INSERT. Habitualmente, la
sentencia INSERT hace referencia a una o ms variables del lenguaje principal
que cambian de valor durante las sucesivas ejecuciones del bucle. La clusula
VALUES puede especificar una sola fila o varias filas.
Las aplicaciones tpicas de soporte de decisiones requieren una carga e
insercin peridica de datos nuevos. Estos datos pueden representar cientos
de miles de filas. Puede preparar y enlazar lgicamente las aplicaciones de
forma que utilicen inserciones en almacenamiento intermedio cuando carguen
tablas.
Para hacer que una aplicacin utilice inserciones en almacenamiento
intermedio, use el mandato PREP para procesar el archivo fuente del
programa de aplicacin, o utilice el mandato BIND en el archivo de
vinculacin resultante. En ambas situaciones, se debe especificar la opcin
INSERT BUF.
Nota: las inserciones en almacenamiento intermedio ocasionan que se lleven a
cabo los pasos siguientes:
1. El gestor de bases de datos abre un almacenamiento intermedio de
4 KB para cada particin de base de datos en que reside la tabla.
2. La sentencia INSERT con la clusula VALUES emitida por la
aplicacin hace que la o las fila(s) se coloque(n) en el o los
almacenamiento(s) intermedio(s) apropiado(s).
3. El gestor de bases de datos devuelve el control a la aplicacin.
4. Las filas del almacenamiento intermedio se envan a la particin
cuando se llena el almacenamiento intermedio, o cuando se produce
un suceso que hace que se enven las filas de un almacenamiento
intermedio parcialmente lleno. Un almacenamiento parcialmente
lleno se vaca cuando se da una de las situaciones siguientes:
v La aplicacin emite una sentencia COMMIT (implcita o
explcitamente a travs de la terminacin de la aplicacin) o
ROLLBACK.
v La aplicacin emite otra sentencia que hace que se tome un punto
de rescate. Las sentencias de cursor OPEN, FETCH y CLOSE no
ocasionan que se tome un punto de rescate ni cierran una
insercin en almacenamiento intermedio abierta.
Las sentencias de SQL siguientes cerrarn una insercin en
almacenamiento intermedio abierta:
BEGIN COMPOUND SQL
COMMIT
DDL
DELETE
END COMPOUND SQL
EXECUTE IMMEDIATE
GRANT
INSERT en otra tabla
PREPARE de la misma sentencia dinmica (por nombres)
realizando inserciones en almacenamiento intermedio
REDISTRIBUTE DATABASE PARTITION GROUP
RELEASE SAVEPOINT
REORG
REVOKE
ROLLBACK
ROLLBACK TO SAVEPOINT
RUNSTATS
SAVEPOINT
SELECT INTO
UPDATE
Ejecucin de cualquier otra sentencia, pero no otra ejecucin
(bucle) de la INSERT en almacenamiento intermedio
Fin de la aplicacin
Las API siguientes cerrarn una insercin en almacenamiento
intermedio abierta:
BIND (API)
REBIND (API)
RUNSTATS (API)
REORG (API)
REDISTRIBUTE (API)
En cualquiera de estas situaciones en que otra sentencia cierra la
insercin en almacenamiento intermedio, la particin coordinadora
espera hasta que todas las particiones de bases de datos reciben los
almacenamientos intermedios y se insertan las filas. A continuacin,
ejecuta la otra sentencia (aqulla que cierra la insercin en
almacenamiento intermedio), siempre que todas las filas se hayan
insertado satisfactoriamente.
La interfaz estndar en un entorno particionado (sin insercin en
almacenamiento intermedio) carga una fila cada vez, llevando a cabo los
pasos siguientes (suponiendo que la aplicacin se ejecuta localmente en una
de las particiones de bases de datos):
1. La particin coordinadora pasa la fila al gestor de bases de datos que se
encuentra en la misma particin.
2. El gestor de bases de datos utiliza un procedimiento de hash indirecto
para determinar la particin de base de datos en que se debe colocar la
fila:
v La particin de destino recibe la fila.
v La particin de destino inserta la fila localmente.
v La particin de destino enva una respuesta a la particin coordinadora.
3. La particin coordinadora recibe la respuesta de la particin de destino.
4. La particin coordinadora pasa la respuesta a la aplicacin.
No se confirma la insercin hasta que la aplicacin emite una sentencia
COMMIT.
5. Cualquier sentencia INSERT que contenga una clusula VALUES es
candidata a una insercin en almacenamiento intermedio,
independientemente del nmero de filas o del tipo de elementos
contenidos en las filas. Es decir, los elementos pueden ser constantes,
registros especiales, variables del lenguaje principal, expresiones,
funciones, etc.
Para una sentencia INSERT determinada con la clusula VALUES, es posible
que el compilador SQL de DB2 no coloque en el almacenamiento intermedio
la insercin en base a consideraciones sobre la semntica, el rendimiento o la
implementacin. Si prepara o enlaza lgicamente su aplicacin con la opcin
INSERT BUF, asegrese de que no depende de una insercin en
almacenamiento intermedio. Esto significa que:
v Se puede informar de errores de forma asncrona para las inserciones en
almacenamiento intermedio, o de forma sncrona para las inserciones
normales. Si se informa de forma asncrona, un error de insercin se puede
notificar en una insercin posterior en el almacenamiento intermedio, o en
la otra sentencia que cierre el almacenamiento intermedio. La sentencia que
informa del error no se ejecuta. Por ejemplo, piense en la utilizacin de una
sentencia COMMIT para cerrar un bucle de inserciones en almacenamiento
intermedio. La confirmacin informa de SQLCODE -803 (SQLSTATE 23505)
debido a una clave duplicada procedente de una insercin anterior. En este
escenario, no se ejecuta la confirmacin. Si desea que la aplicacin efecte
realmente la confirmacin, por ejemplo, algunas actualizaciones realizadas
antes de entrar en el bucle de inserciones en almacenamiento intermedio,
debe volver a emitir la sentencia COMMIT.
v Las filas insertadas pueden resultar visibles inmediatamente mediante una
sentencia SELECT que utilice un cursor sin insercin en almacenamiento
intermedio. Con una insercin en almacenamiento intermedio, las filas no
sern visibles de inmediato. Si precompila o enlaza lgicamente la
aplicacin con la opcin INSERT BUF, no la escriba de forma que dependa
de estas filas seleccionadas por el cursor.
Las inserciones en almacenamiento intermedio tienen como consecuencia las
ventajas siguientes:
v Slo se enva un mensaje desde la particin de destino a la particin
coordinadora por cada almacenamiento intermedio recibido por la particin
de destino.
v Un almacenamiento intermedio puede contener un elevado nmero de filas,
especialmente si las filas son pequeas.
v Se produce un proceso paralelo a medida que se realizan inserciones en las
particiones, mientras la particin coordinadora est recibiendo filas nuevas.
Una aplicacin que se enlaza lgicamente con INSERT BUF se debe escribir de
forma que la misma sentencia INSERT con la clusula VALUES se reitere
repetidamente antes de que se emita cualquier sentencia o API que cierre una
insercin en almacenamiento intermedio.
Nota: para impedir que las inserciones en almacenamiento intermedio llenen
el registro de transacciones, debe realizar confirmaciones peridicas.
v Creacin y preparacin del archivo fuente en la pgina 79
v Consideraciones sobre la utilizacin de inserciones en almacenamiento
intermedio en la pgina 483
v Restricciones en la utilizacin de inserciones en almacenamiento
intermedio en la pgina 486
Consideraciones sobre la utilizacin de inserciones en almacenamiento
intermedio
Las inserciones en almacenamiento intermedio presentan comportamientos
que pueden afectar a un programa de aplicacin. Este comportamiento es
debido a la naturaleza asncrona de las inserciones en almacenamiento
intermedio. En base a los valores de la clave de particionamiento de la fila,
cada fila insertada se coloca en un almacenamiento intermedio destinado a la
particin correcta. Estos almacenamientos intermedios se envan a sus
particiones de destino cuando se llenan o cuando un suceso ocasiona que se
vacen. Cuando disee y codifique la aplicacin, debe tener en cuenta los
aspectos siguientes:
v Existen determinadas condiciones de error de las que no se informa cuando
se ejecuta la sentencia INSERT. Se informa de ellas ms tarde, cuando se
ejecuta la primera sentencia que no sea INSERT (o INSERT en otro tabla),
como por ejemplo DELETE, UPDATE, COMMIT o ROLLBACK. Cualquier
sentencia o API que cierre la sentencia de insercin en almacenamiento
intermedio puede ver el informe de errores. Asimismo, cualquier invocacin
de la propia insercin puede ver un error de una fila insertada previamente.
Por otra parte, si otra sentencia informa de un error de una insercin en
almacenamiento intermedio, como por ejemplo UPDATE o COMMIT, DB2
no intentar ejecutar dicha sentencia.
v Un error detectado durante la insercin de un grupo de filas hace que se
retrotraigan todas las filas de dicho grupo. Un grupo de filas se define
como todas las filas insertadas mediante ejecuciones de una sentencia de
insercin en almacenamiento intermedio:
Desde el principio de la unidad de trabajo,
Desde que se prepar la sentencia (si sta es dinmica), o
Desde la ejecucin anterior de otra sentencia de actualizacin. Para ver
una lista de las sentencias que cierran (o vacan) una insercin en
almacenamiento intermedio, consulte la descripcin de inserciones en
almacenamiento intermedio en entornos de bases de datos particionadas.
v Es posible que una fila insertada no resulte visible inmediatamente para la
sentencias SELECT emitidas despus de INSERT por el mismo programa de
aplicacin, en caso de que SELECT se ejecute utilizando un cursor.
Una sentencia INSERT en almacenamiento intermedio puede estar abierta o
cerrada. La primera invocacin de la sentencia abre la INSERT en
almacenamiento intermedio, se aade la fila al almacenamiento intermedio
apropiado y se devuelve el control a la aplicacin. Las invocaciones
posteriores aaden filas al almacenamiento intermedio, dejando la sentencia
abierta. Mientras la sentencia est abierta, los almacenamientos intermedios se
pueden enviar a sus particiones de destino, donde se insertan las filas en la
particin de la tabla de destino. Si se invoca a cualquier sentencia o API que
cierra una insercin en almacenamiento intermedio mientras hay una
sentencia INSERT en almacenamiento intermedio abierta (incluida una
invocacin de otra sentencia INSERT en almacenamiento intermedio), o si se
emite una sentencia PREPARE para una sentencia INSERT en almacenamiento
intermedio abierta, antes de procesar la nueva peticin se cierra la sentencia
abierta. Si se cierra la sentencia INSERT en almacenamiento intermedio, se
vacan los almacenamientos intermedios restantes. Entonces se envan las filas
a las particiones de destino y se insertan. El proceso de la nueva peticin slo
comienza despus de que se enven todos los almacenamientos intermedios y
se inserten todas las filas.
Si se detectan errores durante el cierre de la sentencia INSERT, la SQLCA de
la nueva peticin se llenar con la descripcin del error y no se ejecutar la
peticin. Asimismo, se eliminar de la base de datos el grupo entero de filas
que se hubieran insertado mediante la sentencia INSERT en almacenamiento
intermedio desde que se abri. El estado de la aplicacin ser tal como se haya
definido para el error concreto que se haya detectado. Por ejemplo:
v Si el error es un punto muerto, se retrotrae la transaccin (incluidos los
cambios efectuados antes de que se abriera la seccin de insercin en
almacenamiento intermedio).
v Si el error es una violacin de una clave exclusiva, el estado de la base de
datos es igual que antes de que se abriera la sentencia. La transaccin
permanece activa y los cambios efectuados antes de que se abriera la
sentencia no se ven afectados.
Por ejemplo, considere la aplicacin siguiente que est enlazada lgicamente
con la opcin de insercin en almacenamiento intermedio:
EXEC SQL UPDATE t1 SET COMMENT=about to start inserts;
DO UNTIL EOF OR SQLCODE < 0;
READ VALUE OF hv1 FROM A FILE;
EXEC SQL INSERT INTO t2 VALUES (:hv1);
IF 1000 INSERTS DONE, THEN DO
EXEC SQL INSERT INTO t3 VALUES (another 1000 done);
RESET COUNTER;
END;
END;
EXEC SQL COMMIT;
Suponga que el archivo contiene 8 000 valores, pero el valor 3 258 no es lcito
(por ejemplo, contiene una violacin de la clave exclusiva). Cada 1 000
inserciones dan como resultado la ejecucin de otra sentencia de SQL que, a
continuacin, cierra la sentencia INSERT INTO t2. Durante el cuarto grupo de
1 000 inserciones, se detectar el error del valor 3 258. Se puede detectar
despus de la insercin de ms valores (y no necesariamente despus del
siguiente). En esta situacin, se devuelve un cdigo de error para la sentencia
INSERT INTO t2.
Tambin es posible que se detecte el error cuando se intente una insercin en
la tabla t3, la cual cerrar la sentencia INSERT INTO t2. En esta situacin, se
devuelve el cdigo de error para la sentencia INSERT INTO t3, aunque el error
corresponda a la tabla t2.
En cambio, suponga que tiene que insertar 3 900 filas. Antes de que se le
indique el error de la fila nmero 3 258, la aplicacin puede salir del bucle e
intentar emitir una sentencia COMMIT. El cdigo de retorno de la violacin
de la clave exclusiva se emitir para la sentencia COMMIT y no se ejecutar
COMMIT. Si la aplicacin desea confirmar (COMMIT) las 3000 filas que se
encuentran hasta ahora en la base de datos (la ltima ejecucin de EXEC SQL
INSERT INTO t3 ... finaliza el punto de rescate para estas 3000 filas), habr
que volver a emitir la sentencia COMMIT. Tambin se aplican consideraciones
parecidas a ROLLBACK.
Nota: cuando utilice inserciones en almacenamiento intermedio, debe
supervisar cuidadosamente los SQLCODE devueltos para evitar que
una tabla quede en un estado indeterminado. Por ejemplo, si eliminara
la clusula SQLCODE < 0 de la sentencia THEN DO del ejemplo anterior,
la tabla podra terminar por contener un nmero indeterminado de
filas.
v Inserciones en almacenamiento intermedio en entornos de bases de datos
particionadas en la pgina 480
Restricciones en la utilizacin de inserciones en almacenamiento
intermedio
Se aplican las restricciones siguientes a las inserciones en almacenamiento
intermedio:
v Para que una aplicacin se aproveche de las inserciones en almacenamiento
intermedio, se tiene que cumplir una de las condiciones siguientes:
La aplicacin debe estar preparada mediante PREP o enlazada
lgicamente con el mandato BIND y se debe especificar la opcin
INSERT BUF.
La aplicacin debe estar enlazada lgicamente utilizando las API BIND o
PREP con la opcin SQL_INSERT_BUF.
v Si la sentencia INSERT con la clusula VALUES incluye campos largos o
LOB en la lista de columnas explcita o implcita, se pasa por alto la opcin
INSERT BUF para esta sentencia y se realiza una insercin normal, no en el
almacenamiento intermedio. sta no es una condicin de error y no se
emite ningn mensaje de error ni de aviso.
v Una INSERT con una seleccin completa no se ve afectada por INSERT
BUF. Una insercin en almacenamiento intermedio no mejora el
rendimiento de este tipo de INSERT.
v Las inserciones en almacenamiento intermedio slo se pueden utilizar en
aplicaciones y no mediante inserciones emitidas por el CLP, puesto que
stas se realizan a travs de la sentencia EXECUTE IMMEDIATE.
Luego, la aplicacin se puede ejecutar desde cualquier plataforma cliente
soportada.
Ejemplo de extraccin un gran volumen de datos en una base de datos
particionada
Aunque DB2 Universal Database proporciona caractersticas excelentes para el
proceso de consultas paralelas, el nico punto de conexin de una aplicacin
o un mandato EXPORT puede convertirse en un embotellamiento si se extraen
grandes volmenes de datos. Este cuello de botella se produce porque el
proceso de pasar los datos del gestor de bases de datos a la aplicacin hace
un gran uso de la CPU que se ejecuta en una sola particin (normalmente,
tambin en un solo procesador).
DB2 Universal Database brinda varios mtodos para vencer el
embotellamiento, de forma que el volumen de datos extrados se escala
linealmente por unidad de tiempo con un nmero de procesadores
incrementado. El ejemplo siguiente describe la idea bsica que se encuentra
detrs de estos mtodos.
Suponga que tiene una tabla llamada EMPLOYEE que est almacenada en 20
particiones de bases de datos, y que genera una lista de correo (FIRSTNME,
LASTNAME, JOB) de todos los empleados que pertenecen a un departamento
legtimo (es decir, en que WORKDEPT no es NULL).
La consulta siguiente se ejecuta en cada particin y luego genera el conjunto
completo de respuestas en una sola particin (la particin coordinadora):
SELECT FIRSTNME, LASTNAME, JOB FROM EMPLOYEE WHERE WORKDEPT IS NOT NULL
Pero la consulta siguiente se puede ejecutar en cada particin correspondiente
a la base de datos (es decir, si existen cinco particiones, se necesitan cinco
consultas separadas, una en cada particin). Cada consulta genera el conjunto
de todos los nombres de empleado cuyo registro se encuentra en la particin
concreta en que se ejecuta la consulta. Cada conjunto de resultados local se
puede redirigir a un archivo. Luego es necesario fusionar los conjuntos de
resultados en un solo conjunto.
En AIX, puede utilizar una propiedad de los archivos del Sistema de archivos
de red (NFS) para automatizar la fusin. Si todas las particiones dirigen sus
conjuntos de respuestas al mismo archivo de un montaje por NFS, los
resultados se fusionan. Observe que una utilizacin de NFS sin bloquear la
respuesta en almacenamientos intermedios grandes tiene como consecuencia
un rendimiento muy pobre.
AND NODENUMBER(NAME) = CURRENT NODE
El resultado se puede almacenar en un archivo local (lo que significa que el
resultado final constar de 20 archivos, cada uno de los cuales contendr una
porcin del conjunto de respuestas completo), o en un solo archivo montado
por NFS.
En el ejemplo siguiente se utiliza el segundo mtodo, de forma que el
resultado se encuentra en un nico archivo montado por NFS para los 20
nodos. El mecanismo de bloqueo de NFS asegura la colocacin en serie de las
grabaciones en el archivo de resultados por parte de las distintas particiones.
Observe que este ejemplo, tal como se presenta, se ejecuta en la plataforma
AIX con un sistema de archivos NFS instalado.
#define _POSIX_SOURCE
#define INCL_32
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sqlenv.h>
#include <errno.h>
#include <sys/access.h>
#include <sys/flock.h>
#include <unistd.h>
#define BUF_SIZE 1500000 /* Almacenamiento intermedio local para almacenar
los registros captados */
#define MAX_RECORD_SIZE 80 /* >= tamao de un registro grabado */
int main(int argc, char *argv[]) {
EXEC SQL INCLUDE SQLCA;
char dbname[10]; /* Nombre de base de datos (argumento
del programa) */
char userid[9];
char passwd[19];
char first_name[21];
char last_name[21];
char job_code[11];
struct flock unlock ; /* estructuras y variables para manejar */
struct flock lock ; /* el mecanismo de bloqueo NFS */
int lock_command ;
int lock_rc ;
int iFileHandle ; /* archivo de salida */
int iOpenOptions = 0 ;
int iPermissions ;
char * file_buf ; /* puntero al almacenamiento intermedio
en que se acumulan los registros captados */
char * write_ptr ; /* posicin en que se graba el siguiente
registro */
int buffer_len = 0 ; /* longitud de la porcin utilizada del
almacenamiento intermedio */
/* Inicializacin */
lock.l_type = F_WRLCK; /* Peticin de bloqueo exclusivo de grabacin */
lock.l_start = 0; /* Para bloquear el archivo entero */
lock.l_whence = SEEK_SET;
lock.l_len = 0;
unlock.l_type = F_UNLCK; /* Peticin de liberacin de un bloqueo */
unlock.l_start = 0; /* Para desbloquear el archivo entero */
unlock.l_whence = SEEK_SET;
unlock.l_len = 0;
lock_command = F_SETLKW; /* Establecer el bloqueo */
iOpenOptions = O_CREAT; /* Crear el archivo si no existe */
iOpenOptions |= O_WRONLY; /* Abrir slo para grabacin */
/* Conectar con la base de datos */
if (argc == 3) {
strcpy( dbname, argv[2] ); /* obtener nombre de base de datos del argumento */
EXEC SQL CONNECT TO :dbname IN SHARE MODE ;
if ( SQLCODE != 0 ) {
printf( "Error: CONNECT TO the database failed. SQLCODE = %ld\n",
SQLCODE );
exit(1);
}
}
else if ( argc == 5 ) {
strcpy( dbname, argv[2] ); /* obtener nombre de base de datos del argumento */
strcpy (userid, argv[3]);
strcpy (passwd, argv[4]);
EXEC SQL CONNECT TO :dbname IN SHARE MODE USER :userid USING :passwd;
printf( "Error: CONNECT TO the database failed. SQLCODE = %ld\n",
SQLCODE );
exit( 1 );
}
}
else
printf ("\nUSAGE: largevol txt_file database [userid passwd]\n\n");
exit( 1 ) ;
} /* endif */
/* Abrir el archivo de entrada con los permisos de acceso especificados */
if ( ( iFileHandle = open(argv[1], iOpenOptions, 0666 ) ) == -1 ) {
printf( "Error: Could not open %s.\n", argv[2] ) ;
exit( 2 ) ;
}
/* Establecer escapes por error y fin de tabla */
EXEC SQL WHENEVER SQLERROR GO TO ext ;
EXEC SQL WHENEVER NOT FOUND GO TO cls ;
/* Declarar y abrir el cursor */
SELECT firstnme, lastname, job FROM employee
WHERE workdept IS NOT NULL
AND NODENUMBER(lastname) = CURRENT NODE;
EXEC SQL OPEN c1 ;
/* Establecer almacenamiento intermedio temporal para almacenar el
resultado captado */
if ( ( file_buf = ( char * ) malloc( BUF_SIZE ) ) == NULL ) {
printf( "Error: Allocation of buffer failed.\n" ) ;
exit( 3 ) ;
}
memset( file_buf, 0, BUF_SIZE ) ; /* restablecer almacenamiento intermedio */
buffer_len = 0 ; /* restablecer longitud del almacenamiento intermedio */
write_ptr = file_buf ; /* restablecer el puntero de grabacin */
/* Para cada registro captado realizar lo siguiente */
/* - insertarlo en el almac. interm. tras el */
/* registro almacenado previamente */
/* - comprobar si an queda espacio suficiente en */
/* el almac. int. para el siguiente registro y bloquear/grabar/ */
/* desbloquear el archivo e inicializar el almac.*/
/* intermedio si no es as */
do {
EXEC SQL FETCH c1 INTO :first_name, :last_name, :job_code;
buffer_len += sprintf( write_ptr, "%s %s %s\n",
first_name, last_name, job_code );
buffer_len = strlen( file_buf ) ;
/* Grabar el contenido del almac. int. en archivo */
/* si el almac. int. alcanza el lmite */
if ( buffer_len >= ( BUF_SIZE - MAX_RECORD_SIZE ) ) {
/* obtener bloqueo exclusivo de grabacin */
lock_rc = fcntl( iFileHandle, lock_command, &lock );
if ( lock_rc != 0 ) goto file_lock_err;
/* posicionar al final del archivo */
lock_rc = lseek( iFileHandle, 0, SEEK_END );
if ( lock_rc < 0 ) goto file_seek_err;
/* grabar el almacenamiento intermedio */
lock_rc = write( iFileHandle,
( void * ) file_buf, buffer_len );
if ( lock_rc < 0 ) goto file_write_err;
/* liberar el bloqueo */
lock_rc = fcntl( iFileHandle, lock_command, &unlock );
if ( lock_rc != 0 ) goto file_unlock_err;
file_buf[0] = \0 ; /* restablecer almacenamiento intermedio */
buffer_len = 0 ; /* restablecer longitud del almacenamiento intermedio */
write_ptr = file_buf ; /* restablecer puntero de grabacin */
}
else
write_ptr = file_buf + buffer_len ; /* siguiente posicin de grabacin */
}
} while (1) ;
cls:
/* Grabar la ltima porcin de datos en el archivo */
if (buffer_len > 0) {
lock_rc = fcntl(iFileHandle, lock_command, &lock);
if (lock_rc != 0) goto file_lock_err;
lock_rc = lseek(iFileHandle, 0, SEEK_END);
if (lock_rc < 0) goto file_seek_err;
lock_rc = write(iFileHandle, (void *)file_buf, buffer_len);
if (lock_rc < 0) goto file_write_err;
lock_rc = fcntl(iFileHandle, lock_command, &unlock);
if (lock_rc != 0) goto file_unlock_err;
}
free(file_buf);
close(iFileHandle);
EXEC SQL CLOSE c1;
exit (0);
ext:
if ( SQLCODE != 0 )
printf( "Error: SQLCODE = %ld.\n", SQLCODE );
EXEC SQL WHENEVER SQLERROR CONTINUE;
EXEC SQL CONNECT RESET;
printf( "CONNECT RESET Error: SQLCODE = %ld\n", SQLCODE );
exit(4);
}
exit (5);
file_lock_err:
printf("Error: file lock error = %ld.\n",lock_rc);
/* desbloqueo incondicional del archivo */
fcntl(iFileHandle, lock_command, &unlock);
exit(6);
file_seek_err:
printf("Error: file seek error = %ld.\n",lock_rc);
exit(7);
file_write_err:
printf("Error: file write error = %ld.\n",lock_rc);
exit(8);
file_unlock_err:
printf("Error: file unlock error = %ld.\n",lock_rc);
exit(9);
}
Este mtodo no slo es aplicable a la seleccin de una nica tabla, sino que
tambin sirve para consultas ms complejas. No obstante, si la consulte
requiere operaciones no distribuidas (es decir, Explain muestra ms de una
subseccin junto a la subseccin Coordinator), puede tener como consecuencia
que se produzca un nmero excesivo de procesos en algunas particiones, en
caso de que la consulta se ejecute en paralelo en todas las particiones. En esta
situacin, puede almacenar el resultado de la consulta en una tabla temporal
TEMP, en tantas particiones como sea necesario, y luego realizar la extraccin
final en paralelo desde TEMP.
Si desea extraer todos los empleados, pero nicamente para clasificaciones de
trabajo seleccionadas, puede definir la tabla TEMP con los nombres de
columna FIRSTNME, LASTNAME y JOB, tal como sigue:
INSERT INTO TEMP
AND EMPNO NOT IN (SELECT EMPNO FROM EMP_ACT WHERE
EMPNO<200)
A continuacin, realizar la extraccin paralela sobre TEMP.
Cuando defina la tabla TEMP, tenga en cuenta lo siguiente:
v Si la consulta especifica una agregacin GROUP BY, debe definir la clave de
particionamiento de TEMP como subconjunto de las columnas GROUP BY.
v La clave de particionamiento de la tabla TEMP debe tener la cardinalidad
(es decir, el nmero de valores diferenciados en el conjunto de respuestas)
suficiente para asegurarse de que la tabla se distribuye de forma igualitaria
en las particiones en que est definida.
v Cree la tabla TEMP con el atributo NOT LOGGED INITIALLY, luego
confirme (COMMIT) la unidad de trabajo que ha creado la tabla para
liberar los posibles bloqueos de catlogo adquiridos.
v Cuando utilice la tabla TEMP, debe emitir las sentencias siguientes en una
sola unidad de trabajo:
1. ALTER TABLE TEMP ACTIVATE NOT LOGGED INITIALLY WITH
EMPTY TABLE (para vaciar la tabla TEMP y desactivar el registro)
2. INSERT INTO TEMP SELECT FIRSTNAME...
3. COMMIT
Esta tcnica le permite insertar un gran conjunto de respuestas en una tabla
sin realizar un registro y sin que se produzca ninguna contencin de
catlogos. Sin embargo, si una tabla tiene activado el atributo NOT
LOGGED INITIALLY, se produce una actividad no registrada y una de las
siguientes situaciones:
Una sentencia falla, causando una retrotraccin
Se ejecuta una operacin ROLLBACK TO SAVEPOINT
se retrotrae la unidad de trabajo entera (SQL1476N), con lo que la tabla
TEMP queda inutilizable. Si as sucede, deber eliminar y volver a crear la
tabla TEMP. Por este motivo, no debe utilizar esta tcnica para aadir datos
a una tabla que no pueda volver a crear fcilmente.
Si necesita que el conjunto final de respuestas (que est formado por el
conjunto de respuestas parciales fusionadas de todas las particiones) est
clasificado, puede:
v Especificar la clusula SORT BY en la sentencia SELECT final
v Realizar una extraccin en un archivo separado en cada particin
v Fusionar los archivos separados en un conjunto de salida utilizando, por
ejemplo, el mandato sort -m de AIX.
Creacin de un entorno simulado de bases de datos particionadas
Puede crear un entorno de prueba para sus aplicaciones de entorno
particionadas sin configurar un entorno de bases de datos particionadas.
Procedimiento:
Para crear un entorno simulado de bases de datos particionadas:
1. Cree un modelo de diseo de la base de datos con DB2 Enterprise Server
Edition.
2. Cree tablas de ejemplo con la clusula PARTITIONING KEY, que utilizar
para distribuir los datos entre las particiones del entorno de produccin.
3. Cree y ejecute sus aplicaciones para la base de datos de prueba.
DB2 Enterprise Server Edition impone las restricciones de clave de
particionamiento que se aplican en un entorno de bases de datos
particionadas y proporciona un til entorno de prueba para las aplicaciones.
Resolucin de problemas
Las secciones siguientes describen cmo solucionar problemas de aplicaciones
en un entorno de bases de datos particionadas.
Consideraciones sobre el manejo de errores en entornos de bases de
datos particionadas
En un entorno de bases de datos particionadas, DB2 divide las sentencias de
SQL en subsecciones, cada una de las cuales se procesa en la particin que
contiene los datos relevantes. Como resultado, se puede producir un error en
una particin que no tenga acceso a la aplicacin. Esta condicin no se
produce en un entorno de bases de datos no particionadas.
Debe tener en cuenta lo siguiente:
v Errores no graves de no CURSOR (EXECUTE)
v Errores no graves de CURSOR
v Errores graves
v Varias estructuras SQLCA fusionadas
v Cmo identificar la particin que ha devuelto el error
Si una aplicacin finaliza de forma anormal debido a un error grave, es
posible que se dejen transacciones dudosas en la base de datos. (Una
transaccin dudosa pertenece a transacciones globales cuando una fase
finaliza satisfactoriamente, pero el sistema falla antes de poder completar la
siguiente fase, dejando la base de datos en un estado incoherente.)
v Errores graves en entornos de bases de datos particionadas en la pgina
494
v Varias estructuras SQLCA fusionadas en la pgina 495
v Particin que devuelve el error en la pgina 496
v Manually resolving indoubt transactions en el manual Administration
Guide: Planning
Errores graves en entornos de bases de datos particionadas
Si se produce un error grave en un entorno de bases de datos particionadas,
se producir una de las siguientes situaciones:
v El gestor de bases de datos de la particin en la que se produce el error se
cierra.
Las unidades de trabajo activas no se retrotraen.
En esta situacin, debe recuperar la particin y las bases de datos que
estaban activas en la particin cuando se produjo el cierre.
v Se impone la salida de todos los agentes de la base de datos en la particin
en la que se ha producido el error.
Todas las unidades de trabajo de dicha base de datos se retrotraen.
En esta situacin, la particin de base de datos en la que se ha producido el
error se marca como incoherente. Cualquier intento de acceder a la misma
da como resultado la devolucin de SQLCODE -1034 (SQLSTATE 58031) o
SQLCODE -1015 (SQLSTATE 55025). Antes de que el usuario o cualquier
otra aplicacin de otra particin pueda acceder a esta particin de base de
datos, debe ejecutar el mandato RESTART DATABASE contra la base de
datos.
El error grave SQLCODE -30081 (SQLSTATE 08001) se puede producir por
varios motivos. Si recibe este mensaje, compruebe la SQLCA, la cual indicar
qu particin ha fallado. Luego compruebe el archivo de registro de
notificaciones del administrador para ver detalles.
v Particin que devuelve el error en la pgina 496
v Mandato RESTART DATABASE en el manual Consulta de mandatos
Varias estructuras SQLCA fusionadas
Distintos agentes de distintas particin de base de datos pueden ejecutar una
sentencia de SQL, y cada agente puede devolver una SQLCA distinta para
diferentes errores o avisos. El agente coordinador tambin tiene su propia
SQLCA. Adems, la SQLCA tambin tiene campos que indican nmeros
globales (como los campos sqlerrd que indican nmeros de filas). Para ofrecer
una vista coherente para las aplicaciones, todos los valores de SQLCA se
fusionan en una estructura.
La notificacin de errores se realiza del siguiente modo:
v Las condiciones de errores graves siempre se notifican. En cuanto se notifica
un error grave, no se realizan adiciones, adems del error grave, a la
SQLCA.
v Si no se produce ningn error grave, un error de punto muerto tiene
precedencia sobre los dems errores.
v Para los dems errores, se devuelve a la aplicacin la SQLCA
correspondiente al primer SQLCODE negativo.
v Si no se detecta ningn SQLCODE negativo, se devuelve a la aplicacin la
SQLCA correspondiente al primer aviso (es decir, SQLCODE positivo). Se
produce una excepcin a esta norma si se emite una operacin de
manipulacin de datos en una tabla que est vaca en una particin pero
que tiene datos en otras particiones. El SQLCODE +100 slo se devuelve a
la aplicacin si los agentes de todas las particiones devuelven SQL0100W
porque la tabla est vaca en todas las particiones o porque no hay filas que
satisfagan la clusula WHERE de una sentencia UPDATE.
v Para todos los errores y avisos, el campo sqlwarn contiene los distintivos de
aviso recibidos de todos los agentes.
v Los valores de los campos sqlerrd que indican nmeros de filas son sumas
de todos los agentes.
Una aplicacin puede recibir un error o aviso siguiente despus de que se
corrija el problema que ocasion el primer error o aviso. Los errores se
notifican a la SQLCA para asegurar que el primer error detectado tiene
prioridad sobre otros. Esto asegura que un error ocasionado por un error
anterior no puede sobregrabar el error original. Los errores graves y los
errores de punto muerto tienen una prioridad ms alta porque necesitan una
accin inmediata por parte del agente coordinador.
Particin que devuelve el error
Si una particin devuelve un error o aviso, su nmero est en el campo
SQLERRD(6) de la SQLCA. El nmero de este campo coincide con el
especificado para la particin en el archivo db2nodes.cfg.
Si una llamada a una sentencia de SQL o API resulta satisfactoria, el nmero
de particin de este campo no es significativo.
Aplicaciones en bucle o suspendidas
Es posible que, despus de iniciar una consulta o aplicacin, sospeche que
est suspendida (no muestra ninguna actividad) o que ha entrado en un bucle
(muestra actividad, pero no se devuelve ningn resultado a la aplicacin).
Asegrese de que ha activado los tiempos de espera de bloqueo. Sin embargo,
en algunas situaciones no se devuelve ningn error. En estas situaciones,
pueden resultarle de ayuda las herramientas de diagnstico que se
proporcionan con y la instantnea del supervisor del sistema de bases de
datos.
Una de las funciones del supervisor del sistema de bases de datos que resulta
til para depurar aplicaciones consiste en visualizar el estado de todos los
agentes activos. Para sacar el mximo provecho de una instantnea, asegrese
de que la recopilacin de sentencias se realiza antes de ejecutar la aplicacin
(preferiblemente inmediatamente despus de ejecutar DB2START) del
siguiente modo:
db2_all "db2 UPDATE MONITOR SWITCHES USING STATEMENT ON"
Si sospecha que la aplicacin o consulta est atascada o ha entrado en un
bucle, emita el siguiente mandato:
db2_all "db2 GET SNAPSHOT FOR AGENTS ON base de datos
v Database system monitor en el manual System Monitor Guide and Reference
v The database system-monitor information en el manual Administration
Guide: Performance
v Mandato GET SNAPSHOT en el manual Consulta de mandatos
v Mandato UPDATE MONITOR SWITCHES en el manual Consulta de
mandatos
v db2support - Mandato Herramienta de anlisis de problemas y recoleccin
del entorno en el manual Consulta de mandatos
Captulo 18. Tcnicas comunes de aplicacin de DB2
Columnas generadas . . . . . . . . . 499
Columnas de identidad . . . . . . . . 500
Valores secuenciales y objetos de secuencia 501
Generacin de valores secuenciales . . . 502
Gestin del comportamiento de
secuencias . . . . . . . . . . . 504
Rendimiento de la aplicacin y objetos de
secuencia . . . . . . . . . . . 505
Comparacin entre objetos de secuencia y
columnas de identidad . . . . . . . 506
Tablas temporales declaradas y rendimiento
de la aplicacin . . . . . . . . . . 506
Puntos de rescate y transacciones . . . . 509
Gestin de transacciones con puntos de
rescate . . . . . . . . . . . . 509
Comparacin entre puntos de rescate de
la aplicacin y bloques de SQL compuesto 511
Sentencias de SQL para crear y controlar
puntos de rescate . . . . . . . . . 513
Restricciones sobre el uso de puntos de
rescate . . . . . . . . . . . . 514
Puntos de rescate y Lenguaje de
definicin de datos (DDL) . . . . . . 514
Puntos de rescate e inserciones en
almacenamiento intermedio . . . . . 515
Puntos de rescate y bloqueo de cursor 516
Puntos de rescate y gestores de
transacciones que cumplen con XA . . . 517
Transmisin de grandes volmenes de datos
a travs de una red . . . . . . . . . 517
Columnas generadas
En lugar de utilizar engorrosos activadores de insercin y actualizacin, DB2
le permite incluir columnas generadas en sus tablas mediante la clusula
GENERATED ALWAYS AS. Una columna generada es una columna que
deriva de los valores de cada fila procedente de una expresin, en lugar de
hacerlo de una operacin de insercin o actualizacin. Aunque que la
combinacin de un activador de actualizacin y un activador de insercin
puede conseguir un efecto parecido, la utilizacin de una columna generada
garantiza que el valor derivado es coherente con la expresin.
Para crear una columna generada en una tabla, utilice la clusula
GENERATED ALWAYS AS para la columna e incluya la expresin de la cual
se derivar el valor correspondiente a la columna. Puede incluir la clusula
GENERATED ALWAYS AS en sentencias ALTER TABLE y CREATE TABLE. El
siguiente ejemplo crea una tabla con dos columnas normales, c1 y c2, y
dos columnas generadas, c3 y c4, que se derivan de las columnas
normales de la tabla.
CREATE TABLE T1(c1 INT, c2 DOUBLE,
c3 DOUBLE GENERATED ALWAYS AS (c1 + c2),
c4 GENERATED ALWAYS AS
(CASE
WHEN c1 > c2 THEN 1
ELSE NULL
END)
);
v Defining a generated column on a new table en el manual Administration
Guide: Implementation
v Defining a generated column on an existing table en el manual
Administration Guide: Implementation
v TbGenCol.java -- How to use generated columns (JDBC)
Columnas de identidad
Las columnas de identidad proporcionan a los programadores de aplicaciones
de DB2 una forma sencilla de generar automticamente un valor numrico de
columna para cada fila de una tabla. Puede hacer que este valor se genere
como valor exclusivo y luego definir la columna de identidad como la clave
principal para la tabla. Para crear una columna de identidad, incluya la
clusula IDENTITY en la sentencia CREATE TABLE o ALTER TABLE.
Utilice columnas de identidad en las aplicaciones para evitar problemas de
concurrencia y de rendimiento que se pueden producir cuando una aplicacin
genera su propio contador exclusivo fuera de la base de datos. Cuando no
utilice columnas de identidad para generar automticamente claves
principales exclusivas, un diseo comn consiste en almacenar un contador en
una tabla con una sola fila. Luego cada transaccin bloquea esta tabla,
aumenta el nmero y luego confirma la transaccin para desbloquear el
contador. Desgraciadamente, este diseo slo permite que una sola
transaccin aumente el contador cada vez.
Por el contrario, si utiliza una columna de identidad para generar
automticamente claves principales, la aplicacin puede conseguir niveles de
concurrencia muy superiores. Con columnas de identidad, DB2 mantiene el
contador de forma que las transacciones no lo tienen que bloquear. Las
aplicaciones que utilizan columnas de identidad pueden funcionar mejor
porque una transaccin no confirmada que ha aumentado el contador no evita
que otras transacciones siguientes puedan tambin aumentar el contador.
El contador correspondiente a la columna de identidad aumenta o desciende
independientemente de la transaccin. Si una determinada transaccin
aumenta un contador de identidad dos veces, dicha transaccin puede
observar un salto en los dos nmeros que se generan porque es posible que
otras transacciones estn incrementando simultneamente el mismo contador
de identidad.
Puede que parezca que una columna de identidad ha generado saltos en el
contador, como resultado de una transaccin que se ha retrotrado o porque la
base de datos ha colocado en antememoria un rango de valores que se han
desactivado (de forma normal o anmala) antes de que se asignaran todos los
valores colocados en antememoria.
Para recuperar el valor generado despus de insertar una fila nueva en una
tabla con una columna de identidad, utilice la funcin identity_val_local().
La clusula IDENTITY est disponible para las sentencias CREATE TABLE y
ALTER TABLE.
v Identity columns en el manual Administration Guide: Planning
v Defining an identity column on a new table en el manual Administration
v Modifying an identity column definition en el manual Administration
v Altering an identity column en el manual Administration Guide:
Implementation
v tbident.sqc -- How to use identity columns (C)
v TbIdent.java -- How to use Identity Columns (JDBC)
v TbIdent.sqlj -- How to use Identity Columns (SQLj)
Valores secuenciales y objetos de secuencia
Las secciones siguientes describen consideraciones sobre valores secuenciales
y objetos de secuencia.
Captulo 18. Tcnicas comunes de aplicacin de DB2 501
Generacin de valores secuenciales
La generacin de valores secuenciales es un problema comn del desarrollo
de aplicaciones de base de datos. La mejor solucin a este problema es la
utilizacin de objetos de secuencia y expresiones de secuencia en SQL. Cada
objeto de secuencia es un objeto de base de datos con nombre exclusivo al que
slo pueden acceder las expresiones de secuencia. Hay dos expresiones de
secuencia: la expresin PREVVAL y la expresin NEXTVAL. La expresin
PREVVAL devuelve el ltimo valor generado en el proceso de aplicacin
correspondiente al objeto de secuencia especificado. Cualquier expresin
NEXTVAL que aparezca en la misma sentencia que la expresin PREVAL no
tiene ningn efecto sobre el valor que genera la expresin PREVAL en dicha
sentencia. La expresin de secuencia NEXTVAL incrementa el valor del objeto
de secuencia y devuelve el nuevo valor del objeto de secuencia.
Para crear un objeto de secuencia, emita la sentencia CREATE SEQUENCE.
Por ejemplo, para crear un objeto de secuencia llamado id_values utilizando
los atributos por omisin, emita la sentencia siguiente:
CREATE SEQUENCE id_values
Para generar el primer valor de la sesin de la aplicacin correspondiente al
objeto de secuencia, emita una sentencia VALUES que utilice la expresin
NEXTVAL:
VALUES NEXTVAL FOR id_values
1
-----------
1
1 registro(s) seleccionado(s).
Para visualizar el valor actual del objeto de secuencia, emita una sentencia
VALUES que utilice la expresin PREVVAL:
VALUES PREVVAL FOR id_values
1
-----------
1
Se puede recuperar el valor actual del objeto de secuencia repetidamente y el
valor que el objeto de secuencia devuelve no cambia hasta que se emite una
expresin NEXTVAL. En el ejemplo siguiente, la expresin PREVVAL
devuelve un valor de 1, hasta que la expresin NEXTVAL de la conexin
actual aumenta el valor del objeto de secuencia:
1
-----------
1
1
-----------
1
VALUES NEXTVAL FOR id_values
1
-----------
2
1
-----------
2
Para actualizar el valor de una columna con el siguiente valor del objeto de
secuencia, incluya la expresin NEXTVAL en la sentencia UPDATE, del modo
siguiente:
UPDATE personal
SET id = NEXTVAL FOR id_values
WHERE id = 350
Para insertar una nueva fila en una tabla utilizando el siguiente valor del
objeto de secuencia, incluya la expresin NEXTVAL en la sentencia INSERT,
del modo siguiente:
INSERT INTO personal (id, nombre, dept, cargo)
VALUES (NEXTVAL FOR id_values, Kandil, 51, Director)
v CREATE SEQUENCE sentencia en el manual Consulta de SQL, Volumen 2
v DbSeq.java -- How to create, alter and drop a sequence in a database
(JDBC)
Gestin del comportamiento de secuencias
Puede adaptar el comportamiento de objetos de secuencia para satisfacer las
necesidades de su aplicacin. Se cambian los atributos de un objeto de
secuencia cuando se emite la sentencia CREATE SEQUENCE para crear un
nuevo objeto de secuencia y cuando se emite una sentencia ALTER
SEQUENCE para un objeto de secuencia ya existente. A continuacin se
encuentran algunos de los atributos de un objeto de secuencia que se pueden
especificar:
Tipo de datos
La clusula AS de la sentencia CREATE SEQUENCE especifica el tipo
de datos numrico del objeto de secuencia. El tipo de datos determina
los posibles valores mnimo y mximo del objeto de secuencia (los
valores mnimo y mximo correspondientes a un tipo de datos se
listan en el tema que describe los lmites de SQL). No se puede
cambiar el tipo de datos de un objeto de secuencia; en su lugar,
deber descartar el objeto de secuencia emitiendo la sentencia DROP
SEQUENCE y emitir una sentencia CREATE SEQUENCE con el nuevo
tipo de datos.
Valor inicial
La clusula START WITH de la sentencia CREATE SEQUENCE
establece el valor inicial del objeto de secuencia. La clusula RESTART
WITH de la sentencia ALTER SEQUENCE restablece el valor del
objeto de secuencia en un valor especificado.
Valor mnimo
La clusula MINVALUE establece el valor mnimo del objeto de
secuencia.
Valor mximo
La clusula MAXVALUE establece el valor mximo del objeto de
secuencia.
Valor de incremento
La clusula INCREMENT BY establece el valor que cada expresin
NEXTVAL aade al valor actual del objeto de secuencia. Para
disminuir el valor del objeto de secuencia, especifique un valor
negativo.
Secuencia cclica
La clusula CYCLE hace que el valor de un objeto de secuencia que
alcanza su valor mximo o mnimo genere su valor mnimo o mximo
respectivo en la siguiente expresin NEXTVAL.
Por ejemplo, para crear un objeto de secuencia llamado id_values que empiece
con un valor mnimo de 0, tenga un valor mximo de 1000, incremente en 2
con cada expresin NEXTVAL y vuelva a su valor mnimo cuando se alcance
el valor mximo, emita la sentencia siguiente:
CREATE SEQUENCE id_values
START WITH 0
INCREMENT BY 2
MAXVALUE 1000
CYCLE
v Lmites de SQL en el manual Consulta de SQL, Volumen 1
v ALTER SEQUENCE sentencia en el manual Consulta de SQL, Volumen 2
v CREATE SEQUENCE sentencia en el manual Consulta de SQL, Volumen 2
Rendimiento de la aplicacin y objetos de secuencia
Al igual que las columnas de identidad, la utilizacin de objetos de secuencia
para generar valores normalmente mejora el rendimiento de las aplicaciones
en comparacin con los acercamientos alternativos. La alternativa a los objetos
de secuencia consiste en crear una tabla de una sola columna que almacene el
valor actual e incremente este valor con un activador o bajo el control de la
aplicacin. En un entorno distribuido donde las aplicaciones acceden de forma
simultnea a la tabla de una sola columna, el bloqueo necesario para forzar el
acceso en serie a la tabla puede afectar gravemente al rendimiento.
Los objetos de secuencia evitan los problemas de bloqueo que estn asociados
con el enfoque de tablas de una nica columna y pueden almacenar en
antememoria valores de secuencia en memoria para mejorar el tiempo de
respuesta de DB2. Para maximizar el rendimiento de aplicaciones que utilizan
objetos de secuencia, asegrese de que el objeto de secuencia almacene en
antememoria una cantidad apropiada de valores de secuencia. La clusula
CACHE de las sentencias CREATE SEQUENCE y ALTER SEQUENCE
especifica el nmero mximo de valores de secuencia que DB2 genera y
almacena en memoria.
Si el objeto de secuencia debe generar valores en orden, sin incorporar
espacios en ese orden debido a una anomala del sistema o desactivacin de la
base de datos, utilice las clusulas ORDER y NO CACHE en la sentencia
CREATE SEQUENCE. La clusula NO CACHE garantiza que no aparezcan
espacios en los valores generados a expensas de parte del rendimiento de la
aplicacin, puesto que fuerza al objeto de secuencia a grabar en la anotacin
cronolgica de la base de datos cada vez que genera un nuevo valor. Observe
que es posible que sigan apareciendo saltos debido a transacciones que se
retrotraen y no utilizan realmente el valor de secuencia que han solicitado.
Comparacin entre objetos de secuencia y columnas de identidad
Aunque los objetos de secuencia y las columnas de identidad parecen tener
finalidades parecidas para aplicaciones de DB2, existe una diferencia
importante. Una columna de identidad genera automticamente valores para
una columna en una sola tabla. Un objeto de secuencia genera valores
secuenciales bajo peticin que se pueden utilizar en cualquier sentencia de
SQL.
Tablas temporales declaradas y rendimiento de la aplicacin
Una tabla temporal declarada es una tabla temporal a la que slo pueden
acceder las sentencias de SQL que emite la aplicacin que ha creado la tabla
temporal. Una tabla temporal declarada no dura ms que la conexin de la
aplicacin con la base de datos.
Utilice tablas temporales declaradas para mejorar potencialmente el
rendimiento de sus aplicaciones. Cuando crea una tabla temporal declarada,
DB2 no inserta una entrada en las tablas del catlogo del sistema, y por lo
tanto el servidor no experimenta problemas relacionados con la contencin
por el catlogo. En comparacin con las tablas normales, DB2 no bloquea las
tablas temporales declaradas ni sus filas y, si especifica el parmetro NOT
LOGGED al crearlas, no registra las tablas temporales declaradas ni su
contenido. Si la aplicacin actual crea tablas para procesar grandes cantidades
de datos y elimina dichas tablas cuando la aplicacin ha terminado de
manipular dichos datos, considere la posibilidad de utilizar tablas temporales
declaradas en lugar de tablas normales.
Si desarrolla aplicaciones escritas para usuarios simultneos, las aplicaciones
se pueden beneficiar de las tablas temporales declaradas. A diferencia de las
tablas normales, las tablas temporales declaradas no estn sujetas a colisin de
nombres. Para cada instancia de la aplicacin, DB2 puede crear una tabla
temporal declarada con un nombre idntico. Por ejemplo, para escribir una
aplicacin para usuarios simultneos que utilice tablas normales para procesar
grandes cantidades de datos temporales, debe asegurarse de que cada
instancia de la aplicacin utilice un nombre exclusivo para la tabla normal que
contiene los datos temporales. Normalmente, creara otra tabla que efecte un
seguimiento de los nombres de las tablas que se estn utilizando en cada
momento. Con tablas temporales declaradas, simplemente especifique un
nombre de tabla temporal declarada para sus datos temporales. DB2 garantiza
que cada instancia de la aplicacin utiliza una tabla exclusiva.
Para utilizar una tabla temporal declarada, siga los pasos siguientes:
Paso 1. Asegrese de que existe un USER TEMPORARY TABLESPACE. Si no
existe ningn USER TEMPORARY TABLESPACE, emita una
sentencia CREATE USER TEMPORARY TABLESPACE.
Paso 2. Emita una sentencia DECLARE GLOBAL TEMPORARY TABLE en la
aplicacin.
El esquema correspondiente a tablas temporales declaradas siempre es
SESSION. Para utilizar la tabla temporal declarada en las sentencias de SQL,
debe hacer referencia a la tabla mediante el calificador de esquema SESSION
de forma explcita o utilizando un esquema DEFAULT de SESSION para
calificar las referencias no calificadas. En el siguiente ejemplo, el nombre de
tabla siempre est calificado mediante el nombre de esquema SESSION
cuando crea una tabla temporal declarada denominada TT1 con la siguiente
sentencia:
DECLARE GLOBAL TEMPORARY TABLE TT1
Para seleccionar el contenido de la columna column1 de la tabla temporal
declarada creada en el ejemplo anterior, utilice la sentencia siguiente:
SELECT column1 FROM SESSION.TT1;
Observe que DB2 tambin le permite crear tablas permanentes con el esquema
SESSION. Si crea una tabla permanente con el nombre calificado
SESSION.TT3, luego puede crear una tabla temporal declarada con el nombre
calificado SESSION.TT3. En esta situacin, DB2 siempre resuelve las
referencias a las tablas permanente y temporal declarada con nombres
calificados idnticos a la tabla temporal declarada. Para evitar confundir tablas
permanentes con tablas temporales declaradas, no debe crear tablas
permanentes con el esquema SESSION.
Si crea una aplicacin que incluye una referencia de SQL esttico a una tabla,
vista o alias calificado con el esquema SESSION, el precompilador de DB2 no
compila dicha sentencia en el momento de la vinculacin y marca la sentencia
para indicar que necesita compilacin. En el tiempo de ejecucin, DB2
compila la sentencia. Este comportamiento se denomina vinculacin
incremental. DB2 realiza automticamente una vinculacin incremental para
referencias de SQL esttico a tablas, vistas y alias calificados con el esquema
SESSION. No hace falta que especifique la opcin VALIDATE RUN en el
mandato BIND o PRECOMPILE para permitir una vinculacin incremental
para dichas sentencias.
Si emite una sentencia ROLLBACK para una transaccin que incluye una
sentencia DECLARE GLOBAL TEMPORARY TABLE, DB2 elimina la tabla
temporal declarada. Si emite una sentencia DROP TABLE para una tabla
temporal declarada, al emitir una sentencia ROLLBACK para dicha
transaccin slo se restaura una tabla temporal declarada vaca. Una sentencia
ROLLBACK de una sentencia DROP TABLE no restaura las filas que existan
en la tabla temporal declarada.
El comportamiento por omisin de una tabla temporal declarada consiste en
suprimir todas las filas de la tabla cuando el usuario confirma una
transaccin. Sin embargo, si quedan uno o ms cursores WITH HOLD
abiertos en la tabla temporal declarada, DB2 no suprime las filas de la tabla
cuando el usuario confirma una transaccin. Para evitar suprimir todas las
filas cuando confirma una transaccin, cree la tabla temporal utilizando la
clusula ON COMMIT PRESERVE ROWS en la sentencia DECLARE GLOBAL
TEMPORARY TABLE.
Si modifica el contenido de una tabla temporal declarada mediante una
sentencia INSERT, UPDATE o DELETE dentro de una transaccin y retrotrae
dicha transaccin, DB2 suprime todas las filas de la tabla temporal declarada.
Si intenta modificar el contenido de una tabla temporal declarada mediante
una sentencia INSERT, UPDATE o DELETE y la sentencia falla, DB2 se
comporta del siguiente modo:
v Si la tabla se cre sin el parmetro NOT LOGGED (es decir, la tabla se
registra), slo se retrotraen los cambios realizados por la sentencia INSERT,
UPDATE o DELETE.
v Si la tabla se cre con el parmetro NOT LOGGED, DB2 suprime todas las
filas de la tabla temporal declarada.
Cuando se encuentra una anomala en un entorno de bases de datos
particionadas, todas las tablas temporales declaradas existentes en la particin
de base de datos que ha fallado pasan a estar inutilizable. Cualquier acceso
siguiente a estas tablas temporales declaradas inutilizables devuelve un error
(SQL1477N). Cuando la aplicacin encuentra una tabla temporal declarada
inutilizable, la aplicacin puede eliminar la tabla o volverla a crear
especificando la clusula WITH REPLACE en la sentencia DECLARE
GLOBAL TEMPORARY TABLE.
Las tablas temporales declaradas estn sujetas a varias restricciones. Por
ejemplo, no puede definir alias ni vistas para tablas temporales declaradas.
No puede utilizar IMPORT y LOAD para llenar tablas temporales declaradas.
Puede, aunque con restricciones, crear ndices para tablas temporales
declaradas. Adems, puede ejecutar RUNSTATS contra una tabla temporal
declarada para actualizar estadsticas correspondientes a la tabla temporal
declarada y sus ndices.
v DECLARE GLOBAL TEMPORARY TABLE sentencia en el manual
v tbtemp.sqc -- How to use a declared temporary table (C)
v TbTemp.java -- How to use Declared Temporary Table (JDBC)
Puntos de rescate y transacciones
Las secciones siguientes describen los puntos de rescate y cmo utilizarlos
para gestionar transacciones.
Gestin de transacciones con puntos de rescate
Los puntos de rescate de aplicaciones proporcionan control sobre el trabajo
realizado por un subconjunto de sentencias de SQL en una transaccin o
unidad de trabajo. Dentro de la aplicacin puede definir un punto de rescate
y luego liberarlo o retrotraer el trabajo realizado desde que defini el punto
de rescate. Puede utilizar tantos puntos de rescate como necesite dentro de
una sola transaccin; sin embargo, no puede anidar puntos de rescate. El
siguiente ejemplo muestra el uso de dos puntos de rescate dentro de una sola
transaccin para controlar el comportamiento de una aplicacin:
Ejemplo de un pedido que utiliza puntos de rescate de la aplicacin:
INSERT INTO order ...
INSERT INTO order_item ... lamp
-- definir el primer punto de rescate de la transaccin
SAVEPOINT before_radio ON ROLLBACK RETAIN CURSORS
INSERT INTO order_item ... Radio
INSERT INTO order_item ... Power Cord
-- Pseudo-SQL:
IF SQLSTATE = "No Power Cord"
ROLLBACK TO SAVEPOINT before_radio
RELEASE SAVEPOINT before_radio
-- definir el segundo punto de rescate de la transaccin
SAVEPOINT before_checkout ON ROLLBACK RETAIN CURSORS
INSERT INTO order ... Approval
-- Pseudo-SQL:
IF SQLSTATE = "No approval"
ROLLBACK TO SAVEPOINT before_checkout
-- confirmar la transaccin, lo cual libera el punto de rescate
COMMIT
En el ejemplo anterior, el primer punto de rescate hace cumplir una
dependencia entre dos objetos de datos en los que la dependencia no es
intrnseca de los propios objetos. No utilizara integridad referencial para
describir la relacin anterior entre radios y cables de alimentacin (power
cords) puesto que un objeto puede existir sin el otro. Sin embargo, no desea
distribuir al cliente la radio sin un cable de alimentacin. Tampoco desea
cancelar el pedido de la lmpara (lamp) retrotrayendo la transaccin entera
porque no hay cables de alimentacin para la radio. Los puntos de rescate de
la aplicacin proporcionan el control granular que necesita para completar
este pedido.
Cuando emite una sentencia ROLLBACK TO SAVEPOINT, el punto de rescate
correspondiente no se libera automticamente. Las siguientes sentencias de
SQL se asocian con este punto de rescate hasta que este se libera de forma
explcita con una sentencia RELEASE SAVEPOINT o de forma implcita
finalizando la transaccin o unidad de trabajo. Esto significa que puede emitir
varias sentencias ROLLBACK TO SAVEPOINT para un solo punto de rescate.
Los puntos de rescate le ofrecen un mejor rendimiento y un diseo de
aplicacin ms limpio que la utilizacin de varias sentencias COMMIT y
ROLLBACK. Cuando emite una sentencia COMMIT, DB2 debe realizar un
trabajo adicional para confirmar la transaccin actual e iniciar una nueva
transaccin. Los puntos de rescate le permiten dividir una transaccin en
unidades de menor tamao o pasos sin el proceso general aadido de varias
sentencias COMMIT. El siguiente ejemplo muestra el deterioro del
rendimiento que se produce si se utilizan varias transacciones en lugar de
puntos de rescate:
Ejemplo de un pedido que utiliza varias transacciones::
-- confirmar transaccin actual, iniciar transaccin nueva
COMMIT
-- Pseudo-SQL:
-- retrotraer transaccin actual, iniciar transaccin nueva
ROLLBACK
ELSE
COMMIT
-- Pseudo-SQL:
-- retrotraer transaccin actual, iniciar transaccin nueva
ROLLBACK
ELSE
COMMIT
Otro inconveniente de utilizar varios puntos de confirmacin es que se puede
confirmar un objeto, con lo cual estar visible para otras aplicaciones antes de
que haya finalizado por completo. En el segundo ejemplo, el pedido est
disponible para otro usuario antes de que se hayan aadido todos los
elementos y, lo que es peor, antes de que se haya aprobado. El uso de puntos
de rescate de la aplicacin evita esta exposicin a datos sucios mientras se
ofrece un control granular sobre una operacin.
v tbsavept.sqc -- How to use external savepoints (C)
Comparacin entre puntos de rescate de la aplicacin y bloques de SQL
compuesto
Los puntos de rescate ofrecen las siguientes ventajas sobre los bloques de SQL
compuesto:
v Control mejorado de transacciones
v Menor contencin de bloqueo
v Integracin mejorada con la lgica de la aplicacin
Los bloques de SQL compuesto pueden ser de tipo ATOMIC o NOT ATOMIC.
Si una sentencia dentro de un bloque de SQL compuesto de tipo ATOMIC
falla, el bloque de SQL compuesto entero se retrotrae. Si una sentencia dentro
de un bloque de SQL compuesto de tipo NOT ATOMIC falla, la aplicacin
controla la confirmacin o retrotraccin de la aplicacin, incluido el bloque de
SQL compuesto entero. En comparacin, si una sentencia dentro del mbito
de un punto de rescate falla, la aplicacin puede retrotraer todas las
sentencias del mbito del punto de rescate pero confirmar el trabajo realizado
por sentencias externas al mbito del punto de rescate. Esta opcin se ilustra
en el siguiente ejemplo. Si el trabajo del punto de rescate se retrotrae, el
trabajo de las dos sentencias INSERT anteriores al punto de rescate se
confirma. Como alternativa, la aplicacin puede confirmar el trabajo realizado
por todas las sentencias de la transaccin, incluidas las sentencias dentro del
mbito del punto de rescate.
Ejemplo de un pedido que utiliza puntos de rescate de la aplicacin:
-- Pseudo-SQL:
RELEASE SAVEPOINT before_radio
-- definir el segundo punto de rescate de la transaccin
SAVEPOINT before_checkout ON ROLLBACK RETAIN CURSORS
-- Pseudo-SQL:
ROLLBACK TO SAVEPOINT before_checkout
-- confirmar la transaccin, lo cual libera el punto de rescate
COMMIT
Cuando emite un bloque de SQL compuesto, DB2 adquiere simultneamente
los bloqueos necesarios para el bloque completo de sentencias de SQL
compuesto. Cuando define un punto de rescate de la aplicacin, DB2 adquiere
bloqueos a medida que se emite cada sentencia en el mbito del punto de
rescate. Este comportamiento de bloqueo de puntos de rescate puede llevar a
una contencin de bloqueo significativamente menor que la que ocasionan los
bloques de SQL compuesto, de modo que, a menos que la aplicacin necesite
que el bloqueo lo realicen las sentencias de SQL compuesto, puede ser
aconsejable utilizar puntos de rescate.
Los bloques de SQL compuesto ejecutan un conjunto completo de sentencias
como una sola sentencia. Una aplicacin no puede utilizar funciones o
estructuras de control para aadir sentencias a un bloque de SQL compuesto.
En comparacin, cuando define un punto de rescate de la aplicacin, esta
puede emitir sentencias de SQL dentro del mbito del punto de rescate
realizando llamadas a otros mtodos o funciones de aplicacin, a travs de
estructuras de control como bucles while o con sentencias de SQL dinmico.
Los puntos de rescate de la aplicacin le ofrecen libertad para integrar las
sentencias de SQL con la lgica de la aplicacin de forma intuitiva.
Por ejemplo, en el ejemplo siguiente la aplicacin define un punto de rescate y
emite dos sentencias INSERT dentro del mbito del punto de rescate. La
aplicacin utiliza una sentencia IF que, cuando es cierta, llama a la funcin
add_batteries(). La funcin add_batteries() emite un sentencia de SQL que en
este contexto se incluye dentro del mbito del punto de rescate. Finalmente, la
aplicacin retrotrae el trabajo realizado dentro del punto de rescate (incluida
la sentencia de SQL que ha emitido la funcin add_batteries()) o confirma el
trabajo realizado en la transaccin entera:
Ejemplo de integracin de puntos de rescate y sentencias de SQL dentro de
la lgica de la aplicacin:
void add_batteries()
{
-- el punto de rescate definido en main() controla
-- el trabajo realizado por la siguiente sentencia
INSERT INTO order_item ... Batteries
}
void main(int argc, char[] *argv)
{
if (strcmp(Radio..power_source(), "AC/DC"))
{
add_batteries();
}
-- Pseudo-SQL:
COMMIT
}
Sentencias de SQL para crear y controlar puntos de rescate
Las siguientes sentencias de SQL le permiten crear y controlar puntos de
rescate:
SAVEPOINT
Para definir un punto de rescate, emita una sentencia de SQL
SAVEPOINT. Para que el cdigo quede ms claro, puede elegir un
nombre significativo para el punto de rescate. Por ejemplo:
SAVEPOINT savepoint1 ON ROLLBACK RETAIN CURSORS
RELEASE SAVEPOINT
Para liberar un punto de rescate, emita una sentencia de SQL
RELEASE SAVEPOINT. Si no libera de forma explcita un punto de
rescate con una sentencia de SQL RELEASE SAVEPOINT, se libera al
final de la transaccin. Por ejemplo:
RELEASE SAVEPOINT savepoint1
Para retrotraer un punto de rescate, emita una sentencia de SQL
ROLLBACK TO SAVEPOINT. Por ejemplo:
v ROLLBACK sentencia en el manual Consulta de SQL, Volumen 2
v RELEASE SAVEPOINT sentencia en el manual Consulta de SQL, Volumen
2
v SAVEPOINT sentencia en el manual Consulta de SQL, Volumen 2
v tbsavept.sqc -- How to use external savepoints (C)
Restricciones sobre el uso de puntos de rescate
DB2 Universal Database impone las siguientes restricciones en el uso de
puntos de rescate en aplicaciones:
SQL compuesto atmico
DB2 no le permite utilizar puntos de rescate dentro de SQL
compuesto atmico. No puede utilizar SQL compuesto atmico dentro
de un punto de rescate.
Puntos de rescate anidados
DB2 no da soporte al uso de un punto de rescate dentro de otro punto
de rescate.
Activadores
DB2 no da soporte al uso de puntos de rescate en activadores.
sentencia SET INTEGRITY
Dentro de un punto de rescate, DB2 trata las sentencias SET
INTEGRITY como sentencias de DDL.
v Puntos de rescate y Lenguaje de definicin de datos (DDL) en la pgina
514
Puntos de rescate y Lenguaje de definicin de datos (DDL)
DB2 le permite incluir sentencias de DDL dentro de un punto de rescate. Si la
aplicacin libera satisfactoriamente un punto de rescate que ejecuta sentencias
de DDL, la aplicacin puede continuar utilizando los objetos SQL creados por
DDL. Sin embargo, si la aplicacin emite una sentencia ROLLBACK TO
SAVEPOINT para un punto de rescate que ejecuta sentencias de DDL, DB2
marca los cursores que dependen de los efectos de dichas sentencias de DDL
como no vlidos.
En el siguiente ejemplo, la aplicacin intenta captar desde de los tres cursores
abiertos anteriormente despus de emitir una sentencia ROLLBACK TO
SAVEPOINT:
SAVEPOINT savepoint_name;
PREPARE s1 FROM 'SELECT FROM t1';
--emitir sentencia de DDL para t1
ALTER TABLE t1 ADD COLUMN...
--emitir sentencia de DDL para t3
ALTER TABLE t3 ADD COLUMN...
OPEN c1 USING s1;
OPEN c2 USING s2;
OPEN c3 USING s3;
FETCH c1; --no vlido (SQLCODE 910)
FETCH c2; --satisfactorio
FETCH c3; --no vlido (SQLCODE 910)
En la sentencia ROLLBACK TO SAVEPOINT, DB2 marca los cursores c1 y
c3 como no vlidos porque las sentencias de DDL dentro del punto de
rescate han manipulado los objetos SQL de los que dependen. Sin embargo,
una sentencia FETCH que utiliza el cursor c2 en el ejemplo es satisfactoria
despus de la sentencia ROLLBACK TO SAVEPOINT.
Puede emitir una sentencia CLOSE para cerrar los cursores no vlidos. Si
emite una sentencia FETCH contra un cursor no vlido, DB2 devuelve
SQLCODE 910. Si emite una sentencia OPEN contra un cursor no vlido,
DB2 devuelve SQLCODE 502. Si emite una sentencia UPDATE o DELETE
WHERE CURRENT OF contra un cursor no vlido, DB2 devuelve SQLCODE
910.
Dentro de los puntos de rescate, DB2 trata las tablas con la propiedad NOT
LOGGED INITIALLY y las tablas temporales del siguiente modo:
Tablas NOT LOGGED INITIALLY
Dentro de un punto de rescate, puede crear una tabla con la
propiedad NOT LOGGED INITIALLY o modificar una tabla para que
tenga la propiedad NOT LOGGED INITIALLY. Sin embargo, para
estos puntos de rescate DB2 trata las sentencias ROLLBACK TO
SAVEPOINT como sentencias ROLLBACK WORK y retrotrae la
transaccin entera.
DECLARE TEMPORARY TABLE dentro del punto de rescate
Si se declara una tabla temporal dentro de un punto de rescate, una
sentencia ROLLBACK TO SAVEPOINT elimina la tabla temporal.
DECLARE TEMPORARY TABLE fuera del punto de rescate
Si se declara una tabla temporal fuera de un punto de rescate, una
sentencia ROLLBACK TO SAVEPOINT no elimina la tabla temporal.
Puntos de rescate e inserciones en almacenamiento intermedio
Para mejorar el rendimiento de las aplicaciones DB2, puede utilizar
inserciones en almacenamiento intermedio en las aplicaciones, precompilando
o vinculando con la opcin INSERT BUF. Si la aplicacin aprovecha tanto
inserciones en almacenamiento como puntos de rescate, DB2 desecha el
almacenamiento intermedio antes de ejecutar sentencias SAVEPOINT,
RELEASE SAVEPOINT o ROLLBACK TO SAVEPOINT.
v Inserciones en almacenamiento intermedio en entornos de bases de datos
particionadas en la pgina 480
Puntos de rescate y bloqueo de cursor
Si la aplicacin utiliza puntos de rescate, considere la posibilidad de evitar el
bloqueo de cursor, precompilando o vinculando la aplicacin con la opcin de
precompilacin BLOCKING NO. Aunque los cursores de bloqueo pueden
mejorar el rendimiento de la aplicacin al realizar una captacin previa de
varias filas, es posible que los datos que devuelve una aplicacin que utiliza
puntos de rescate y cursores de bloqueo no reflejen los datos que se han
confirmado en la base de datos.
Si no precompila la aplicacin con la opcin BLOCKING NO, y la aplicacin
emite una sentencia FETCH despus de que se haya producido una operacin
ROLLBACK TO SAVEPOINT, es posible que la sentencia FETCH recupere
datos suprimidos. Por ejemplo, supongamos que la aplicacin que contiene el
siguiente SQL se precompila sin la opcin BLOCKING NO:
CREATE TABLE t1(c1 INTEGER);
DECLARE CURSOR c1 AS 'SELECT c1 FROM t1 ORDER BY c1';
INSERT INTO t1 VALUES (1);
SAVEPOINT showFetchDelete;
OPEN CURSOR c1;
FETCH c1; --obtener primer valor y bloque de cursor
ALTER TABLE t1... --aadir restriccin
ROLLBACK TO SAVEPOINT;
FETCH c1; --recupera segundo valor de bloque de cursor
Cuando la aplicacin emite la primera sentencia FETCH en la tabla t1, el
servidor DB2 enva un bloque de valores de columna (1, 2 y 3) a la aplicacin
cliente. El cliente almacena localmente estos valores de columna. Cuando la
aplicacin emite la sentencia ROLLBACK TO SAVEPOINT SQL, los valores de
columna '2' y '3' se suprimen de la tabla. Despus de la sentencia ROLLBACK
TO SAVEPOINT, la siguiente sentencia FETCH de la tabla devuelve el valor
de columna '2', aunque dicho valor ya no existe en la tabla. La aplicacin
recibe este valor porque aprovecha la opcin de bloqueo de cursor para
mejorar el rendimiento y accede a los datos que se han almacenado
localmente.
Puntos de rescate y gestores de transacciones que cumplen con XA
Si hay algn punto de rescate activo en una aplicacin cuando un gestor de
transacciones que cumple con XA emite una peticin XA_END, DB2 emite
una sentencia RELEASE SAVEPOINT.
Transmisin de grandes volmenes de datos a travs de una red
Puede combinar las tcnicas de procedimientos almacenados y el bloqueo de
filas para mejorar significativamente el rendimiento de las aplicaciones que
necesitan pasar grandes cantidades de datos a travs de una red.
Las aplicaciones que pasan matrices, grandes cantidades de datos o paquetes
de datos a travs de la red pueden pasar los datos en bloques utilizando
como mecanismo de transporte la estructura de datos SQLDA o variables del
lenguaje principal. Esta tcnica es sumamente potente en los lenguajes
principales que soportan estructuras.
Tanto una aplicacin cliente como un procedimiento de servidor pueden pasar
los datos a travs de la red. Los datos se pueden pasar utilizando uno de los
tipos de datos siguientes:
v VARCHAR
v LONG VARCHAR
v CLOB
v BLOB
Los datos tambin se pueden pasar utilizando uno de los tipos de grficos
siguientes:
v VARGRAPHIC
v LONG VARGRAPHIC
v DBCLOB
Nota: cuando utilice esta tcnica, asegrese de considerar la posibilidad de
convertir los caracteres. Si est pasando datos con uno de los tipos de
datos de serie de caracteres, como por ejemplo VARCHAR, LONG
VARCHAR o CLOB, o tipo de datos grficos, como por ejemplo
VARGRAPHIC, LONG VARGRAPHIC o DBCLOB, y si la pgina de
cdigos de la aplicacin no es la misma que la de la base de datos, los
datos que no sean de tipo carcter se convertirn como si lo fueran.
Para evitar la conversin de caracteres, debe pasar los datos en una
variable con el tipo de datos BLOB.
436
v Specifying row blocking to reduce overhead en el manual Administration
Guide: Performance
Parte 6. Apndices
Apndice A. Sentencias de SQL soportadas
La tabla siguiente:
v Contiene todas las sentencias de SQL soportadas en DB2 Universal
Database para Linux, UNIX y sistemas operativos Windows
v Indica (mediante una 'X') si se pueden ejecutar dinmicamente
v Indica (mediante una 'X') si el procesador de lnea de mandatos (CLP) las
soporta
v Indica (mediante una 'X' o un nombre de funcin de la CLI de DB2) si se
puede ejecutar la sentencia utilizando la Interfaz a nivel de llamada de DB2
(CLI de DB2)
v Indica (mediante una 'X') si se puede ejecutar la sentencia en un
procedimiento de SQL
Tabla 37. Sentencias de SQL (DB2 Universal Database)
Sentencia de SQL Dinmico
1
Procesador
de lnea
de
mandatos
(CLP)
Interfaz de nivel de llamada
3
(CLI)
Procedimiento
SQL
ALLOCATE CURSOR X
Sentencia de asignacin X
ASSOCIATE LOCATORS X
ALTER { BUFFERPOOL,
NICKNAME,
10
NODEGROUP,
SERVER,
10
TABLE,
TABLESPACE, USER
MAPPING,
10
TYPE, VIEW }
X X X
BEGIN DECLARE SECTION
2
CALL X
9
X
4
X
Sentencia CASE X
CLOSE X SQLCloseCursor(),
SQLFreeStmt()
X
COMMENT ON X X X X
COMMIT X X SQLEndTran(), SQLTransact() X
SQL compuesto (incorporado) X
4
Sentencia compuesta X
Tabla 37. Sentencias de SQL (DB2 Universal Database) (continuacin)
1
Procesador
de lnea
de
mandatos
(CLP)
3
(CLI)
Procedimiento
SQL
CONNECT (Tipo 1) X SQLBrowseConnect(),
SQLConnect(),
SQLDriverConnect()
CONNECT (Tipo 2) X SQLBrowseConnect(),
SQLConnect(),
SQLDriverConnect()
CREATE { ALIAS,
BUFFERPOOL,
DISTINCT TYPE,
EVENT MONITOR,
FUNCTION, FUNCTION
MAPPING,
10
INDEX, INDEX
EXTENSION, METHOD,
NICKNAME,
10
NODEGROUP,
PROCEDURE, SCHEMA,
SERVER, TABLE, TABLESPACE,
TRANSFORM, TYPE
MAPPING,
10
TRIGGER, USER
MAPPING,
10
TYPE, VIEW,
WRAPPER
10
}
X X X X
11
DECLARE CURSOR
2
X SQLAllocStmt() X
DECLARE GLOBAL
TEMPORARY TABLE
X X X X
DELETE X X X X
DESCRIBE
8
X SQLColAttributes(),
SQLDescribeCol(),
SQLDescribParam()
6
DISCONNECT X SQLDisconnect()
DROP X X X X
11
END DECLARE SECTION
2
EXECUTE SQLExecute() X
EXECUTE IMMEDIATE SQLExecDirect() X
EXPLAIN X X X X
FETCH X SQLExtendedFetch() ,
SQLFetch(), SQLFetchScroll()
X
FLUSH EVENT MONITOR X X X
1
Procesador
de lnea
de
mandatos
(CLP)
3
(CLI)
Procedimiento
SQL
sentencia FOR X
FREE LOCATOR X
4
X
GET DIAGNOSTICS X
Sentencia GOTO X
GRANT X X X X
Sentencia IF X
INCLUDE
2
INSERT X X X X
ITERATE X
Sentencia LEAVE X
LOCK TABLE X X X X
Sentencia LOOP X
OPEN X SQLExecute(), SQLExecDirect() X
PREPARE SQLPrepare() X
REFRESH TABLE X X X
RELEASE X X
RELEASE SAVEPOINT X X X X
RENAME TABLE X X X
RENAME TABLESPACE X X X
Sentencia REPEAT X
Sentencia RESIGNAL X
Sentencia RETURN X
REVOKE X X X
ROLLBACK X X SQLEndTran(), SQLTransact() X
SAVEPOINT X X X X
Sentencia-select X X X X
SELECT INTO X
SET CONNECTION X SQLSetConnection()
SET CURRENT DEFAULT
TRANSFORM GROUP
X X X X
Apndice A. Sentencias de SQL soportadas 523
1
Procesador
de lnea
de
mandatos
(CLP)
3
(CLI)
Procedimiento
SQL
SET CURRENT DEGREE X X X X
SET CURRENT EXPLAIN
MODE
X X X, SQLSetConnectAttr() X
SET CURRENT EXPLAIN
SNAPSHOT
X X X, SQLSetConnectAttr() X
SET CURRENT PACKAGESET
SET CURRENT QUERY
OPTIMIZATION
X X X X
SET CURRENT REFRESH AGE X X X X
SET EVENT MONITOR STATE X X X X
SET INTEGRITY X X X
SET PASSTHRU
10
X X X X
SET PATH X X X X
SET SCHEMA X X X X
SET SERVER OPTION
10
X X X X
Variable de transicin SET
5
X X X X
Sentencia SIGNAL X
SIGNAL SQLSTATE
5
X X X
UPDATE X X X X
VALUES INTO X
WHENEVER
2
Sentencia WHILE X
1
Procesador
de lnea
de
mandatos
(CLP)
3
(CLI)
Procedimiento
SQL
Notas:
1. Puede codificar todas las sentencias de esta lista como SQL esttico, pero slo las marcadas con X
como SQL dinmico.
2. No puede ejecutar esta sentencia.
3. Una X indica que puede ejecutar esta sentencia utilizando SQLExecDirect() o SQLPrepare() y
SQLExecute(). Si hay una funcin de CLI de DB2 equivalente, se lista el nombre de la funcin.
4. Aunque esta sentencia no es dinmica, con CLI de DB2 puede especificar esta sentencia cuando
llame a SQLExecDirect() o a SQLPrepare() y a SQLExecute().
5. Slo puede utilizarlo dentro de sentencias CREATE TRIGGER.
6. Slo puede utilizar la sentencia de SQL DESCRIBE para describir salida, mientras que con CLI de
DB2 tambin puede describir entrada (mediante la funcin SQLDescribeParam()).
7. Slo puede utilizar la sentencia de SQL FETCH para captar filas de una en una en una direccin,
mientras que con las funciones de CLI de DB2 SQLExtendedFetch() y SQLFetchScroll() puede
captar en matrices. Adems, puede captar en cualquier direccin y en cualquier posicin del
conjunto de resultados.
8. La sentencia de SQL DESCRIBE tiene una sintaxis diferente de la del mandato CLP DESCRIBE.
9. Cuando se emite CALL desde el procesador de lnea de mandatos, slo ciertos procedimientos y sus
respectivos parmetros reciben soporte.
10. La sentencia slo recibe soporte para servidores de bases de datos federados.
11. Los procedimientos de SQL slo pueden emitir las sentencias CREATE y DROP para ndices, tablas
y vistas.
v Administracin de los archivos JAR en el servidor de bases de datos en el
servidor
Apndice A. Sentencias de SQL soportadas 525
Apndice B. Programacin en un entorno de sistema
principal o iSeries
Aplicaciones en entornos de sistema
principal o iSeries. . . . . . . . . . 527
Lenguaje de definicin de datos en entornos
de sistema principal e iSeries . . . . . . 529
Lenguaje de manipulacin de datos en
entornos de sistema principal e iSeries . . . 529
Lenguaje de control de datos en entornos de
sistema principal e iSeries . . . . . . . 530
Gestin de conexiones de bases de datos con
DB2 Connect . . . . . . . . . . . 531
Proceso de peticiones de interrupcin . . . 532
Atributos de paquete, PREP y BIND . . . 532
Diferencias de atributos de paquete entre
IBM . . . . . . . . . . . . . 532
Opcin CNULREQD BIND para series C
terminadas en nulo . . . . . . . . 533
Variables SQLCODE y SQLSTATE
autnomas . . . . . . . . . . . 533
Niveles de aislamiento soportados por
DB2 Connect . . . . . . . . . . 534
rdenes de clasificacin definidos por el
usuario . . . . . . . . . . . . . 535
Diferencias en la integridad referencial entre
IBM . . . . . . . . . . . . . . 535
Bloqueo y portabilidad de aplicaciones. . . 536
Diferencias en SQLCODE y SQLSTATE entre
IBM . . . . . . . . . . . . . . 536
Diferencias en el catlogo del sistema entre
IBM . . . . . . . . . . . . . . 537
Desbordamientos por conversin numrica
en asignaciones de recuperacin . . . . . 537
Procedimientos almacenados en entornos de
sistema principal o iSeries . . . . . . . 537
Soporte de DB2 Connect de SQL compuesto 539
Actualizacin mltiple con DB2 Connect . . 539
principal e iSeries soportadas por DB2
Connect . . . . . . . . . . . . . 541
principal e iSeries rechazadas por DB2
Connect . . . . . . . . . . . . . 541
Aplicaciones en entornos de sistema principal o iSeries
DB2 Connect permite que un programa de aplicacin acceda a datos de bases
de datos DB2 en servidores System/390, zSeries e iSeries. Por ejemplo, una
aplicacin que se ejecute en Windows puede acceder a datos de una base de
datos DB2 Universal Database para OS/390 y z/OS. Puede crear nuevas
aplicaciones o modificar las aplicaciones existentes para que se ejecuten en un
entorno de sistema principal o iSeries. Tambin es posible desarrollar
aplicaciones en un entorno y trasladarlas a otro.
DB2 Connect le permite utilizar las API siguientes con productos de base de
datos de sistema principal, como por ejemplo DB2 Universal Database para
OS/390 y z/OS, siempre que dichos productos soporten el elemento:
v SQL incorporado, tanto esttico como dinmico
v La Interfaz a nivel de llamada de DB2
v La API ODBC de Microsoft
v JDBC
Algunas sentencias de SQL difieren segn los productos de base de datos
relacional. Se puede encontrar con sentencias de SQL que:
v Sean iguales para todos los productos de base de datos que utilice,
independientemente de los estndares.
v Estn disponibles en todos los productos de bases de datos relacionales de
IBM (vea la informacin de consulta de SQL para obtener ms detalles).
v Sean exclusivas para el sistema de base de datos al que acceda.
La portabilidad de las sentencias de SQL de las dos primeras categoras es
muy grande, pero las de la tercera categora habr que cambiarlas antes. En
general, la portabilidad de las sentencias de SQL en Lenguaje de definicin de
datos (Data Definition Language - DDL) no es tan grande como la de las que
estn en Lenguaje de manipulacin de datos (Data Manipulation Language -
DML).
DB2 Connect acepta algunas sentencias de SQL que DB2 Universal Database
no soporta. DB2 Connect pasa estas sentencias al servidor de sistema principal
o iSeries. Para obtener informacin sobre los lmites en las distintas
plataformas, como por ejemplo la longitud mxima de columna, consulte el
tema sobre lmites de SQL.
Si traslada una aplicacin CICS desde OS/390 o VSE para que se ejecute bajo
otro producto CICS (por ejemplo, CICS para AIX), sta tambin puede acceder
a la base de datos OS/390 o VSE utilizando DB2 Connect. Consulte los
manuales CICS/6000 Application Programming Guide y CICS Customization and
Operation para obtener ms detalles.
Nota: puede utilizar DB2 Connect con una base de datos DB2 Universal
Database Versin 8, aunque slo necesita un cliente DB2. La mayora de
puntos de incompatibilidad relacionados en los temas siguientes no se
producirn si utiliza DB2 Connect para una base de datos DB2
Universal Database Versin 8, excepto en aquellos casos en que exista
una restriccin debida a una limitacin del propio DB2 Connect.
v Creacin de la base de datos sample en servidores de sistema principal o
AS/400 e iSeries en el manual Gua de desarrollo de aplicaciones: Creacin y
ejecucin de aplicaciones
v Lmites de SQL en el manual Consulta de SQL, Volumen 1
Lenguaje de definicin de datos en entornos de sistema principal e iSeries
Las sentencias DDL difieren segn el producto de base de datos IBM, puesto
que el almacenamiento se maneja de forma diferente en los distintos sistemas.
En los sistemas de servidor de sistema principal o iSeries, pueden existir
varios pasos entre el diseo de una base de datos y la emisin de una
sentencia CREATE TABLE. Por ejemplo, una serie de sentencias pueden
convertir el diseo de objetos lgicos en la representacin fsica de dichos
objetos en el almacenamiento.
El precompilador pasa muchas de estas sentencias DDL al servidor de sistema
principal o iSeries cuando el usuario precompila para una base de datos de
servidor de sistema principal o iSeries. Las mismas sentencias no se
precompilaran para una base de datos del sistema en que se est ejecutando
la aplicacin. Por ejemplo, en una aplicacin Windows la sentencia CREATE
STORGROUP se precompilara satisfactoriamente para una base de datos DB2
Universal Database para OS/390 y z/OS pero no para una base de datos DB2
para Windows.
Lenguaje de manipulacin de datos en entornos de sistema principal e iSeries
En general, la portabilidad de las sentencias de DML es muy grande. Las
sentencias SELECT, INSERT, UPDATE y DELETE son parecidas en los
distintos productos de base de datos relacional de IBM. La mayora de
aplicaciones utilizan, principalmente, sentencias de SQL en DML que el
programa DB2 Connect soporta.
A continuacin se muestran algunas consideraciones que se deben tener en
cuenta cuando se utilice DML en entornos de sistema principal e iSeries:
v Tipos de datos numricos
Cuando se transfieran datos numricos a DB2 Universal Database, el tipo
de datos puede cambiar. Los SQLTYPE numricos y decimales con zona,
soportados por OS/400, se convierten en SQLTYPE decimales fijos
(empaquetados).
v Datos de bytes mixtos
Los datos de bytes mixtos pueden consistir en caracteres de un juego de
caracteres de cdigo UNIX ampliado (EUC), un juego de caracteres de
doble byte (DBCS) y un juego de caracteres de un solo byte (SBCS) en la
misma columna. En los sistemas que almacenan los datos en EBCDIC
(OS/390, z/OS, OS/400, VSE y VM), los caracteres de desplazamiento a
teclado ideogrfico y de desplazamiento a teclado estndar marcan el
comienzo y el final de los datos de doble byte. En los sistemas que
Apndice B. Programacin en un entorno de sistema principal o iSeries 529
almacenan los datos en ASCII (como UNIX), no se requieren caracteres de
desplazamiento a teclado ideogrfico ni de desplazamiento a teclado
estndar.
Si la aplicacin transfiere datos de bytes mixtos desde un sistema ASCII a
un sistema EBCDIC, asegrese de que haya suficiente espacio para los
caracteres de desplazamiento de teclado. Para cada cambio de datos SBCS a
DBCS, aada 2 bytes a la longitud de los datos. Para mejorar la
portabilidad, utilice series de longitud variable en las aplicaciones que usen
datos de bytes mixtos.
v Campos largos
Los campos largos (series que contienen ms de 254 caracteres) se manejan
de forma distinta en los diferentes sistemas. Un servidor de sistema
principal o iSeries slo puede soportar un subconjunto de funciones
escalares para los campos largos; por ejemplo, DB2 Universal Database para
OS/390 y z/OS slo admite las funciones LENGTH y SUBSTR para los
campos largos. Asimismo, un servidor de sistema principal o iSeries puede
necesitar un manejo distinto de determinadas sentencias de SQL; por
ejemplo, DB2 para VSE y VM requiere que con la sentencia INSERT slo se
utilice una variable del lenguaje principal, SQLDA, o un valor NULL.
v Tipo de datos de objetos grandes
DB2 Connect soporta el tipo de datos LOB.
v Tipos definidos por el usuario
DB2 Connect slo soporta los tipos diferenciados definidos por el usuario.
Los tipos estructurados, tambin denominados tipos de datos abstractos, no
reciben soporte de DB2 Connect.
v Tipo de datos ROWID
DB2 Connect maneja el tipo de datos ROWID como VARCHAR para datos
de bits.
v Tipo de datos BIGINT
DB2 Connect soporta enteros de ocho bytes (64 bits). El tipo de datos
interno BIGINT se utiliza para proporcionar soporte de cardinalidad de
bases de datos muy grandes y mantener a la vez la precisin de los datos.
Lenguaje de control de datos en entornos de sistema principal e iSeries
Cada sistema de gestin de bases de datos relacionales de IBM proporciona
distintos niveles de granularidad para las sentencias GRANT y REVOKE de
SQL. Para verificar las sentencias de SQL adecuadas a utilizar para cada
sistema de gestin de bases de datos, consulte las publicaciones especficas del
producto.
Gestin de conexiones de bases de datos con DB2 Connect
DB2 Connect soporta las versiones CONNECT TO y CONNECT RESET de la
sentencia CONNECT, as como CONNECT sin ningn parmetro. Si una
aplicacin llama a una sentencia de SQL sin antes ejecutar una sentencia
CONNECT TO explcita, se realiza una conexin implcita del servidor de
aplicaciones por omisin (si hay alguno definido).
Cuando se conecta con una base de datos, en el campo SQLERRP de la
SQLCA se devuelve informacin que identifica el sistema de gestin de bases
de datos relacionales. Si el servidor de aplicaciones es una base de datos
relacional de IBM, los tres primeros bytes de SQLERRP contienen uno de los
valores siguientes:
DSN DB2 Universal Database para OS/390 y z/OS
ARI DB2 para VSE y VM
QSQ DB2 UDB para iSeries
SQL DB2 Universal Database
Si se emite una sentencia CONNECT TO o CONNECT nula mientras se
utiliza DB2 Connect, el cdigo de territorio o smbolo de territorio del campo
SQLERRMC de la SQLCA se devuelve en blanco; el CCSID del servidor de
aplicaciones se devuelve en la seal de pgina de cdigos o de juego de
cdigos.
Puede realizar explcitamente una desconexin mediante la sentencia
CONNECT RESET (para la conexin de tipo 1), las sentencias RELEASE y
COMMIT (para la conexin de tipo 2) o la sentencia DISCONNECT (para
cualquier tipo de conexin, siempre que el entorno no sea de supervisor TP).
Nota: una aplicacin puede recibir diversos SQLCODE que indiquen errores y
seguir terminando normalmente; en este caso, DB2 Connect confirma
los datos. Si no desea que se confirmen, debe emitir un mandato
ROLLBACK.
El mandato FORCE permite desconectar de la base de datos usuarios
seleccionados o todos los usuarios. Este mandato se soporta para bases de
datos de servidor de sistema principal e iSeries; el usuario puede imponer una
desconexin de la estacin de trabajo DB2 Connect.
Proceso de peticiones de interrupcin
DB2 Connect maneja una peticin de interrupcin procedente de un cliente
DB2 de una de estas dos formas:
v Si aparece la palabra clave INTERRUPT_ENABLED en el campo PARMS de
la entrada del catlogo DCS, DB2 Connect eliminar la conexin con el
servidor de sistema principal o iSeries cuando reciba una peticin de
interrupcin. La prdida de conexin, al menos en servidores DB2 UDB
para OS/390 y z/OS, har que se interrumpa la peticin actual en el
servidor.
v Si no aparece la palabra clave INTERRUPT_ENABLED en el campo PARMS
de la entrada del catlogo DCS, las peticiones de interrupcin se pasan por
alto.
Atributos de paquete, PREP y BIND
Las secciones siguientes describen las diferencias en los atributos de paquete
entre los sistemas de bases de datos relacionales de IBM y las consideraciones
a tener en cuenta al utilizar los mandatos PREPCOMPILE y BIND.
Diferencias de atributos de paquete entre sistemas de bases de datos
relacionales de IBM
Un paquete tiene los atributos siguientes:
ID de coleccin
ID del paquete. Se puede especificar en el mandato PREP.
Propietario
ID de autorizacin del propietario del paquete. Se puede especificar
en los mandatos PREP o BIND.
Creador
Nombre del usuario que enlaza lgicamente el paquete.
Calificador
Calificador implcito de los objetos del paquete. Se puede especificar
en los mandatos PREP o BIND.
Cada sistema de servidor de sistema principal o iSeries tiene limitaciones en
el uso de estos atributos:
DB2 Universal Database para OS/390 y z/OS
Los cuatro atributos pueden ser diferentes. El uso de un calificador
distinto requiere privilegios de administracin especiales. Para obtener
ms informacin sobre las condiciones relativas al uso de estos
atributos, consulte la publicacin Command Reference para DB2
Universal Database para OS/390 y z/OS.
DB2 para VSE y VM
Todos los atributos deben ser idnticos. Si USER1 crea un archivo de
vinculacin (mediante PREP) y USER2 realiza la vinculacin real,
USER2 necesitar autorizacin DBA para realizar la vinculacin para
USER1. Para los atributos slo se utiliza el nombre de usuario de
USER1.
DB2 UDB para iSeries
El calificador indica el nombre de coleccin. La relacin entre
calificadores y propietario afecta al otorgamiento y a la revocacin de
privilegios sobre el objeto. El nombre de usuario que se registra es el
creador y propietario, a menos que se califique con un ID de
coleccin, en cuyo caso el ID de coleccin es el propietario. El ID de
coleccin debe existir antes de que se pueda utilizar como calificador.
Los cuatro atributos pueden ser diferentes. El uso de un propietario
distinto requiere autorizacin de administracin y el enlazador debe
tener el privilegio CREATEIN sobre el esquema (si ya existe).
Opcin CNULREQD BIND para series C terminadas en nulo
La opcin de vinculacin CNULREQD altera temporalmente el manejo de las
series terminadas en nulo que se especifican utilizando la opcin
LANGLEVEL.
Por omisin, CNULREQD se establece en YES. Esto hace que las series
terminadas en nulo se interpreten segn los estndares MIA. Si se conecta a
un servidor DB2 Universal Database para OS/390 y z/OS, es altamente
recomendable establecer CNULREQD en YES. Es necesario enlazar
lgicamente las aplicaciones codificadas para los estndares SAA1 (respecto a
las series terminadas en nulo) con la opcin CNULREQD establecida en NO.
De no hacerlo, estas series se interpretarn segn los estndares MIA, aunque
se preparen estableciendo LANGLEVEL en SAA1.
v Series terminadas en nulo en C y C++ en la pgina 205
Variables SQLCODE y SQLSTATE autnomas
Las variables SQLCODE y SQLSTATE autnomas, definidas en ISO/ANS
SQL92, se soportan mediante la opcin de precompilacin LANGLEVEL
SQL92E. Durante la precompilacin se emitir un aviso SQL0020W, indicando
que no se soporta LANGLEVEL. Este aviso slo es aplicable a las
caractersticas relacionadas bajo el ttulo LANGLEVEL MIA, que es un
subconjunto de LANGLEVEL SQL92E.
Niveles de aislamiento soportados por DB2 Connect
DB2 Connect acepta los niveles de aislamiento siguientes cuando se prepara o
enlaza lgicamente una aplicacin:
RR Lectura repetible
RS Estabilidad de lectura
CS Estabilidad del cursor
UR Lectura no confirmada
NC Sin confirmacin
Los niveles de aislamiento se relacionan en orden de mayor a menor
proteccin. Si el servidor de sistema principal o iSeries no soporta el nivel de
aislamiento que se especifique, se utiliza el prximo nivel soportado superior.
La tabla siguiente muestra el resultado de cada nivel de aislamiento en cada
servidor de aplicaciones de sistema principal o iSeries.
Tabla 38. Niveles de aislamiento
DB2 Connect DB2 Universal
Database para
OS/390 y z/OS
DB2 para VSE y
VM
DB2 UDB para
iSeries
DB2 Universal
Database
RR RR RR nota 1 RR
RS nota 2 RR COMMIT(*ALL) RS
CS CS CS COMMIT(*CS) CS
UR nota 3 CS COMMIT(*CHG) UR
NC nota 4 nota 5 COMMIT(*NONE) UR
Notas:
1. En DB2 UDB no existe ninguna opcin COMMIT equivalente que coincida con RR. DB2 UDB
para iSeries da soporte a RR bloqueando la tabla entera.
2. Resultados en RR para la Versin 3.1, y resultados en RS para la Versin 4.1 con el APAR
PN75407 o para la Versin 5.1.
3. Resultados en CS para la Versin 3.1, y resultados en UR para la Versin 4.1 o para la Versin
5.1.
4. Resultados en CS para la Versin 3.1, y resultados en UR para la Versin 4.1 con el APAR
PN60988 o para la Versin 5.1.
5. El nivel de aislamiento NC no se soporta con DB2 para VSE y VM.
Con DB2 UDB, puede acceder a una tabla que no sea de diario si una
aplicacin se enlaza con un nivel de aislamiento de UR y el bloqueo
establecido en ALL, o si el nivel de aislamiento se establece en NC.
rdenes de clasificacin definidos por el usuario
Las diferencias entre EBCDIC y ASCII ocasionan diferencias en los rdenes de
clasificacin en los diversos productos de base de datos, y tambin afectan a
las clusulas ORDER BY y GROUP BY. Una manera de minimizar estas
diferencias consiste en crear un orden de clasificacin definido por el usuario
que imite el orden de clasificacin EBCDIC. Slo se puede especificar un
orden de clasificacin cuando se crea una base de datos nueva.
Nota: ahora, las tablas de bases de datos se pueden almacenar en formato
ASCII de DB2 Universal Database para OS/390 y z/OS. Esto permite
un intercambio ms rpido de los datos entre DB2 Connect y DB2
Universal Database para OS/390 y z/OS, y suprime la necesidad de
proporcionar procedimientos de campo, que en lugar de esto se
deberan utilizar para convertir los datos y volverlos a colocar en
secuencia.
Diferencias en la integridad referencial entre sistemas de bases de datos
relacionales de IBM
Los diferentes sistemas manejan las restricciones referenciales de forma
distinta:
DB2 Universal Database para OS/390 y z/OS
Para poder crear una clave fornea utilizando la clave primaria, antes
se debe crear un ndice sobre la clave primaria. Las tablas se pueden
hacer referencia a s mismas.
DB2 para VSE y VM
Se crea automticamente un ndice para una clave fornea. Las tablas
no se pueden hacer referencia a s mismas.
DB2 UDB para iSeries
Se crea automticamente un ndice para una clave fornea. Las tablas
se pueden hacer referencia a s mismas.
Para las bases de datos DB2 Universal Database, se crea
automticamente un ndice para una restriccin exclusiva, incluida
una clave primaria. Las tablas se pueden hacer referencia a s mismas.
Existen otras normas que varan con respecto a los niveles de cascada.
Bloqueo y portabilidad de aplicaciones
La manera en que el servidor de base de datos realiza un bloqueo puede
afectar a algunas aplicaciones. Por ejemplo, las aplicaciones diseadas en base
a un bloqueo de fila y aislamiento de la estabilidad del cursor no se pueden
trasladar directamente a sistemas que realicen un bloqueo de pgina. Debido a
estas diferencias fundamentales, es posible que haya que ajustar las
aplicaciones.
Los productos DB2 Universal Database para OS/390 y z/OS y DB2 Universal
Database ofrecen la posibilidad de marcar un tiempo de espera para un
bloqueo y enviar un cdigo de retorno de error a las aplicaciones que estn a
la espera.
Diferencias en SQLCODE y SQLSTATE entre sistemas de bases de datos
relacionales de IBM
Distintos productos de bases de datos relacionales de IBM no siempre
producen los mismos SQLCODE para errores similares. Puede manejar este
problema de una de dos maneras:
v Utilice el SQLSTATE en lugar del SQLCODE para un error determinado.
Los SQLSTATE tienen, aproximadamente, el mismo significado en los
productos de base de datos, y los productos producen SQLSTATE que
corresponden a los SQLCODE.
v Correlacione los SQLCODE de un sistema con los de otro.
Por omisin, DB2 Connect correlaciona los SQLCODE y los smbolos de
cada sistema de servidor de sistema principal o iSeries con el sistema DB2
Universal Database. El usuario puede especificar su propio archivo de
correlacin de SQLCODE si desea alterar temporalmente la correlacin por
omisin o est utilizando un servidor de base de datos que no dispone de
correlacin de SQLCODE (un servidor de base de datos no IBM). Tambin
puede desactivar la correlacin de SQLCODE.
v SQLCODE mapping en el manual DB2 Connect Users Guide
Diferencias en el catlogo del sistema entre sistemas de bases de datos
relacionales de IBM
Los catlogos del sistema varan en los distintos productos de base de datos
de IBM. Muchas de las diferencias se pueden enmascarar mediante el uso de
vistas. Para obtener informacin, consulte le documentacin correspondiente
al servidor de base de datos que utilice.
Las funciones de catlogo de la CLI evitan este problema presentando soporte
de la misma API y conjuntos de resultados para las consultas de catlogos en
la familia DB2.
v Catalog Functions for Querying System Catalog Information in CLI
Applications en el manual CLI Guide and Reference, Volume 1
Desbordamientos por conversin numrica en asignaciones de recuperacin
Los distintos productos de bases de datos relacionales de IBM pueden
manejar de forma distinta los desbordamientos por conversin numrica en
asignaciones de recuperacin. Por ejemplo, considere la operacin de traer
una columna de coma flotante a una variable del lenguaje principal de entero
desde DB2 Universal Database para OS/390 y z/OS y desde DB2 Universal
Database. Cuando se convierte el valor de coma flotante en un valor entero, se
puede producir un desbordamiento por conversin. Por omisin, DB2
Universal Database para OS/390 y z/OS devolver a la aplicacin un
SQLCODE de aviso y un valor nulo. En cambio, DB2 Universal Database
devolver un error de desbordamiento por conversin. Es recomendable que
las aplicaciones eviten los desbordamientos por conversin numrica en las
asignaciones de recuperacin y realicen el movimiento a variables del lenguaje
principal del tamao adecuado.
Procedimientos almacenados en entornos de sistema principal o iSeries
Las consideraciones que deben tenerse en cuenta para procedimientos
almacenados en entornos de sistema principal e iSeries son las siguientes:
v Invocacin
Un programa cliente puede invocar a un programa servidor emitiendo una
sentencia CALL de SQL. En este caso, cada servidor funciona de un modo
distinto a los otros servidores.
z/OS y OS/390
El nombre de esquema no debe tener una longitud superior a 8
bytes, el nombre de procedimiento no debe contener ms de 18
bytes y el procedimiento almacenado debe estar definido en el
catlogo SYSIBM.SYSPROCEDURES del servidor.
VSE o VM
El nombre de procedimiento no debe contener ms de 18 bytes y
debe estar definido en el catlogo SYSTEM.SYSROUTINES del
servidor.
OS/400
El nombre de procedimiento debe ser un identificador de SQL.
Tambin puede utilizar las sentencias DECLARE PROCEDURE o
CREATE PROCEDURE para especificar el nombre de va de acceso
real (nombre de esquema o nombre de coleccin) a fin de localizar
el procedimiento almacenado.
Todas las sentencias CALL destinadas a DB2 UDB para iSeries
desde REXX/SQL se deben preparar dinmicamente y la aplicacin
las tiene que ejecutar como la sentencia CALL implantada en las
correlaciones de REXX/SQL con CALL USING DESCRIPTOR.
Puede invocar al programa servidor en DB2 Universal Database con el
mismo convenio de parmetros que utilizan los programas servidores en
DB2 Universal Database para OS/390 y z/OS, DB2 UDB para iSeries o DB2
para VSE y VM. Para obtener ms informacin sobre el convenio de
parmetros en otras plataformas, consulte la documentacin del producto
DB2 correspondiente a cada plataforma.
Todas las sentencias de SQL contenidas en un procedimiento almacenado se
ejecutan formando parte de la unidad de trabajo SQL iniciada por el
programa cliente SQL.
v No pase valores de indicador con significados especiales a los
procedimientos almacenados, ni desde stos.
Entre DB2 Universal Database, los sistemas pasan cualquier cosa que se
incluya en las variables de indicador. Sin embargo, cuando se utiliza DB2
Connect, slo se pueden pasar 0, -1 y -128 en las variables de indicador.
v Debe definir un parmetro para devolver los posibles errores o avisos
encontrados por la aplicacin de servidor.
Un programa servidor en DB2 Universal Database puede actualizar la
SQLCA para devolver los posibles errores o avisos, pero un procedimiento
almacenado en DB2 Universal Database para OS/390 y z/OS o DB2 UDB
para iSeries no dispone de este soporte. Si desea devolver un cdigo de
error desde el procedimiento almacenado, lo debe pasar en forma de
parmetro. El SQLCODE y la SQLCA slo los establece el servidor para los
errores detectados por el sistema.
v DB2 para VSE y VM Versin 7 o superior, DB2 Universal Database para
OS/390 y z/OS Versin 5.1 o superior, DB2 para AS/400 V5R1 y DB2 para
iSeries Versin 7 o superior son los nicos servidores de aplicaciones de
sistema principal o iSeries que actualmente pueden devolver los conjuntos
de resultados de procedimientos almacenados.
v CALL sentencia en el manual Consulta de SQL, Volumen 2
Soporte de DB2 Connect de SQL compuesto
El cdigo SQL compuesto permite que se agrupen varias sentencias de SQL en
un solo bloque ejecutable. Esto puede reducir la actividad general de la red y
mejorar el tiempo de respuesta.
Con SQL compuesto NOT ATOMIC, el proceso de SQL compuesto contina
despus de un error. Con SQL compuesto ATOMIC, un error retrotrae el
grupo entero de SQL compuesto.
Las sentencias se seguirn ejecutando hasta que el servidor de aplicaciones las
termine. En general, la ejecucin de la sentencia de SQL compuesto slo se
detendr en caso de errores graves.
El cdigo SQL compuesto NOT ATOMIC se puede utilizar con todos los
servidores de aplicacin de sistema principal o iSeries soportados. SQL
compuesto ATOMIC se puede utilizar con servidores de aplicaciones de
sistema principal soportados.
Si se producen varios errores de SQL, los SQLSTATE de las siete primeras
sentencias que fallen se devuelven en el campo SQLERRMC de la SQLCA con
un mensaje que indica que se han producido varios errores.
Actualizacin mltiple con DB2 Connect
DB2 Connect permite realizar una actualizacin mltiple, tambin conocida
como confirmacin en dos fases. Una actualizacin mltiple es una
actualizacin de varias bases de datos en una sola unidad de trabajo
distribuida (DUOW). Si se puede o no se puede utilizar esta posibilidad,
depende de varios factores:
v El programa de aplicacin se debe precompilar con las opciones CONNECT
2 y SYNCPOINT TWOPHASE.
v Si tiene conexiones de red SNA, puede utilizar el soporte de confirmacin
en dos fases que proporciona la funcin de gestor de puntos de sincronismo
(SPM) de DB2 Connect Enterprise Edition en AIX y Windows NT. Esta
funcin permite a los siguientes servidores de bases de datos de sistema
principal participar en una unidad de trabajo distribuida:
DB2 para AS/400 Versin 3.1 o posterior
DB2 UDB para iSeries Versin 5.1 o posterior
DB2 para OS/390 Versin 5.1 o posterior
DB2 UDB para OS/390 y z/OS Versin 7 o posterior
DB2 para VM & VSE Versin V5.1 o posterior.
Esto es cierto para aplicaciones DB2 UDB nativas y aplicaciones
coordinadas por un supervisor TP externo como IBM TXSeries, CICS para
Open Systems, BEA Tuxedo, Encina Monitor y Microsoft Transaction Server.
v Si tiene conexiones de red TCP/IP, un servidor DB2 para OS/390 V5.1 o
posteriores puede participar en una unidad de trabajo distribuida. Si la
aplicacin se controla mediante un Supervisor de proceso de transacciones,
tal como IBM TXSeries, CICS para Open Systems, Encina Monitor o
Microsoft Transaction Server, debe utilizar SPM.
Si, tanto las aplicaciones DB2 nativas como las aplicaciones de supervisor
TP, utilizan un servidor DB2 Connect Enterprise Edition comn para
acceder a datos del sistema principal a travs de conexiones TCP/IP, se
debe utilizar el gestor de puntos de sincronismo.
Si se utiliza un solo servidor DB2 Connect Enterprise Edition para acceder a
datos del sistema principal usando los dos protocolos de red SNA y
TCP/IP, y si se requiere una confirmacin en dos fases, debe utilizar SPM.
Esto es as tanto para las aplicaciones DB2 como para las aplicaciones de
supervisor TP.
v XA function supported by DB2 UDB en el manual Administration Guide:
Planning
v Configuring DB2 Connect with an XA compliant transaction manager en
el manual DB2 Connect Users Guide
v Configuring BEA Tuxedo en el manual Administration Guide: Planning
v Updating host or iSeries database servers with an XA-compliant
transaction manager en el manual Administration Guide: Planning
Sentencias de SQL de servidor de sistema principal e iSeries soportadas por
DB2 Connect
Las sentencias siguientes se compilan satisfactoriamente para un proceso de
servidor de sistema principal o iSeries, pero no para un proceso con sistemas
DB2 Universal Database:
v ACQUIRE
v DECLARE (modificador.(calificador.)nombre_tabla TABLE ...
v LABEL ON
El procesador de lnea de mandatos tambin soporta estas sentencias.
Las sentencias siguientes se soportan para un proceso de servidor de sistema
principal e iSeries, pero no se aaden al archivo de vinculacin ni al paquete
y el procesador de lnea de mandatos no las soporta:
v DESCRIBE nombre_sentencia INTO nombre_descriptor USING NAMES
v PREPARE nombre_sentencia INTO nombre_descriptor USING NAMES
FROM ...
El precompilador realiza las suposiciones siguientes:
v Las variables del lenguaje principal son variables de entrada
v Se asigna a la sentencia un nmero de seccin exclusivo.
Sentencias de SQL de servidor de sistema principal e iSeries rechazadas por
DB2 Connect
DB2 Connect y el procesador de lnea de mandatos no soportan las sentencias
de SQL siguientes:
v COMMIT WORK RELEASE
v DECLARE nombre_sentencia, nombre_sentencia STATEMENT
v DESCRIBE nombre_sentencia INTO nombre_descriptor USING xxxx (donde
xxxx es ANY, BOTH o LABELS)
v PREPARE nombre_sentencia INTO nombre_descriptor USING xxxx FROM
:variable_sist_principal (donde xxxx es ANY, BOTH o LABELS)
v PUT ...
v ROLLBACK WORK RELEASE
v SET :host_variable = CURRENT ...
Las sentencias de SQL dinmicas ampliadas de DB2 para VSE y VM se
rechazan con -104 y SQLCODE de error de sintaxis.
Apndice C. Simulacin de clasificacin binaria EBCDIC
Con DB2, puede clasificar series de caracteres de acuerdo con un orden de
clasificacin definido por el usuario. Puede utilizar esta funcin para simular
la clasificacin binaria EBCDIC.
Como ejemplo de cmo simular una clasificacin EBCDIC, supongamos que
desea crear una base de datos ASCII con la pgina de cdigos 850, pero
tambin desea que las series de caracteres se clasifiquen como si los datos
realmente residieran en una base de datos EBCDIC con la pgina de cdigos
500. Consulte las figuras siguientes para ver las definiciones de pgina de
cdigos 500 y pgina de cdigos 850.
Supongamos la clasificacin relativa de cuatro caracteres en una base de datos
de pgina de cdigos EBCDIC 500, cuando se clasifican en cdigo binario:
Carcter Punto de cdigo de pgina de cdigos 500
a X'81'
b X'82'
A X'C1'
B X'C2'
El orden de clasificacin binaria de la pgina de cdigos 500 (el orden
deseado) es:
a < b < A < B
Si crea la base de datos con la pgina de cdigos ASCII 850, el orden de
clasificacin sera el siguiente:
Carcter Punto de cdigo de pgina de cdigos 850
a X'61'
b X'62'
A X'41'
B X'42'
El orden binario de la pgina de cdigos 850 (que no es el orden deseado) es:
A < B < a < b
Para conseguir el orden deseado, tiene que crear la base de datos con un
orden de clasificacin definido por el usuario. Se suministra un orden de
clasificacin de ejemplo solo con este objetivo con DB2 en el archivo include
sqle850a.h. El contenido de sqle850a.h se muestra a continuacin.
Para ver cmo conseguir el orden de clasificacin de la pgina de cdigos 500
en caracteres de la pgina de cdigos 850, observe el orden de clasificacin de
ejemplo de sqle_850_500. Para cada carcter de la pgina de cdigos 850, su
peso en el orden de clasificacin es simplemente su punto de cdigo
correspondiente en la pgina de cdigos 500.
Por ejemplo, supongamos que tenemos la letra a. Esta letra tiene el punto de
cdigo X'61' para la pgina de cdigos 850. En la matriz sqle_850_500, a la
letra a se le asigna un peso de X'81' (es decir, el elemento nmero 98 de la
matriz sqle_850_500).
Veamos cmo se clasifican los cuatro caracteres cuando se crea la base de
datos con el orden de clasificacin definido por el usuario del ejemplo
anterior:
#ifndef SQL_H_SQLE850A
#define SQL_H_SQLE850A
#ifdef __cplusplus
extern "C" {
#endif
unsigned char sqle_850_500[256] = {
0x00,0x01,0x02,0x03,0x37,0x2d,0x2e,0x2f,0x16,0x05,0x25,0x0b,0x0c,0x0d,0x0e,0x0f,
0x10,0x11,0x12,0x13,0x3c,0x3d,0x32,0x26,0x18,0x19,0x3f,0x27,0x1c,0x1d,0x1e,0x1f,
0x40,0x4f,0x7f,0x7b,0x5b,0x6c,0x50,0x7d,0x4d,0x5d,0x5c,0x4e,0x6b,0x60,0x4b,0x61,
0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0x7a,0x5e,0x4c,0x7e,0x6e,0x6f,
0x7c,0xc1,0xc2,0xc3,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xd1,0xd2,0xd3,0xd4,0xd5,0xd6,
0xd7,0xd8,0xd9,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe8,0xe9,0x4a,0xe0,0x5a,0x5f,0x6d,
0x79,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x91,0x92,0x93,0x94,0x95,0x96,
0x97,0x98,0x99,0xa2,0xa3,0xa4,0xa5,0xa6,0xa7,0xa8,0xa9,0xc0,0xbb,0xd0,0xa1,0x07,
0x68,0xdc,0x51,0x42,0x43,0x44,0x47,0x48,0x52,0x53,0x54,0x57,0x56,0x58,0x63,0x67,
0x71,0x9c,0x9e,0xcb,0xcc,0xcd,0xdb,0xdd,0xdf,0xec,0xfc,0x70,0xb1,0x80,0xbf,0xff,
0x45,0x55,0xce,0xde,0x49,0x69,0x9a,0x9b,0xab,0xaf,0xba,0xb8,0xb7,0xaa,0x8a,0x8b,
0x2b,0x2c,0x09,0x21,0x28,0x65,0x62,0x64,0xb4,0x38,0x31,0x34,0x33,0xb0,0xb2,0x24,
0x22,0x17,0x29,0x06,0x20,0x2a,0x46,0x66,0x1a,0x35,0x08,0x39,0x36,0x30,0x3a,0x9f,
0x8c,0xac,0x72,0x73,0x74,0x0a,0x75,0x76,0x77,0x23,0x15,0x14,0x04,0x6a,0x78,0x3b,
0xee,0x59,0xeb,0xed,0xcf,0xef,0xa0,0x8e,0xae,0xfe,0xfb,0xfd,0x8d,0xad,0xbc,0xbe,
0xca,0x8f,0x1b,0xb9,0xb6,0xb5,0xe1,0x9d,0x90,0xbd,0xb3,0xda,0xfa,0xea,0x3e,0x41
};
#ifdef __cplusplus
}
#endif
#endif /* SQL_H_SQLE850A */
Figura 9. Orden de clasificacin definido por el usuario - sqle_850_500
Carcter Punto cdigo pgina cdigos 850 / Peso (de sqle_850_500)
a X'61' / X'81'
b X'62' / X'82'
A X'41' / X'C1'
B X'42' / X'C2'
El orden definido por el usuario de la pgina de cdigos 850 por peso (el
orden deseado) es:
a < b < A < B
En este ejemplo, consigue el orden deseado especificando los pesos correctos
para simular el comportamiento deseado.
Mirando detenidamente el orden de clasificacin real, se observa que el orden
en s es simplemente una tabla de conversin, en la que la pgina de cdigos
fuente es la pgina de cdigos de la base de datos (850) y la pgina de
cdigos de destino es la pgina de cdigos del orden binario deseado (500).
Otros rdenes de clasificacin de ejemplo que se suministran con DB2
permiten otras conversiones. Si una tabla de conversin que necesita no se
suministra con DB2, puede obtener tablas de conversin adicionales de la
publicacin de IBM Character Data Representation Architecture, Reference and
Registry, SC09-2190. Encontrar las tablas de conversin adicionales en un
CD-ROM que se suministra con dicha publicacin.
Apndice C. Simulacin de clasificacin binaria EBCDIC 545
DIGIT
HEX
1
o
o
2
4- 5- 6- 7- 8- 9- A- B- C- D- E- F-
-0
-1
-2
-3
-4
-5
-6
-7
-8
-9
-A
-B
-C
-D
-E
-F
(SP)
SP010000 SM030000
&
SP100000
-
LO610000
LO620000
SM190000
SM170000
SC040000
SM110000
{
SM140000
}
SM070000
\
ND100000
0
(RSP)
SP300000 LE110000
SP120000
/
LE120000
LA010000
a
LJ010000
j
SD190000
~
SC020000
LA020000
A
LJ020000
J
SA060000
ND010000
1
LA150000
LE150000
LA160000
LE160000
b
LB010000 LK010000
k
LS010000
s
SC050000
LB020000
B
LK020000
K
LS020000
S
ND020000
2
LA170000
LE170000
LA180000
LE180000
LC010000
c
LL010000
l
LT010000
t
SD630000 LC020000
C
LL020000
L
LT020000
T
ND030000
3
LA130000
LE130000
LA140000
LE140000
LD010000
d
LM010000
m
LU010000
u
SM520000
LD020000
D
LM020000
M
LU020000
U
ND040000
4
LA110000
LI110000
LA120000
LI120000
LE010000
e
LN010000
n
LV010000
v
SM240000
LE020000
E
LN020000
N
LV020000
V
ND050000
5
LA190000
LI150000
LA200000
LI160000
LF010000
f
LO010000
o
LW010000
w
SM250000
LF020000
F
LO020000
O
LW020000
W
ND060000
6
LA270000
LI170000
LA280000
LI180000
LG010000
g
LP010000
p
LX010000
x
NF040000
LG020000
G
LP020000
P
LX020000
X
ND070000
7
LC410000
LI130000
LC420000
LI140000
LH010000
h
LQ010000
q
LY010000
y
NF010000
LH020000
H
LQ020000
Q
LY020000
Y
ND080000
8
LN190000
LS610000
LN200000
SD130000
`
LI010000
i
LR010000
r
LZ010000
z
NF050000
LI020000
I
LR020000
R
LZ020000
Z
ND090000
9
SM060000
[
SM080000
]
SM650000 SP130000
:
SP170000
SM210000
SP030000
SM660000
(SHY)
SP320000 ND011000
ND021000
ND031000
SP110000
.
SC030000
$
SP080000
,
SM010000
#
SP180000
SM200000
SP160000
SM130000
l
LO150000
LU150000
LO160000
LU160000
SA030000
<
SM040000
*
SM020000
%
SM050000
@
LD630000
LA510000

LD620000 SM150000
LO170000
LU170000
LO180000
LU180000
SP060000
(
SP070000
)
SP090000
_
SP050000
'
LY110000
SD410000
,
LY120000
SD170000
LO130000
LU130000
LO140000
LU140000
SA010000
+
SP140000
;
SA050000
>
SA040000
=
LT630000
LA520000
LT640000
SD110000

LO110000 LU110000
LO120000
LU120000
SP020000
!
SD150000
^
SP150000
?
SP040000
"
SA020000
SC010000
SM530000
SA070000
LO190000
LY170000
LO200000
(EO)
P gina de codigos 00500
Figura 10. Pgina de cdigos 500

v rdenes de clasificacin en la pgina 422
DIGITS
HEX
1
2
O
O
0- 1- 2- 3- 4- 5- 6- 7- 8- 9- A- B-
-0
-1
-2
-3
-4
-5
-6
-7
-8
-9
-A
-B
-C
-D
-E
-F
SM590000
(SP)
SP010000 ND100000
0
SM050000
@
LP020000
P
SD130000
`
LP010000
p
LC420000
LE120000
LA110000
SF140000
SS000000 SM630000 SP020000
!
ND010000
1
LA020000
A
LQ020000
Q
LA010000
a
LQ010000
q
LU170000
LA510000
LI110000
SF150000
SS010000 SM760000 SP040000
"
ND020000
2 B
LB020000 LR020000
R
LB010000
b
LR010000
r
LE110000
LA520000
LO110000
SF160000
SS020000 SP330000
!!
SM010000
#
ND030000
3
LC020000
C
LS020000
S
LC010000
c
LS010000
s
LA150000
LO150000
LU110000
SF110000
SS030000 SM250000
SC030000
$
ND040000
4
LD020000
D
LT020000
T
LD010000
d
LT010000
t
LA170000 LO170000
LN190000
SF090000
SS040000 SM240000
SM020000
%
ND050000
5
LE020000
E
LU020000
U
LE010000
e
LU010000
u
LA130000
LO130000
LN200000
LA120000
SS050000 SM700000 SM030000

&
ND060000
6
LF020000
F
LV020000
V
LF010000
f
LV010000
v
LA270000
LU150000
SM210000
LA160000
SM570000 SM770000 SP050000

'
ND070000
7
LG020000
G
LW020000
W
LG010000
g
LW010000
w
LC410000
LU130000
SM200000
LA140000
SM570001 SM320000 SP060000

(
ND080000
8
LH020000
H
LX020000
X
LH010000
h
LX010000
x
LE150000
LY170000
SP160000
SM520000
SM750000
SM330000 SP070000
)
ND090000
9
LI020000
I
LY020000
Y
LI010000
i
LY010000
y
LE170000
LO180000
SM530000
SF230000
SM750002
SM310000 SM040000
*
SP130000
:
LJ020000
J
LZ020000
Z
LJ010000
j
LZ010000
z
LE130000
LU180000
SM660000
SF240000
SM280000 SM300000 SA010000
+
SP140000
;
LK020000
K
SM060000
[
LK010000
k
SM110000
{
LI170000
LO610000
NF010000
SF250000
SM290000 SA420000 SP080000
,
SA030000
<
LL020000
L
SM070000
\ l
LL010000 SM130000
l
LI150000
SC020000
NF040000
SF260000
SM930000
SM780000 SP100000
-
SA040000
=
LM020000
M
LM080000
]
LM010000
m
SM140000
}
LI130000
LO620000
SP030000
SC040000
SM910000 SM600000 SP110000

.
SA050000
>
LN020000
N
SD150000
^
LN010000
n
SD190000
~
LA180000 SA070000
SP170000
SC050000
SM690000 SV040000 SP120000

/
SP150000
?
LO020000
O
SP090000
_
LO010000
o
SM790000 LA280000
SC070000
SP180000
SF030000
P gina de cdigos 00850
C- D- E- F-
SF020000 LD630000
SF070000 LD620000
SF060000
LE160000
SF080000 LE180000
SF100000 LE140000
SF050000
1
LI610000
LA190000
LI120000
LA200000
LI160000
SF380000 LI180000
SF390000 SF040000
SF400000 SF010000
SF410000 SF610000
SF420000
SF570000
SF430000 SM650000
SF440000 LI140000
SC010000
SF600000
LO120000
(SHY)
SP320000
LS610000
SA020000
LO160000
SM100000
LO140000
NF050000
LO190000
SM250000
LO200000
SM240000
SM170000
SA060000
LT630000
SD410000
,
LT640000
SM190000
LU120000
SD170000
LU160000
SD630000
LU140000
ND011000
LY110000
ND031000
LY120000
ND021000
SM150000
SM470000
SD110000
(RSP)
SP300000
8
+
+
+
+
O
Figura 11. Pgina de cdigos 850
Apndice C. Simulacin de clasificacin binaria EBCDIC 547
ndice
Caracteres
Especiales
#ifdefs
restricciones en C/C 200
A
acceso 573
ACQUIRE, sentencia
no soportada en DB2 UDB 541
activadores
actualizaciones anteriores 57
actualizaciones posteriores 58
consideracin sobre lgica de
aplicacin 59
control de relaciones de
datos 57
visin general 29
actualizable por el usuario
estadsticas de catlogo
programa de utilidad de
creacin de prototipos 50
actualizaciones mltiples
finalidad 462
parmetros de
configuracin 467
precompilacin de
aplicaciones 465
sentencias de SQL en aplicaciones
de actualizacin mltiple 463
soporte de DB2 Connect 539
visin general 461
almacenamiento
asignacin para pginas de
cdigos desiguales 449
asociacin para albergar
filas 157
declaracin de suficientes
entidades SQLVAR 151
almacenamientos intermedios
tamao de inserciones colocadas
en almacenamiento
intermedio 480
API Bind
creacin de paquetes 89
vinculacin diferida 94
API CREATE DATABASE
estructura SQLEDBDESC 427
API de paquete opcional JDBC
soporte de controlador de tipo
2 300
API de paquete opcional JDBC 2.1
soporte de controlador de tipo
4 302
API de transacciones de Java
(JTA) 347
API GET ERROR MESSAGE 376
recuperacin de mensajes de
error 137
API principal JDBC 2.1
restricciones del controlador de
tipo 2 299
aplicaciones
actualizacin mltiple
precompilacin 465
ADO
cursores desplazables
actualizables 411
limitaciones 411
bucle 496
conexin con fuentes de datos
IBM OLE DB Provider 416
en entornos de sistema principal
iSeries 527
funciones de MQSeries 21
funciones de programacin de
DB2 22
gestin de transacciones con
puntos de rescate 509
herramientas de DB2 para
desarrollar 5
herramientas para crear
aplicaciones Web 19
interfaces de programacin
soportadas 6
Interfaz XA de X/Open,
enlace 476
puntos de rescate
restricciones 514
reinicio para servicios Web 339
soportado en Java 2 Enterprise
Edition 344
soportado por IBM OLE DB
Provider 393
suspendida 496
aplicaciones (continuacin)
Visual Basic
conexin con fuente de
datos 410
aplicaciones ADO
cursores desplazables
actualizables 411
limitaciones 411
palabras clave de serie de
conexin 410
procedimientos
almacenados 411
soporte de IBM OLE DB Provider
para mtodos y propiedades
ADO 411
aplicaciones ATL
cursores
aplicaciones C/C++
acceso a bases de datos de varias
hebras 227
compilacin y enlace, IBM OLE
DB Provider 416
conexin con fuentes de datos,
aplicaciones CICS
diferencias entre
plataformas 527
aplicaciones compiladas, creacin de
paquetes 82
aplicaciones REXX 383
aplicaciones Web
herramientas para crear 19
servicios Web 337
APPC (Comunicacin Avanzada
Programa a Programa)
manejo de interrupciones 136
archivo de extensin de definicin
de acceso a documentos (DADX)
finalidad 343
archivos
declaraciones de referencia en
C/C 199
archivos de entrada para C/C 176
archivos de entrada y salida
COBOL 234
FORTRAN 262
archivos de mensajes
definicin 84
archivos de salida
C/C++ 176
archivos de vinculacin
compatibilidad con versiones
anteriores 93
opciones de precompilacin 84
REXX 384
soporte para aplicaciones
REXX 384
archivos fuente
creacin 79
archivos include
requisitos
C/C 177
COBOL 234
FORTRAN 263
SQL
para C/C 177
para COBOL 234
para FORTRAN 263
SQL1252A
COBOL 234
FORTRAN 263
SQL1252B
COBOL 234
FORTRAN 263
SQLADEF para C/C 177
SQLAPREP
para C/C 177
para COBOL 234
para FORTRAN 263
SQLCA
para C/C 177
para COBOL 234
para FORTRAN 263
SQLCA_92
COBOL 234
FORTRAN 263
SQLCACN
FORTRAN 263
SQLCACS
FORTRAN 263
SQLCLI para C/C 177
SQLCLI1 para C/C 177
SQLCODES
para C/C 177
para COBOL 234
para FORTRAN 263
SQLDA
COBOL 234
para C/C 177
para FORTRAN 263
SQLDACT
FORTRAN 263
archivos include (continuacin)
SQLE819A
para C/C 177
para COBOL 234
para FORTRAN 263
SQLE819B
para C/C 177
para COBOL 234
para FORTRAN 263
SQLE850A
para C/C 177
para COBOL 234
para FORTRAN 263
SQLE850B
para C/C 177
para COBOL 234
para FORTRAN 263
SQLE932A
para C/C 177
para COBOL 234
para FORTRAN 263
SQLE932B
para C/C 177
para COBOL 234
para FORTRAN 263
SQLEAU
para C/C 177
para COBOL 234
para FORTRAN 263
SQLENV
COBOL 234
FORTRAN 263
para C/C 177
SQLETSD
COBOL 234
SQLEXT para C/C 177
SQLJACB para C/C 177
SQLMON
COBOL 234
FORTRAN 263
para C/C 177
SQLMONCT
para COBOL 234
SQLSTATE
para C/C 177
para COBOL 234
para FORTRAN 263
SQLSYSTM para C/C 177
SQLUDF para C/C 177
SQLUTBCQ
COBOL 234
SQLUTBSQ
COBOL 234
SQLUTIL
para C/C 177
archivos include (continuacin)
SQLUTIL (continuacin)
para COBOL 234
para FORTRAN 263
SQLUV para C/C 177
SQLUVEND para C/C 177
SQLXA para C/C 177
ubicacin
en C/C 180
en COBOL 237
en FORTRAN 266
rea de comunicaciones de SQL
(SQLCA) 40
ARI en campo SQLERRP
DB2 para VSE VM 531
ASCII
datos de bytes mixtos 529
orden de clasificacin 535
ATOMIC, SQL compuesto
B
bases de datos
acceso
varias hebras 227
creacin
utilizando contextos
distintos 227
bibliotecas de clases
Java 288
BLOB-FILE, tipo de COBOL 254
BLOB-LOCATOR, tipo de
COBOL 254
Bloque de descriptor de base de
datos (SQLEDBDESC),
especificacin de rdenes de
clasificacin 427
bloqueo
error de insercin en
almacenamiento
intermedio 483
bloqueo a nivel de fila
entornos de sistema principal e
iSeries 536
bloqueo a nivel de pgina
iSeries 536
bloqueos
liberacin de cursor 120
nivel de fila 536
nivel de pgina 536
tiempo de espera 536
bsqueda de documentacin de DB2
utilizacin de Netscape 4.x 570
C
calificacin y operaciones de
miembros en C/C++ 209
CALL, sentencias
CALL USING
DESCRIPTOR 537
Java 309
plataformas soportadas 537
campo SQLSTATE 134
campos largos
diferencias entre
plataformas 529
intermedio, restriccin 486
caracteres de desplazamiento a
teclado ideogrfico, diferencias
entre plataformas 529
cascada 535
catlogo SYSIBM.SYSROUTINES
(VM/VSE) 537
catlogos del sistema
iSeries 537
Centro de desarrollo
caractersticas 25
visin general 25
Centro de informacin de DB2 575
cerrar insercin colocada en
almacenamiento intermedio 480
CICS SYNCPOINT ROLLBACK,
mandato 472
clasificacin
juegos de cdigos en chino
(tradicional) 447
juegos de cdigos en
japons 447
orden de clasificacin 427, 535
orden de resultados 535
clusula FOR UPDATE 124
clusula ORDER BY
claves
fornea
diferencias entre
plataformas 535
primaria 535
claves forneas
diferencias entre
plataformas 535
claves primarias
diferencias entre
plataformas 535
CLI (Interfaz de nivel de llamada)
frente a SQL dinmico
incorporado 169
cliente/servidor
conversin de pgina de
cdigos 436
CLOB-FILE, tipo de COBOL 254
CLOB-LOCATOR, tipo de
COBOL 254
COBOL, lenguaje
archivos de entrada y salida 234
archivos include 234
consideraciones sobre EUC en
chino (tradicional) 258
japons 258
consideraciones sobre
programacin 233
declaracin de variables del
lenguaje principal 242
lenguaje principal de
grficos 245
declaraciones de datos LOB 246
declaraciones de localizadores de
LOB 248
declaraciones de referencias de
archivos 248
estructuras de sistema
principal 249
FOR BIT DATA 257
no hay soporte para acceso a
bases de datos de varias
hebras 234
nomenclatura de variables del
normas para las variables de
indicador 246
REDEFINES 252
referencia a variables del lenguaje
principal 240
restricciones 234
restricciones orientadas a
objetos 259
sentencias de SQL
incorporado 77, 237
tablas de indicadores 251
tipos de datos 254
variables SQLCODE 257
variables SQLSTATE 257
COBOL, tipos de datos
BINARY 257
BLOB 254
BLOB-FILE 254
BLOB-LOCATOR 254
CLOB 254
CLOB-FILE 254
CLOB-LOCATOR 254
COBOL, tipos de datos
(continuacin)
COMP 257
COMP-1 254
COMP-3 254
COMP-4 257
COMP-5 254
DBCLOB 254
DBCLOB-FILE 254
DBCLOB-LOCATOR 254
PICTURE (PIC), clusula 254
USAGE clusula 254
cdigos de finalizacin 40
cdigos de mensajes de error
manejo de errores 40
cdigos de resultados 40
cdigos de retorno
declaracin del SQLCA 40
estructura de SQLCA 134
cdigos de territorio
SQLERRMC, campo de
SQLCA 531
cdigos satisfactorios 40
coherencia
de datos 44
colocacin en serie
estructuras de datos 229
SQL, ejecucin de
sentencias 227
columna, tipos de
creacin
COBOL 254
FORTRAN 276
creacin en C/C 218
columnas
derivadas 499
establecimiento de valores
nulos 110
generadas 499
identidad 500
tipos de datos de SQL
soportados 113
utilizacin de variables de
indicador en columnas de datos
que pueden tener valores
null 116
columnas de identidad
comparacin con objetos en
secuencia 506
finalidad 500
columnas derivadas
finalidad 499
columnas generadas
finalidad 499
ndice 551
comentarios
sentencia de SQL incorporado
REXX 372
SQL, normas 182, 237, 267
COMMIT WORK RELEASE,
sentencia
no soportada en DB2
Connect 541
COMP-1, clusula en los tipos de
COBOL 254
COBOL 254
COBOL 254
comparacin de caracteres 424
comparticin de sesiones, SQLj y
JDBC 285
compilacin
programas SQLj
ejemplo de 310
visin general 88
comportamiento de definicin,
DYNAMICRULES 147
comportamiento de ejecucin,
DYNAMICRULES 147
comportamiento de invocacin,
DYNAMICRULES 147
comportamiento de vinculacin,
DYNAMICRULES 147
conexiones
agrupacin, WebSphere 351
CONNECT nula 531
gestin de recursos, Java 286
implcita
diferencias entre
plataformas 531
sentencia CONNECT
RESET 531
sentencia CONNECT TO 531
conexiones implcitas
diferencias entre
plataformas 531
confirmacin de cambios
tablas 45
confirmacin en dos fases
actualizacin
varias bases de datos 461
conjunto de filas de esquema
consideraciones sobre programacin
acceso a servidores de sistema
principal, AS/400 o iSeries 469
C/C++ 176
COBOL 233
entornos 32
consideraciones sobre programacin
(continuacin)
FORTRAN 261
infraestructura de
seudocdigo 49
interfaces soportadas 6
interfaz XA de X/Open 472
REXX 369
tipos de variables, control de
valores de datos 55
constantes grficas
(tradicional) 447
juegos de cdigos en
japons 447
consultas
actualizable 124
servicios Web 342
suprimible 124
consultas SQL, servicios Web 342
contenedores
Java 2 Enterprise Edition 345
contextos
dependencias de aplicacin
entre 230
dependencias de base de datos
entre 230
establecimiento en aplicaciones
DB2 de varias hebras 227
evitacin de puntos muertos
entre 231
control de relaciones de datos
activadores 57
activadores anteriores 57
activadores posteriores 58
integridad referencial 56
lgica de aplicacin 58
control de valores de datos
finalidad 52
lgica de aplicacin y tipo de
variable 55
restricciones de comprobacin de
tabla 54
restricciones de integridad
referencial 54
restricciones exclusivas 53
tipos de datos 53
vistas con opcin check 55
controlador JDBC de tipo 2
restricciones de API principal
JDBC 2.1 299
soporte de API de paquete
opcional JDBC 2.1 300
controlador JDBC de tipo 4
restricciones de API principal
JDBC 2.1 300
soporte de API de paquete
opcional JDBC 2.1 302
conversin de caracteres
codificacin de procedimientos
almacenados 435, 457
codificacin de sentencias de
SQL 433
programacin 432
cuando se ejecuta una
aplicacin 436
cundo se produce 437
desbordamiento en la longitud de
la serie 457
la serie sobrepasando los tipos
de datos 457
durante precompilacin y
vinculacin 436
expansin 440
pginas de cdigos
soportadas 438
soporte de idioma nacional
(NLS) 436
sustituciones de caracteres 438
Unicode (UCS2) 459
correlaciones de tipos de datos
entre OLE DB y DB2 396
tabla de 396
creacin
paquetes para aplicaciones
compiladas 82
creacin de prototipo del cdigo
SQL 50
cursores
actualizable 125
actualizable y desplazable en
aplicaciones ADO 411
ambiguos 125
aplicaciones ATL
bloqueo, consideraciones sobre
punto de rescate 516
colocacin al final de la
tabla 131
comportamiento con sentencia
COMMIT 120
comportamiento tras ROLLBACK
TO SAVEPOINT 514
COMMIT 120
cursores (continuacin)
ROLLBACK 120
declaracin 119
denominacin
REXX 372
filas
actualizacin 124
supresin 124
finalidad 105, 118
finalizacin de unidad de
trabajo 120
FOR FETCH ONLY 125
liberacin
comportamiento de
bloqueo 120
paquete invalidado
captacin de filas 120
proceso, en SQL dinmico 144
proceso, resumen de 118
proceso con estructura de
SQLDA 158
programa de ejemplo 126
READ ONLY 477
recuperacin de filas 119
recuperacin de varias filas 118
REXX 381
solo lectura
requisitos de aplicacin 120
slo lectura 119, 125
SQL dinmico, programa de
ejemplo 145
tipos 125
uso en CLI 169
varios en aplicacin 118
WITH HOLD
comportamiento tras
COMMIT 120
comportamiento tras
ROLLBACK 120
Interfaz XA de X/Open 472
revinculacin de paquete
durante unidad de
trabajo 120
D
datos
acceso a especificaciones de
Microsoft 17
acceso a travs de servicios
Web 341
actualizacin 124
anteriormente recuperada
actualizacin 131
datos (continuacin)
captada, guardar 128
coherencia a nivel de
transaccin 44
confirmacin de cambios 45
control de relaciones 56
deshacer cambios con sentencia
ROLLBACK 46
desplazamiento 127
entornos de bases de datos
particionadas 487
expansin
servidor iSeries 529
servidor OS/390 529
extraccin de grandes
volmenes 487
incoherencia 46
recuperacin
con SQL esttico 105
segunda vez 129
segunda recuperacin 130
supresin 124
transmisin de grandes
volmenes 517
datos de bytes mixtos
servidor OS/390 529
datos grficos
(tradicional) 444, 447
juegos de cdigos en
japons 444, 447
DB2 Application Development
Client 391
DB2 Connect
niveles de aislamiento 534
proceso de peticiones de
interrupcin 532
DB2 Personal Developers Edition 3
DB2 Universal Developers
Edition 3
DB2Appl.java
ejemplo de aplicacin 297
DB2ARXCS.BND, archivo de enlace
lgico para REXX 384
DB2ARXNC.BND, archivo de enlace
lgico para REXX 384
DB2ARXRR.BND, archivo de enlace
lgico para REXX 384
DB2ARXRS.BND, archivo de enlace
lgico para REXX 384
DB2ARXUR.BND, archivo de enlace
lgico para REXX 384
db2bfd, programa de utilidad de
descripcin de archivos de
vinculacin 95
DB2INCLUDE, variable de
entorno 237, 266
valor de antememoria de
procesador de lnea de
mandatos 180
DBCLOB-FILE, tipo de COBOL 254
DBCLOB-LOCATOR, tipo de
COBOL 254
DBCS (juego de caracteres de doble
byte)
juegos de cdigos de japons y
chino tradicional 444
DCL (lenguaje de control de datos)
iSeries 530
DDL (lenguaje de definicin de
datos)
e iSeries 529
rendimiento de SQL
dinmico 141
declaracin
variables de indicador 110
variables del lenguaje principal,
normas 106
archivos en REXX 379
DECLARE, sentencia
no soportada en DB2
Connect 541
no soportada en DB2 UDB 541
DECLARE PROCEDURE, sentencia
(OS/400) 537
definicin de acceso a documentos
(DAD)
finalidad 342
depuracin
programas FORTRAN 262
programas Java 313
programas SQLj 313
desbordamiento, numrico 537
desbordamientos por conversin
numrica 537
descriptores de contexto
conexin 169
descriptor 169
entorno 169
sentencia 169
descriptores de contexto de conexin
descripcin 169
ndice 553
descriptores de contexto de
descriptor
descripcin 169
descriptores de contexto de entorno
descripcin 169
descriptores de contexto de sentencia
descripcin 169
destino
particiones, comportamiento sin
intermedio 480
diagnstico de aplicaciones
suspendidas o en bucle 496
discapacidad 573
diseo de aplicacin
aplicaciones Web 337
archivos include
COBOL 234
colocacin en antememoria de
SQL dinmico 102
japons y chino tradicional en
COBOL 258
consideraciones sobre la
conversin de caracteres 432
control de valores de datos 52
conversin de caracteres en
sentencias de SQL 433
conversiones de caracteres en los
procedimientos
almacenados 435
creacin de estructura de
SQLDA, directrices 158
descripcin de sentencia
SELECT 156
ejecucin de sentencias sin
variables 140
ejemplo de Perl 366
guardar peticiones de usuario
final 165
lgica en el servidor 59
manejo de errores, directrices 41
rdenes de clasificacin,
directrices 422
pasar datos, directrices 162
precompilacin 79
proceso de cursor 120
programas de ejemplo 132
prototipo en Perl 363
puntos de cdigo para caracteres
especiales 433
recepcin de valores NULL 110
diseo de aplicacin (continuacin)
recuperacin de datos por
segunda vez 129
relaciones entre objetos de
datos 56
REXX
registro de rutinas 370
sentencias de lista variable,
proceso 164
sentencias necesarias 34
seudocdigo 49
soporte de caracteres de doble
byte (DBCS) 433
SQL dinmico, finalidad 139
SQL esttico, ventajas 102
usuarios simultneos
tablas temporales
declaradas 506
utilizacin de marcadores de
parmetros 166
versiones de paquetes con mismo
nombre 90
vinculacin 79
DML (lenguaje de manipulacin de
datos)
iSeries 529
rendimiento de SQL
dinmico 141
DSN en campo SQLERRP
DB2 UDB para OS/390 531
DSS (subseccin distribuida)
dirigida 478
E
EBCDIC
ejemplos
applets Java 297
declaracin de BLOB
FORTRAN 273
declaracin de BLOB utilizando
COBOL 246
declaracin de CLOB
COBOL 246
FORTRAN 273
declaracin de DBCLOB
COBOL 246
declaracin de localizador de
archivos CLOB
FORTRAN 274
BLOB
COBOL 248
ejemplos (continuacin)
declaracin de referencias de
archivos BLOB
COBOL 248
FORTRAN 275
declaraciones de datos
BLOB 195
CLOB 195
DBCLOB 195
ejemplo de seccin de declaracin
de SQL para tipos de datos SQL
soportados 216
localizador de CLOB 198
marcadores de parmetros,
utilizados en bsqueda y
actualizacin 167
miembros de datos de clase en
programa Perl 366
programa REXX
registro de SQLEXEC,
SQLDBS y SQLDB2 370
referencia de archivos
CLOB 199
sintaxis, variables del lenguaje
principal de caracteres
FORTRAN 271
en lnea
ayuda, acceso 561
enganche, estado con varias
hebras 227
enlace
descripcin 88
entero de 64 bits (BIGINT), tipo de
datos
soportado por DB2 Connect 529
Enterprise Java beans
finalidad 348
entidades SQLVAR
declaracin del nmero
suficiente 155
nmero variable,
declaracin 151
entorno, API de
archivo include
FORTRAN 263
archivo include para C/C 177
archivo include para
COBOL 234
entorno de aplicacin, para
programacin 32
entorno iSeries
principal 469
particionadas
aplicaciones suspendidas o en
bucle 496
cursores READ ONLY 477
elusin local 479
entorno de prueba, creacin 493
errores graves 494
extraccin de un gran volumen
de datos 487
identificacin de la particin que
devuelve el error 496
intermedio
consideraciones 483
finalidad 480
restricciones 486
optimizacin de aplicaciones
OLTP 477
subsecciones distribuidas,
dirigidas 478
entornos de pginas de cdigos
mixtas
nombres de paquetes 435
entornos de prueba
bases de datos
particionadas 493
iSeries
bloqueo a nivel de fila 536
bloqueo a nivel de pgina 536
catlogos del sistema 537
aplicaciones 527
DB2 Connect
niveles de aislamiento 534
diferencias en los SQLCODE y
los SQLSTATE 536
estabilidad del cursor 536
lenguaje de control de datos
(DCL) 530
lenguaje de definicin de datos
(DDL) 529
lenguaje de manipulacin de
datos (DML) 529
procedimientos
almacenados 537
proceso de peticiones de
interrupcin 532
series C terminadas en nulo 533
iSeries (continuacin)
SQLCODE y SQLSTATE
autnomos 533
entornos nacionales
cmo se obtiene DB2 431
obtencin en programas de
aplicacin 430
errores
deteccin en insercin en
almacenamiento
intermedio 483
errores graves, entornos de bases de
datos particionadas 494
espacio GRAPHIC 433
especificacin ActiveX Data Object
(ADO)
soportado en DB2 17
especificacin Microsoft Transaction
Server
acceso a datos 17
especificacin Objeto de datos
remotos (RDO)
soportado en DB2 17
especificaciones de Microsoft
acceso a datos 17
ADO (ActiveX Data Object) 17
MTS (Microsoft Transaction
Server) 17
RDO (Remote Data Object) 17
Visual Basic 17
Visual C 17
estabilidad del cursor (CS)
iSeries 536
estadsticas de catlogo
actualizable por el usuario 50
estado abierto, inserciones en
estado cerrado, inserciones en
estndar FIPS 127-2 52
declaracin de SQLSTATE y
SQLCODE como variables del
estndar ISO/ANS SQL92
definicin 52
soporte 533
estndar SQL92
soporte 533
estructura de sistema principal
COBOL 249
estructura de SQLCA
estructura de SQLCA (continuacin)
archivos include
aplicaciones COBOL 234
aplicaciones FORTRAN 263
avisos 110
campo SQLCODE 134
campo SQLSTATE 134
campo SQLWARN1 110
definicin, programas de
ejemplo 132
particionadas
varias estructuras de SQLCA
fusionadas 495
notificacin de errores 495
requisitos 134
sqlerrd 495
truncamiento de seal 135
varias definiciones 41
varias estructuras
fusionadas 495
visin general 134
estructura de SQLDA
asociacin con sentencia
PREPARE 140
colocacin de informacin sobre
sentencia preparada en 140
creacin 158
declaracin 151
determinacin de tipo de
sentencia arbitraria 164
pasar datos 162
pase de bloques de datos 517
preparacin de sentencias
mediante estructura
mnima 153
estructura SQLCHAR
pasar datos con 162
estructura SQLWARN 134
estructuras de datos
declaracin 34
definidas por el usuario con
varias hebras 229
SQLEDBDESC 427
EUC (Extended UNIX Code)
consideraciones 444
juegos de caracteres 442
EXEC SQL INCLUDE SQLCA
utilizacin de varias
hebras 229
expansin de datos
ndice 555
expansin de datos (continuacin)
servidor OS/390 529
expresin CURVAL 502
expresin NEXTVAL 502
Extended UNIX Code (EUC)
Archivos DBCLOB 447
consideraciones sobre el chino
tradicional 447
clasificacin 447
consideraciones sobre UDF
(funcin definida por el
usuario) 447
constantes grficas 447
conversiones de caracteres,
procedimientos
almacenados 457
chino (tradicional)
C/C 215
consideraciones en
COBOL 258
FORTRAN 278
chino (tradicional) en REXX 372
desbordamiento en la conversin
de caracteres 457
la serie de caracteres 457
ejemplos de expansin 453
expansin en el servidor 449
expansin en la aplicacin 449
Japons
C/C 215
FORTRAN 278
japons en REXX 372
japons y chino tradicional
consideraciones en
COBOL 258
juegos de caracteres 442
(tradicional) 444
juegos de cdigos en
japons 444
manipulacin de datos
grficos 447
pginas de cdigos de doble
byte 446
pginas de cdigos
desiguales 449
pginas de cdigos mixtas 446
procedimientos
almacenados 447
sentencia DESCRIBE 454
tipos de datos de longitud
fija 456
Extended UNIX Code (EUC)
(continuacin)
tipos de datos de longitud
variable 456
validacin de parmetros basada
en el cliente 453
Extended UNIX Code mixto,
consideraciones 446
Extensible Markup Language (XML)
base para servicios Web 337
descripcin 20
extensiones de archivos de entrada
para C/C 176
extensiones de archivos de salida
C/C++ 176
extraccin de grandes volmenes de
datos 487
F
filas
captacin tras paquete
invalidado 120
posicionamiento en tabla 131
recuperacin con cursor 125
recuperacin de varias 118
recuperacin mediante
SQLDA 157
segunda recuperacin
mtodos 129
orden de filas 130
filas, bloqueo
personalizacin para el
rendimiento 517
finalizacin de transacciones de
forma implcita 48
FORCE, mandato
diferencias entre sistemas
operativos 531
FORTRAN, lenguaje
archivos de entrada y salida 262
archivos include 263
tradicional 278
consideraciones sobre el
japons 278
programacin 261
LOB 274
archivos 275
depuracin 262
inclusin de archivos 266
FORTRAN, lenguaje (continuacin)
incorporacin de sentencias de
SQL 77
incorporacin de SQL 267
juegos de caracteres de varios
bytes 278
lneas condicionales 262
lneas de comentario 262
no hay mejoras planificadas 32
hebras 262
precompilacin 262
restricciones 262
seccin de declaracin de
SQL 276
tipos de datos 276
ubicacin de los archivos
include 266
variables del lenguaje principal
declaracin 270
denominacin 269
finalidad 269
referencia 267
FORTRAN, tipos de datos
BLOB 276
BLOB_FILE 276
BLOB_LOCATOR 276
CLOB 276
CLOB_FILE 276
CLOB_LOCATOR 276
conversin con DB2 276
CHARACTER*n 276
INTEGER*2 276
INTEGER*4 276
REAL*2 276
REAL*4 276
REAL*8 276
fuentes
aplicaciones de SQL
incorporado 86
archivos fuente modificados 84
extensiones de archivos SQL 79
extensiones de nombre de
archivo 84
funciones de preprocesador
y el precompilador de SQL 200
funciones de programacin de
DB2 22
funciones de tabla OLE DB 391
funciones definidas por el usuario
(UDF)
aplicacin 59
(tradicional) 447
juegos de cdigos en
japons 447
visin general 24
G
gestor de bases de datos
definicin de API, programas de
ejemplo 132
GROUP BY, clusula
grupo de filas en insercin en
guas de aprendizaje 574
guas de aprendizaje de DB2 574
H
hebras
IBM OLE DB Provider para
DB2 391
varias
aplicaciones UNIX 229
consideraciones sobre pgina
de cdigos 229
consideraciones sobre pgina
de cdigos de
pas/regin 229
dependencias de aplicacin
entre contextos 230
dependencias de base de
datos entre contextos 230
evitacin de puntos muertos
entre contextos 231
problemas potenciales 230
recomendaciones 229
utilizacin en aplicaciones
DB2 227
herramientas
para desarrollo de
aplicaciones 5
I
IBM OLE DB Provider
aplicaciones ADO 410
aplicaciones ATL
cursores 417
aplicaciones C/C
conexiones con fuentes de
datos 416
IBM OLE DB Provider (continuacin)
compilacin y enlace de
aplicaciones C/C 416
conexin de aplicaciones Visual
Basic con fuente de datos 410
conexiones con fuentes de
datos 409
conjunto de filas de
esquema 393
consumidor 391
conversin de datos
de tipos DB2 a tipos OLE
DB 400
conversin de datos de OLE DB a
tipos DB2 398
cursores 396
cursores en aplicaciones
ADO 411
habilitacin automtica de
servicios OLE DB 396
habilitacin del soporte de MTS
en DB2 418
hebras 393
limitaciones para aplicaciones
ADO 411
LOB 393
para DB2
instalacin 391
propiedades de OLE DB
soportadas 406
proveedor 391
restricciones 402
soporte de OLE DB 403
soporte de transacciones
distribuidas MTS y COM 417
soporte para mtodos y
propiedades ADO 411
tipos de aplicaciones
soportadas 393
ID de coleccin, atributo de
DB2 UDB para iSeries 532
paquete 532
incoherencia
datos 46
estados 46
indicaciones horarias
al precompilar 96
inserciones, sin inserciones en
intermedio
asncronos 483
consideraciones 483
consideraciones sobre puntos de
rescate 480
intermedio (continuacin)
deteccin de errores 483
errores de punto muerto 483
estado abierto 483
estado cerrado 483
grupo de filas 483
no soportado en CLP 486
opcin de vinculacin INSERT
BUF 480
parcialmente lleno 480
registros de transacciones 480
restriccin de campo largo 486
restricciones 486
SELECT en inserciones en
almacenamiento
intermedio 483
sentencias que las cierran 480
tamao del almacenamiento
intermedio 480
ventajas 480
violacin de clave exclusiva 483
visin general 480
intermedio variadas 480
INSERT, sentencia
no soportado en CLP 486
VALUES, clusula 480
instantneas de Explain
durante vinculacin 93
integridad referencial
consideracin sobre las relaciones
de datos 56
diferencias entre
plataformas 535
interfaces de programacin de
aplicaciones (API) de DB2
visin general 8
Interfaz de nivel de llamada (CLI)
comparacin de SQL incorporado
y CLI de DB2 169
sentencias de SQL
soportadas 521
ventajas de utilizar 171, 173
visin general 169
Interfaz de nivel de llamada de DB2
(CLI de DB2)
comparacin con SQL dinmico
incorporado 13
visin general 11
ndice 557
interfaz de programacin de
aplicaciones (API)
para establecer contextos entre
hebras
sqleAttachToCtx() 227
sqleBeginCtx() 227
sqleDetachFromCtx() 227
sqleEndCtx() 227
sqleGetCurrentCtx() 227
sqleInterruptCtx() 227
sqleSetTypeCtx() 227
restricciones en un entorno
XA 472
sintaxis para REXX 385
tipos de 52
usos de 52
visin general de 52
Interfaz XA de X/Open
aplicacin de una soba
hebra 472
aplicacin de varias hebras 472
caractersticas del proceso de
transacciones 472
cursores declarados WITH
HOLD 472
DISCONNECT 472
enlace de aplicaciones 476
entorno CICS 472
entorno XA 472
finalidad 472
RELEASE no soportado 472
restricciones de la API 472
sentencia COMMIT 472
sentencia ROLLBACK 472
SQL CONNECT 472
transacciones 472
XASerialize 472
interrupcin SIGUSR1 136
interrupciones, SIGUSR1 136
ISO
estndar 10646 444
estndar 2022 444
J
japons y chino tradicional, juegos
de cdigos EUC
consideraciones en COBOL 258
Java
actualizacin de clases 289
aplicaciones
soporte con controlador de
tipo 2 292
tipo 4 293
Java (continuacin)
applets
distribucin y ejecucin 297
soporte 293
tipo 4 293
archivos de clases, dnde
colocarlos 288
archivos de salida 287
archivos fuente 287
bibliotecas de clases 288
comparaciones
con otros lenguajes 285
SQLj con JDBC 284
consideraciones sobre archivo
db2java.zip para applets 298
depuracin 313
distribucin y ejecucin de
aplicaciones 297
Enterprise Java beans 348
SQL 77
JDBC
especificacin 295
paquetes 290
paquetes y clases 294
paquetes y clases,
COM.ibm.db2.app 291
parmetro de configuracin
javaheapsz 288
jdk11path 288
seguridad 286
soporte de DB2 292
SQLCODE 335
SQLj (SQL incorporado para
Java)
applets 304
clusulas de ejemplo 306
declaracin de cursores 307
declaracin de iteradores 307
especificacin 295
iteradores 307
llamada a procedimientos
almacenados 309
restricciones 304
sentencia DELETE
posicionada 307
sentencia UPDATE
posicionada 307
sentencias de SQL
incorporado 306
Java (continuacin)
SQLj (SQL incorporado para
Java) (continuacin)
variables del lenguaje
principal 290
visin general 302
SQLMSG 335
SQLSTATE 335
variable de entorno
CLASSPATH 288
visin general 284
Java 2 Enterprise Edition
contenedores 345
Enterprise Java beans 348
gestin de transacciones 347
requisitos 346
servidor 346
soporte de aplicaciones 344
visin general 343
Java Database Connectivity (JDBC)
visin general 15
(JNDI) 346
JDBC
codificacin de aplicaciones y
applets 294
COM.ibm.db2.jdbc
.app.DB2Driver 294
COM.ibm.db2.jdbc
.net.DB2Driver 294
comparacin con SQLj 284
comparticin de sesiones con
SQLj 285
controladores 299
gestin de recursos de
conexin 286
interoperatividad de SQLj 284
visin general 15
JNDI (Java Naming and Directory
Interface) 346
JTA (API de transacciones de
Java) 347
JTS (servicio de transacciones de
Java) 347
juegos de caracteres
doble byte 441
Extended UNIX Code
(EUC) 442
varios bytes, FORTRAN 278
juegos de caracteres de doble byte
(DBCS) 441
tradicional 447
consideraciones sobre orden 447
juegos de caracteres de doble byte
(DBCS) (continuacin)
(tradicional) 444
juegos de cdigos en
japons 444
pginas de cdigos
desiguales 449
parmetros de
configuracin 443
juegos de cdigos
SQLERRMC, campo de
SQLCA 531
(tradicional)
consideraciones en C/C 215
consideraciones para REXX 372
consideraciones sobre doble
byte 447
Extended UNIX Code 447
Extended UNIX Code,
consideraciones 444
FORTRAN 278
UCS2, consideraciones 444
juegos de cdigos en japons
consideraciones en C/C 215
Extended UNIX Code,
consideraciones 444
FORTRAN 278
REXX 372
UCS2, consideraciones 444
juegos de cdigos EUD en chino
(tradicional)
consideraciones en COBOL 258
L
LANGLEVEL, opcin de
precompilacin
MIA 218
SAA1 218
variables SQL92E y SQLSTATE o
SQLCODE 224, 257, 279, 533
lectura repetible (RR)
mtodo 128
lenguaje C/C++
archivos de entrada 176
archivos de salida 176
archivos include necesarios 177
codificacin de caracteres de
mltiples bytes 210
japons 215
lenguaje C/C++ (continuacin)
programacin 176
lenguaje principal de
grficos 191
LOB 198
archivos 199
depuracin 180
expansin de macro 200
FOR BIT DATA 222
SQL 77
inicializacin de variables del
juego de caracteres 176
macro #include,
restricciones 180
macros #line, restricciones 180
manejo de series terminadas en
nulo 205
miembros de datos de clase 208
opcin WCHARTYPE del
precompilador 211
operador de calificacin,
restriccin 209
operador de miembro,
restriccin 209
puntero a tipo de datos,
declaracin en C/C 207
secuencias tri-grafo 176
sentencias de SQL
incorporado 182
soporte de estructura de sistema
principal 201
sqldbchar, tipo de datos 211
tablas de indicadores 203
tipo de datos wchart 211
tipos de datos para
funciones 223
mtodos 223
procedimientos
almacenados 223
tipos de datos soportados 218
declaracin 186
denominacin 185
finalidad 183
de grficos 191
lenguaje C/C++ (continuacin)
lenguaje de control de datos (DCL)
iSeries 530
(DDL)
emisin en punto de rescate 514
e iSeries 529
lenguaje de descripcin de servicios
Web (WSDL) 339
lenguaje de flujo de servicios Web
(WSFL) 339
lenguaje de manipulacin de datos
(DML)
iSeries 529
lenguaje de procedimientos
SQL 521
lenguaje del sistema principal
SQL 77
lenguaje REXX
API
SQLDB2 369
SQLDBS 369
SQLEXEC 369
archivos de vinculacin 384
campos decimales de SQLDA
recuperacin de datos 390
programacin 369, 370
cursores 381
datos LOB 378
LOB 378
archivos LOB 379
ejecucin de aplicaciones 383
identificadores de cursor 372
SQL 372
inicializacin de variables 387
Japons 372
llamada al CLP de DB2 385
hebras 372
procedimientos almacenados
llamada 387
visin general 387
registro de rutinas 370
ndice 559
lenguaje REXX (continuacin)
registro de SQLEXEC, SQLDBS y
SQLDB2 370
requisitos de datos
cliente 389
servidor 389
restricciones 370
sintaxis de API 385
tipos de datos 381
denominacin 375
finalidad 374
referencia 375
LOB, borrado 380
variables predefinidas 376
liberacin de conexiones,
aplicaciones CMS 45
local
elusin 479
lgica de aplicacin
activadores 59
control de relaciones de
datos 58
funciones definidas por el
usuario 59
procedimientos almacenados 59
servidor 59
M
macro #include
macro automtica de herramientas
de IBM DB2 Universal Database
para Microsoft Visual C 74
macro automtica de proyectos de
IBM DB2 Universal Database para
Microsoft Visual C
activacin 73
finalidad 69
macros #line
mandato BIND
creacin de paquetes 89
opcin INSERT BUF 480
mandato BIND PACKAGE
volver a vincular 98
mandato PREP (PRECOMPILE)
descripcin 84
ejemplo 84
mandatos
FORCE
diferencias entre
plataformas 531
manejadores de excepciones
consideraciones sobre COMMIT y
ROLLBACK 136
finalidad 136
manejadores de interrupciones
ROLLBACK 136
finalidad 136
manejadores de seales
con sentencias de SQL 136
ROLLBACK 136
finalidad 136
instalacin, programas de
ejemplo 132
manejo de errores
aplicaciones en bucle 496
aplicaciones suspendidas 496
archivos include
C/C 177
COBOL 234
FORTRAN 263
durante la precompilacin 84
entorno de bases de datos
particionadas 493
particionadas 494
estructuras de SQLCA
varias estructuras
fusionadas 495
identificacin de la particin de
base de datos que devuelve el
error 496
notificacin 495
Perl 366
precompilador de lenguaje
C/C 180
sentencia WHENEVER 41
SQLCODE 495
utilizacin del SQLCA 40
manejo de interrupciones con
manuales de DB2
peticin 560
manuales impresos, solicitud 560
marcador de parmetro
tipificado 166
ejemplo de programacin 167
(continuacin)
en proceso de sentencias
arbitrarias 164
entradas SQLVAR 166
Perl 365
tipificados 166
uso en SQL dinmico 166
uso en SQLExecDirect 169
memoria
asignacin para pginas de
cdigos desiguales 449
mensajes de aviso
truncamiento 110
mensajes de error
distintivo de condicin de
aviso 134
error 134
excepcin 134
estructura SQLWARN 134
SQLSTATE 134
mtodos
visin general 24
mtodos definidos por el usuario
llamada, SQLJ 309
Microsoft OLE DB Provider para
ODBC
soporte de OLE DB 403
Microsoft Visual C
macro automtica de proyectos
de IBM DB2 Universal
Database 69
miembros de datos de clase
en C/C 208
modelo para programacin de
DB2 49
MQSeries
soporte de aplicaciones 21
mltiples bytes, consideraciones
japons y chino tradicional,
juegos de cdigos EUC
COBOL 258
(tradicional)
C/C 215
FORTRAN 278
REXX 372
juegos de cdigos en japons
C/C 215
FORTRAN 278
REXX 372
N
naturaleza asncrona de las
intermedio 483
Net.Data
visin general 21
niveles de aislamiento
lectura repetible (RR) 128
niveles de versin
IBM OLE DB Provider para
DB2 391
NOLINEMACRO, opcin PREP 180
nombres de paquetes
entornos de pginas de cdigos
mixtas 435
numricos, tipos de datos
diferencias entre
plataformas 529
O
objetos de SQL
representacin con variables 35
objetos en secuencia
comparacin con columnas de
identidad 506
comportamiento, control 504
finalidad 502
rendimiento de aplicacin 505
objetos grandes (LOB)
aplicaciones 26
ODBC (Open Database Connectivity)
herramientas de desarrollo de
aplicaciones 18
OLE DB
conexiones con fuentes de datos
mediante IBM OLE DB
Provider 409
conversin de datos
de OLE DB a tipos DB2 398
de tipos DB2 a tipos OLE
DB 400
correlaciones de tipos de datos
con DB2 396
funciones de tabla
visin general 29
propiedades soportadas 406
servicios habilitados
automticamente 396
soportado en DB2 17
soporte de BLOB 403
soporte de componentes e
interfaces 403
OLE DB (continuacin)
soporte de conjunto de filas 403
soporte de mandatos 403
soporte de sesiones 403
soporte para ver objetos 403
opcin de precompilacin MIA
LANGLEVEL 218
opcin de precompilacin SAA1
LANGLEVEL 218
opcin de vinculacin
EXPLSNAP 93
opcin de vinculacin
FUNCPATH 93
opcin de vinculacin INSERT BUF
intermedio 480
opcin de vinculacin
QUERYOPT 93
opcin DYNAMICRULES
efectos en SQL dinmico 147
opcin PREP, NOLINEMACRO 180
opciones de vinculacin
EXPLSNAP 93
FUNCPATH 93
QUERYOPT 93
operador de miembro, restriccin en
C/C 209
optimizador
consideraciones sobre SQL
esttico y dinmico 141
orden de clasificacin
archivos include
C/C 177
COBOL 234
FORTRAN 263
caracteres de varios bytes 422
comparaciones de caracteres 424
comparaciones que no dependen
de maysculas y
minsculas 424
EBCDIC y ASCII 535
ejemplo de orden de
clasificacin 426
ejemplo de orden de clasificacin
EBCDIC y ASCII 426
ejemplos 429
especificacin 427
funcin TRANSLATE 424
punto de cdigo 422
secuencia de identidad 422
simulacin de orden binario
EBCDIC 543
temas generales 422
visin general 422
orden de clasificacin definido por el
usuario 535, 543
P
pgina HTML
codificacin para applets
Java 297
pginas de cdigos
asignacin de almacenamiento
para situaciones
desiguales 449
vinculacin 93
conversin
servidor OS/390 529
entornos nacionales
obtencin 430
manejo de expansiones en el
servidor 449
manejo de expansiones en la
aplicacin 449
pginas de cdigos de
Windows 430
para ejecucin de aplicacin 436
para precompilacin y
vinculacin 436
situaciones desiguales 440, 449
soporte de idioma nacional
(NLS) 436
SQLERRMC, campo de
SQLCA 531
variable de registro
DB2CODEPAGE 430
pginas de cdigos de doble
byte 446
pginas de cdigos de varios bytes
(tradicional) 444
juegos de cdigos en
japons 444
pginas de cdigos desiguales 449
asignacin de
almacenamiento 449
paquetes
atributos, por plataforma 532
creacin 82, 89
descripcin 95
errores de indicacin horaria 96
inoperativo 98
no vlido
estado 98
ndice 561
paquetes (continuacin)
revinculacin durante unidad de
trabajo
comportamiento de
cursor 120
soporte de aplicaciones
REXX 384
versiones, privilegios 90
versiones con mismo nombre 90
javaheapsz 288
jdk11path 288
locktimeout 231
parmetros de COLLECTION 92
parmetros de configuracin
actualizacin mltiple 467
locktimeout 231
javaheapsz 288
jdk11path 288
particin coordinadora, sin
intermedio 480
pase de contextos entre hebras 227
Perl
conexin con base de datos 364
programacin 363
controladores 363
devolucin de datos 364
ejemplo de aplicacin 366
especificacin Interfaz de bases
de datos (DBI) 18
marcadores de parmetros 365
hebras 364
restricciones 363
SQLCODE 366
SQLSTATE 366
peso, definicin 422
PICTURE (PIC), clusula en los tipos
de COBOL 254
portabilidad cuando se utiliza CLI
en lugar de SQL incorporado 171
precompilacin 86
acceso a servidor de aplicaciones
de sistema principal o AS/400 a
travs de DB2 Connect 86
acceso a varios servidores 86
ejemplo 84
FORTRAN 262
precompilacin (continuacin)
indicaciones horarias 96
opcin de cursor
actualizable 125
programa de utilidad del
marcador 86
seal de coherencia 96
soporte de sentencias de SQL
dinmico 140
visin general 84
precompilador
COBOL 233
depuracin en lenguaje
C/C 180
FORTRAN 261
juego de caracteres de C/C 176
lenguaje C/C 209
nmero de seccin 541
opcin LANGLEVEL
SQL92E 533
opciones 84
secuencias de tri-grafo de
C/C 176
tipos de salida 84
visin general 77
PREPARE, sentencia
finalidad 140
no soportada en DB2
Connect 541
proceso de sentencias
arbitrarias 163
aplicaciones REXX 387
aplicacin 59
conversin de caracteres,
EUC 457
inicializacin
variables REXX 387
(tradicional) 447
juegos de cdigos en
japons 447
llamada
REXX 387
SQLj 309
visin general 23
procesador de lnea de mandatos
(CLP)
llamada desde aplicacin
REXX 385
prototipo 50
procesador de lnea de mandatos
(CLP) (continuacin)
sentencias de SQL
soportadas 521
valores de antememoria de
variable de entorno
DB2INCLUDE 180
programa de utilidad del marcador
utilizacin en precompilacin 86
programas de aplicacin
estructura 33
requisitos previos 32
sentencias necesarias 34
SQLj
ejemplo de ejecucin 310
programas de utilidad, API de
archivo include
archivo include para aplicaciones
C/C 177
archivos include
propiedades
propiedades de OLE DB
soportadas 406
punto de cdigo 422
definicin 422
puntos de rescate
activadores 514
anidados 514
comparacin con SQL
compuesto 511
consideraciones sobre bloqueo de
cursor 516
control 513
creacin 513
gestin de transacciones 509
gestores de transacciones
XA 517
intermedio 480, 515
(DDL) 514
restricciones 514
SET INTEGRITY, sentencia 514
SQL compuesto atmico 514
puntos muertos
en aplicaciones de varias
hebras 230
error en insercin en
almacenamiento
intermedio 483
evitacin de varios
contextos 231
puntos muertos (continuacin)
evitar en transacciones
simultneas 471
Q
QSQ en campo SQLERRP para
iSeries 531
R
rastreo de CLI/ODBC/JDBC
archivos de rastreo 324
recurso de rastreo 313
rastreos
CLI/ODBC/JDBC 313
recuperacin de asignaciones
desbordamientos por conversin
numrica 537
recuperacin de datos
Perl 364
SQL esttico 105
recurso Explain
prototipo 50
REDEFINES, COBOL 252
registro de notificacin de
administracin
particionadas 494
registro especial CURRENT
EXPLAIN MODE
efecto en SQL dinmico
vinculado 91
registro especial CURRENT PATH
vinculado 91
registro especial CURRENT QUERY
OPTIMIZATION
vinculado 91
registros de transacciones,
intermedio 480
registros especiales
CURRENT EXPLAIN MODE 91
CURRENT PATH 91
CURRENT QUERY
OPTIMIZATION 91
remota, unidad de trabajo
finalidad 461
rendimiento
clusula FOR UPDATE 124
columnas de identidad 500
compilacin de sentencias de
SQL esttico 95
cursores de solo lectura 125, 477
rendimiento (continuacin)
factores que afectan, SQL
esttico 101
intermedio 480
liberacin de bloqueos 120
optimizacin con paquetes 95
SQL dinmico 102, 141
SQL esttico 102
subsecciones distribuidas,
dirigidas 478
rendimiento de aplicacin
comparacin de objetos de
secuencia y columnas de
identidad 506
elusin local 479
objetos en secuencia 505
tablas temporales
declaradas 506
REORGANIZE TABLE, mandato
pginas de cdigos mixtas 446
requisitos del sistema
IBM 0LE DB Provider para
DB2 391
resolucin de problemas
bsqueda de documentacin de
DB2 570
informacin en lnea 572
restricciones
COBOL 234
en C/C 200
FORTRAN 262
intermedio 486
REXX 370
restricciones de API principal JDBC
2.1
controlador de tipo 4 300
restricciones de COBOL orientadas a
objetos 259
restricciones de comprobacin de
tabla
restricciones exclusivas
restricciones referenciales
RESULT, variable predefinida de
REXX 376
retrotraer cambios 46
ROWID, tipo de datos
RUOW
consulte unidad de trabajo
remota 461
rutina de seccin crtica, en varias
hebras 230
rutina SQLDB2, registro para
REXX 370
rutina SQLDBS, registro para
REXX 370
rutinas
automatizacin de OLE, visin
general 28
rutinas de automatizacin de
OLE 28
rutinas de salida
restricciones de uso 137
S
seccin de declaracin
C/C 216
COBOL 242
creacin 34
en C/C 186
en COBOL 253
FORTRAN 270, 276
normas para sentencias 106
secciones crticas 230
secuencia de identidad 422
secuencias de tri-grafo, C/C++ 176
seguridad
Java 286
seleccin completa
consideraciones sobre las
intermedio 486
semforos 230
sentencia BEGIN DECLARE
SECTION 34
sentencia COMMIT
asociacin con cursor 120
finalizacin de transaccin 45
finalizacin de transacciones 48
sentencia CONNECT
valores de
SQLCA.SQLERRD 449
sentencia CONNECT RESET 48
sentencia CREATE SEQUENCE 502
sentencia DECLARE CURSOR
adicin a una aplicacin 43
descripcin 119
sentencia DESCRIBE 541
consideraciones sobre Extended
UNIX Code 454
ndice 563
sentencia DESCRIBE (continuacin)
no soportada en DB2
Connect 541
proceso de sentencias
arbitrarias 163
sentencia END DECLARE
SECTION 34
sentencia EXEC SQL INCLUDE
sentencia EXECUTE
finalidad 140
sentencia EXECUTE IMMEDIATE
finalidad 140
sentencia FETCH
acceso repetido a datos 128
estructura de SQLDA 157
principal 150
sentencia INCLUDE 43
sentencia INCLUDE SQLCA
seudocdigo 40
sentencia INCLUDE SQLDA 43
creacin de estructura de
SQLDA 158
sentencia LABEL ON, no
soportada 541
sentencia PUT, no soportada en DB2
Connect 541
sentencia RELEASE
SAVEPOINT 513
sentencia ROLLBACK
asociacin con cursor 120
deshacer los cambios 46
diferencias entre
plataformas 531
finalizacin de transacciones 48
retrotraer cambios 46
sentencia ROLLBACK TO
SAVEPOINT
comportamiento de cursor 514
sentencia ROLLBACK WORK
RELEASE
no soportada en DB2
Connect 541
sentencia SAVEPOINT
control de transacciones 513
sentencia SELECT
actualizacin de datos
recuperados 131
asociacin con sentencia
EXECUTE 140
declaracin en SQLDA 151
descripcin despus de asignar
SQLDA 156
sentencia SELECT (continuacin)
intermedio 483
lista variable 164
recuperacin
datos una segunda vez 129
varias filas 118
sentencia DECLARE
CURSOR 119
sentencia SET CURRENT, no
soportada en DB2 Connect 541
sentencia SET CURRENT
PACKAGESET 92
sentencia WHENEVER
sentencias
ACQUIRE, no soportada en DB2
UDB 541
BEGIN DECLARE SECTION 34
CALL, plataformas
soportadas 537
CALL USING
DESCRIPTOR 537
colocacin en antememoria,
WebSphere 358
COMMIT 45
COMMIT WORK RELEASE 541
CONNECT 531
CREATE SEQUENCE 502
DB2 Connect
no soportadas 541
soportados 541
DECLARE, no soportada en DB2
UDB 541
DECLARE CURSOR 43
DESCRIBE 541
END DECLARE SECTION 34
INCLUDE 43
INCLUDE SQLCA 40
INCLUDE SQLDA 43
LABEL ON, no soportada en DB2
UDB 541
preparacin mediante estructura
de SQLDA mnima 153
RELEASE SAVEPOINT 513
ROLLBACK
diferencias entre
plataformas 531
finalizacin de
transacciones 46
tablas temporales
declaradas 506
ROLLBACK TO
SAVEPOINT 513
SAVEPOINT 513
sentencias de SQL
aplicaciones de actualizacin
mltiple 463
CONNECT
valores de
SQLCA.SQLERRD 449
guardar peticiones de usuario
final 165
manejadores de excepciones 136
manejadores de
interrupciones 136
manejadores de seales 136
REXX 372
sintaxis de C/C 182
sintaxis en COBOL 237
sintaxis en FORTRAN 267
sintaxis en REXX 372
sentencias de SQL dinmico
no soportada en DB2
Connect 541
sentencias de SQL no ejecutables
DECLARE CURSOR 43
INCLUDE 43
INCLUDE SQLDA 43
sentencias dinmicas
vinculacin 91
seal de coherencia 96
seales
truncamiento, estructura de
SQLCA 135
series
opcin C, CNULREQD BIND
terminada en nulo 533
series C terminadas en nulo 533
series grficas
series terminadas en nulo
opcin CNULREQD BIND 533
servicio de transacciones de Java
(JTS) 347
servicios en tiempo de ejecucin
varias hebras
efecto en enganches 227
servicios Web
acceso a datos de DB2 341
archivo de extensin de
definicin de acceso a
documentos (DADX) 343
arquitectura 339
consulta basada en SQL 342
consulta basada en XML 342
documentos 342
definicin de operaciones 343
finalidad 337, 339
servicios Web (continuacin)
infraestructura basada en
XML 337
seguridad 339
smbolos
sustituciones, restricciones del
lenguaje C/C++ 200
Simple Object Access Protocol
(SOAP), mensajes XML y sobres
SOAP 339
sintaxis
declaraciones de indicador LOB,
REXX 378
SQL
REXX 372
seccin de declaracin
C/C++ 186
COBOL 242
FORTRAN 270
sentencias de SQL incorporado
C/C++ 182
COBOL 237
comentarios, C/C++ 182
comentarios, COBOL 237
comentarios, FORTRAN 267
comentarios, REXX 372
evitar divisin de lnea 182
FORTRAN 267
sustitucin de caracteres de
espacio en blanco 182
de tipo carcter 190
sistemas principales
principal 469
solicitud de manuales de DB2 560
soporte de caracteres de varios bytes
puntos de cdigo para caracteres
especiales 433
soporte de estructura de sistema
principal
C/C 201
soporte de idioma nacional (NLS)
pgina de cdigos 436
soporte de MTS
habilitacin en DB2 418
soporte de transacciones distribuidas
MTS y COM
SQL, archivo include
SQL, archivo include (continuacin)
SQL, ejecucin de sentencias
colocacin en serie 227
SQL (Structured Query Language)
autorizacin
API 63
SQL dinmico 61
SQL esttico 63
SQL incorporado 60
preparado dinmicamente 169
SQL compuesto
comparacin con puntos de
rescate 511
SQL compuesto NOT ATOMIC
SQL dinmico
colocacin en antememoria
de 102
comparacin con SQL
esttico 101, 141
consideraciones 141
autorizacin 61
cursores, programa de
ejemplo 145
declaracin de SQLDA 151
definicin 140
determinacin de tipo de
sentencia arbitraria 164
efectos de
DYNAMICRULES 147
finalidad 139
limitaciones 140
marcadores de parmetros 166
normas de sintaxis 140
PREPARE, sentencia 140, 150
proceso de cursor 144
proceso de cursores 158
rendimiento 141
sentencia DESCRIBE 140, 150
sentencia EXECUTE 140
sentencia EXECUTE
IMMEDIATE 140
sentencia FETCH 150
sentencias arbitrarias, proceso
de 163
sentencias de SQL
soportadas 521
sentencias soportadas 140
soporte de Perl 363
supresin de filas 124
SQL dinmico incorporado 13
SQL esttico
consideraciones 141
ejemplo de programacin de
actualizacin esttica 132
Perl, no soportado 363
precompilacin, ventajas 95
programa de cursor de
ejemplo 122
recuperacin de datos 105
rendimiento 102
SQL dinmico
comparacin 101, 141
utilizacin de variables de
sistema principal 106
visin general 101
SQL incorporado
COBOL 237
columnas generadas 499
comentarios
COBOL 237
normas 267
comentarios en C/C 182
ejemplos 77
generacin de valores
secuenciales 502
Java
clusulas de ejemplo 306
iteradores 307
normas
C/C 182
normas, FORTRAN 267
normas de sintaxis 77
normas para comentarios
C/C 182
referencia a variables del lenguaje
principal 106, 110
visin general 9, 77
SQL incorporado para Java (SQLJ)
visin general 17
SQL_WCHART_CONVERT, macro
del preprocesador 211
SQL1252A, archivo include
SQL1252B, archivo include
SQLADEF, archivo include
SQLAPREP, archivo include
ndice 565
SQLAPREP, archivo include
(continuacin)
SQLCA, archivo include
SQLCA (rea de comunicaciones de
SQL)
campo SQLERRP identifica
RDBMS 531
hebras 229
informe de errores en inserciones
en almacenamiento
intermedio 483
inserciones incompletas cuando
se producen errores 483
SQLERRMC, campo 531, 539
SQLCA, variable predefinida 376
SQLCA_92, archivo include
SQLCA_92, estructura 263
SQLCA_CN, archivo include 263
SQLCA_CS, archivo include 263
SQLCLI, archivo include 177
SQLCLI1, archivo include 177
SQLCODE
autnoma 533
campo, estructura de
SQLCA 134
cdigos de error 40
diferencias entre
plataformas 536
estructura 134
inclusin de SQLCA 40
programas Java 335
SQLCODE -1015
particionadas 494
SQLCODE -1034
particionadas 494
SQLCODE -30081
particionadas 494
SQLCODES, archivo include
SQLDA, archivo include
SQLDA, archivo include
(continuacin)
SQLDA (rea de descriptor de SQL)
hebras 229
SQLDACT, archivo include 263
SQLDB2, API de REXX 369, 385
sqldbchar, tipo de datos
seleccin 211
tipo de columna
equivalente 218
SQLDBS, API de REXX 369
SQLE819A, archivo include
SQLE819B, archivo include
sqleAttachToCtx(), API 227
SQLEAU, archivo include
sqleBeginCtx(), API 227
sqleDetachFromCtx(), API 227
sqleEndCtx(), API 227
sqleGetCurrentCtx(), API 227
sqleInterruptCtx(), API 227
SQLENV, archivo include
SQLERRD(1) 440, 449
SQLERRD(2) 440, 449
SQLERRD(3) 472
SQLERRMC, campo de
SQLCA 440, 531, 539
SQLERRP, campo de SQLCA 531
sqleSetTypeCtx(), API 227
SQLETSD, archivo include 234
SQLException
manejo 137
recuperacin de SQLCODE 335
recuperacin de SQLMSG 335
recuperacin de SQLSTATE 335
SQLEXEC, API de REXX
proceso de sentencias de
SQL 372
registro 370
SQL incorporado 369
SQLEXT, archivo include
aplicaciones CLI 177
SQLISL, variable predefinida 376
SQLj (SQL incorporado para Java)
aplicaciones
ejemplos 310
applets
restricciones 304
clusulas, ejemplos 306
comparacin con Java Database
Connectivity (JDBC) 284
comparticin de sesiones con
JDBC 285
cursores, declaracin 307
interoperatividad de Java
Database Connectivity
(JDBC) 284
iteradores 307
opciones de conversor 312
llamada 309
programas
ejemplo 308
restricciones 304
sentencia DELETE,
posicionada 307
sentencia UPDATE,
posicionada 307
sentencias de SQL
incorporado 306
principal 290
visin general 302
SQLJACB, archivo include
SQLMON, archivo include
SQLMON, archivo include
(continuacin)
para aplicaciones C/C 177
SQLMONCT, archivo include 234
SQLMSG, variable predefinida 376
SQLRDAT, variable predefinida 376
SQLRIDA, variable predefinida 376
SQLRODA, variable
predefinida 376
SQLSTATE
autnoma 533
diferencias 536
en CLI 169
programas Java 335
SQLSTATE, archivo include
SQLSYSTM, archivo include 177
SQLUDF, archivo include
SQLUTBCQ, archivo include 234
SQLUTBSQ, archivo include 234
SQLUTIL, archivo include
SQLUV, archivo include
SQLUVEND, archivo include 177
SQLXA, archivo include
Structured Query Language (SQL)
sentencias soportadas
(CLI) 521
lenguaje de procedimientos
SQL 521
Procesador de lnea de
mandatos (CLP) 521
SQL dinmico 521
subseccin distribuida (DSS)
dirigida 478
sucesos asncronos 227
SYSIBM.SYSPROCEDURES, catlogo
(OS/390) 537
T
tablas
autorreferentes 535
colocacin del cursor al
final 131
columnas generadas 499
tablas (continuacin)
confirmacin de cambios 45
no conectado inicialmente,
creacin en punto de
rescate 514
nombres, resolucin de no
calificados 92
recuperacin de filas,
ejemplo 126
resolucin de nombres no
calificados 92
temporal, declarada 506
temporal declarada
creacin en punto de
rescate 514
creacin fuera de punto de
rescate 514
tablas de indicadores
C y C 203
soporte de COBOL 251
tablas de prueba, creacin 65
tablas temporales
declarada 506
tablas temporales declaradas
finalidad 506
terminador nulo
datos grficos de longitud
variable, proceso 218
territorio, campo SQLERRMC de
SQLCA 531
tipo blob CC 218
tipo blob_file CC 218
tipo blob_locator CC 218
tipo CC de formato de caracteres
terminado en nulo 218
tipo clob_file CC 218
tipo clob_locator CC 218
tipo char CC 218
tipo dbclob_file CC 218
tipo dbclob_locator CC 218
Tipo de datos BIGINT
en SQL esttico 113
tipo de datos BLOB 113
COBOL 254
conversin a C y C++ 218
FORTRAN 276
Java 291
REXX 381
tipo de datos BLOB_FILE
FORTRAN 276
tipo de datos BLOB FORTRAN 276
tipo de datos BLOB_LOCATOR
FORTRAN 276
tipo de datos CLOB (objeto grande
de caracteres)
C/C 222
C y C++ 218
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
REXX 381
tipo de datos CLOB_FILE
FORTRAN 276
tipo de datos CLOB FORTRAN 276
tipo de datos CLOB_LOCATOR
FORTRAN 276
tipo de datos COMP
COBOL 257
tipo de datos COMP-4
COBOL 257
tipo de datos CHAR 113
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
REXX 381
tipo de datos CHARACTER*n
FORTRAN 276
tipo de datos DATE 113
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
REXX 381
tipo de datos DBCLOB
CC, conversin 218
COBOL 254
en C y C++ 218
en programas de SQL
esttico 113
Java 291
(tradicional) 447
juegos de cdigos en
japons 447
REXX 381
tipo de datos de SQL BIGINT
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
tipo de datos DECIMAL
CC, conversin 218
COBOL 254
en SQL esttico 113
ndice 567
tipo de datos DECIMAL
(continuacin)
FORTRAN 276
Java 291
REXX 381
tipo de datos DOUBLE 113
tipo de datos FLOAT 113
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
REXX 381
tipo de datos FOR BIT DATA
C/C 222
tipo de datos GRAPHIC
CC, conversin 218
COBOL 254
FORTRAN, no soportado 276
Java 291
REXX 381
seleccin 211
tipo de datos INTEGER 113
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
REXX 381
tipo de datos INTEGER*2
FORTRAN 276
tipo de datos INTEGER*4
FORTRAN 276
tipo de datos integer de 64 bits
tipo de datos Java
BigDecimal 291
Blob 291
Double 291
Int 291
java.math.BigDecimal 291
Short 291
String 291
tipo de datos Java BigDecimal 291
tipo de datos Java double 291
tipo de datos Java Int 291
tipo de datos Java
java.math.BigDecimal 291
tipo de datos Java short 291
tipo de datos Java String 291
tipo de datos LONG VARCHAR
C/C++, conversin 218
COBOL 254
en programas de SQL
esttico 113
FORTRAN 276
Java 291
tipo de datos LONG VARCHAR
(continuacin)
REXX 381
tipo de datos LONG VARGRAPHIC
COBOL 254
en programas de SQL
esttico 113
FORTRAN 276
Java 291
REXX 381
tipo de datos NUMERIC
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
REXX 381
tipo de datos REAL
CC, conversin 218
COBOL 254
FORTRAN 276
Java 291
lista 113
REXX 381
tipo de datos REAL*2
FORTRAN 276
FORTRAN 276
FORTRAN 276
tipo de datos SMALLINT
COBOL 254
FORTRAN 276
Java 291
REXX 381
sentencia CREATE TABLE 113
tipo de datos TIME
COBOL 254
en sentencia CREATE
TABLE 113
FORTRAN 276
Java 291
REXX 381
tipo de datos TIMESTAMP
COBOL 254
descripcin 113
FORTRAN 276
Java 291
REXX 381
tipo de datos VARCHAR
C o C++ 222
tipo de datos VARCHAR
(continuacin)
COBOL 254
en columnas de tablas 113
formato estructurado,
C/C++ 218
FORTRAN 276
Java 291
REXX 381
tipo de datos VARGRAPHIC
C/C++ 218
COBOL 254
FORTRAN 276
Java 291
lista 113
REXX 381
tipo double CC 218
tipo float CC 218
tipo long C/C++ 218
tipo long int C/C++ 218
tipo long long C/C++ 218
tipo long long int C/C++ 218
tipo short C/C++ 218
tipo short int C/C++ 218
tipo sqlint64 CC 218
tipos de datos
BINARY
COBOL 257
C/C 218
CC, conversin 218
CLOB en C/C 222
COBOL 254
UNIX Code 456
conversin
entre DB2 y COBOL 254
entre DB2 y FORTRAN 276
entre DB2 y REXX 381
conversin entre DB2 y CC 218
DATALINK
variable del lenguaje
principal, restriccin 276
DECIMAL
FORTRAN 276
de caracteres 457
descripcin 34
FOR BIT DATA
COBOL 257
FOR BIT DATA en C/C 222
FORTRAN 276
Java 291
tipos de datos (continuacin)
lenguaje de sistema principal y
correspondencias en DB2 113
miembros de datos de clase,
declaracin en C/C 208
numricos
diferencias entre
plataformas 529
puntero a, declaracin en
C/C 207
ROWID
soportado por DB2
Connect 529
seleccin de tipos grficos 211
soportados 113
COBOL, normas 254
FORTRAN, normas 276
temas sobre compatibilidad 113
VARCHAR en C/C 222
tipos de datos BINARY
COBOL 257
tipos de datos de C/C++
blob 218
blob_file 218
blob_locator 218
clob 218
clob_file 218
clob_locator 218
char 218
dbclob 218
dbclob_file 218
dbclob_locator 218
double 218
float 218
formato de caracteres terminado
en nulo 218
formato estructurado
VARCHAR 218
long 218
long int 218
long long 218
long long int 218
short 218
short int 218
sqldbchar 218
sqlint64 218
wchart 218
tipos de datos de REXX 381
tipos de datos de SQL
BIGINT 113
BLOB 113
CLOB 113
COBOL 254
conversin a CC 218
CHAR 113
tipos de datos de SQL (continuacin)
DATE 113
DBCLOB 113
DECIMAL 113
FLOAT 113
FORTRAN 276
INTEGER 113
Java 291
LONG VARCHAR 113
LONG VARGRAPHIC 113
REAL 113
REXX 381
SMALLINT 113
TIME 113
TIMESTAMP 113
VARCHAR 113
VARGRAPHIC 113
tipos de datos LOB (objeto grande)
declaraciones de datos en
C/C++ 195
declaraciones de localizador en
C/C++ 198
tipos definidos por el usuario (UDT)
aplicaciones 26
tipos diferenciados
tipos estructurados
no soportados en DB2
Connect 529
transacciones
codificacin 44
coherencia de datos 44
confirmacin de trabajo 45
deshacer cambios con sentencia
ROLLBACK 46
finalizacin
sentencia COMMIT 48
sentencia CONNECT
RESET 48
finalizacin implcita 48
simultnea
evitar puntos muertos 471
finalidad 469
transacciones, supervisores del
proceso
Interfaz XA de X/Open 472
transacciones simultneas
evitar puntos muertos 471
transacciones simultneas
(continuacin)
finalidad 469
transferencia de datos
actualizacin 131
transmisin de grandes volmenes
de datos 517
truncamiento
principal 110
U
ubicacin de archivos include,
FORTRAN 266
UCS-2 444
UDF (funciones definidas por el
usuario)
llamada
SQLj 309
Unicode (UCS-2)
consideraciones sobre UDF
(funcin definida por el
usuario) 447
(tradicional) 444
juegos de cdigos en
japons 444
Unicode (UCS2)
de caracteres 457
unidad de trabajo 44
cursor 120
finalizacin
comportamiento de
cursor 120
remota 461
unidad de trabajo distribuida 461
USAGE, clusula en los tipos de
COBOL 254
V
validacin de parmetros basada en
el cliente
UNIX Code 453
valor NULL
variable de indicador para recibir
valor NULL 110
valor SQLMSG en Java 335
Valores de SQLCA.SQLERRD en
CONNECT 449
ndice 569
valores secuenciales
generacin 502
variable de entorno
CLASSPATH 288
DB2CODEPAGE 430
variables
declaracin 34
interactuacin con gestor de
bases de datos 34
representacin de objetos de
SQL 35
REXX, predefinido 376
SQLCODE 224, 257, 279
SQLSTATE 224, 257, 279
variables de entorno
DB2INCLUDE 180, 266
variables de indicador
C/C 191
COBOL 246
declaracin 110
durante INSERT o UPDATE 110
finalidad 110
FORTRAN 273
REXX 375
truncamiento 110
utilizacin en columnas que
pueden tener valores null 116
COBOL, tipos de datos 254
codificacin de caracteres de
mltiples bytes 210
datos grficos 191
declaracin
C/C 186
COBOL 242
ejemplos 108
FORTRAN 270
normas 106
utilizacin de sentencia de
lista de variables 164
declaracin como punteros a
tipos de datos 207
declaracin de grficas
COBOL 245
LOB
COBOL 248
declaraciones de datos grficos
C/C 191
declaraciones de datos LOB
C/C 195
COBOL 246
REXX 378
(continuacin)
declaraciones de LOB
FORTRAN 273
LOB
C/C 198
FORTRAN 274
REXX 378
archivos
COBOL 248
FORTRAN 275
REXX 379
archivos en C/C 199
definicin 106
definicin para utilizar con
columnas 39
denominacin
C/C 185
COBOL 241
FORTRAN 269
REXX 375
en sentencia de lenguaje de
sistema principal 106
en sentencia de SQL 106
en SQL dinmico 140
finalidad 183
FORTRAN 269
grfico
FORTRAN 278
inicializacin en C/C 200
LOB
borrado en REXX 380
miembros de datos de clase en
C/C 208
no soportado en Perl 364
opcin WCHARTYPE del
precompilador 211
precompilador considera como
global en un mdulo en
C/C 185
referencia
C/C 183
COBOL 240
FORTRAN 267
REXX 375
referencia desde SQL 106, 110
relacionadas con sentencia de
SQL 39
restriccin de DATALINK 276
REXX
finalidad 374
(continuacin)
seleccin de tipos de datos
grficos 211
series terminadas en nulo,
manejo en C/C 205
SQL esttico 106
SQLj 290
truncamiento 110
variables del lenguaje principal de
grficos
C/C 192
COBOL 245
variables del lenguaje principal de
tipo carcter
fijas y terminadas en nulo en
C/C 189
FORTRAN 271
longitud de variable en
C/C 190
numricas
C/C 187
COBOL 242
FORTRAN 271
vinculacin
consideraciones 93
diferir 94
opciones 89
programa de utilidad de
descripcin de archivos de
vinculacin, db2bfd 95
sentencias dinmicas 91
visin general 89
violacin de clave exclusiva,
intermedio 483
vistas
catlogos del sistema 537
vistas de prueba, creacin 65
vistas del catlogo del sistema
programa de utilidad de creacin
de prototipos 50
Visual Basic
aplicaciones
conexin con fuente de
datos 410
consideraciones sobre cursor 411
soportado en DB2 17
soporte de control de datos 411
Visual C
macro automtica de proyectos
de IBM DB2 Universal
Database 69
Visual C (continuacin)
soportado en DB2 17
volver a vincular
descripcin 98
mandato REBIND PACKAGE 98
W
wchar_t, tipo de datos
seleccin 211
WCHARTYPE
directrices 211
opcin de precompilacin 211
tipos de datos disponibles con la
opcin NOCONVERT 218
WebSphere
acceso a datos de la
empresa 351
agrupacin de conexiones
ajuste 352
beneficios 357
finalidad 351
colocacin en antememoria de
sentencias 358
fuentes de datos 351
WebSphere Studio 19
Windows
pginas de cdigos 430
DB2CODEPAGE 430
X
XML
acceso a aplicacin
reiniciada 339
consultas 342
documentos 342
infraestructura para servicios
Web 337
lenguaje de descripcin de
servicios Web (WSDL) 339
mensajes XML en sobres
SOAP 339
XML Extender
visin general 20
ndice 571
Informacin tcnica sobre DB2 Universal Database
Visin general de la informacin tcnica de DB2 Universal Database
La informacin tcnica de DB2 Universal Database puede obtenerse en los
formatos siguientes:
v Manuales (formatos PDF y copia impresa)
v Un rbol de temas (formato HTML)
v Herramientas de ayuda para DB2 (formato HTML)
v Programas de ejemplo (formato HTML)
v Ayuda de lnea de mandatos
v Guas de aprendizaje
Esta seccin es una visin general de la informacin tcnica que se
proporciona y del modo en que se puede acceder a ella.
FixPaks para la documentacin de DB2
IBM puede poner peridicamente a disposicin del usuario FixPaks de
documentacin. Los FixPaks de documentacin permiten actualizar la
informacin que se instal desde el CD de documentacin HTML de DB2 a
medida que aparece nueva informacin.
Nota: Si instala los FixPaks de documentacin, la documentacin HTML
contendr informacin ms reciente que los manuales de DB2 en
formato PDF en lnea o impresos.
Categoras de la informacin tcnica de DB2
La informacin tcnica de DB2 se clasifica por categoras con las cabeceras
siguientes:
v Informacin bsica de DB2
v Informacin de administracin
v Informacin para el desarrollo de aplicaciones
v Informacin de Inteligencia empresarial
v Informacin de DB2 Connect
v Informacin de iniciacin
v Informacin de aprendizaje
v Informacin sobre componentes opcionales
v Notas del release
Las tablas siguientes describen, para cada manual de la biblioteca de DB2, la
informacin necesaria para solicitar la copia impresa, imprimir o ver el PDF o
localizar el directorio de HTML de dicho manual. En el Centro de
publicaciones de IBM de la direccin www.ibm.com/shop/publications/order
se encuentra disponible una descripcin completa de cada uno de los
manuales de la biblioteca de DB2.
El directorio de instalacin del CD de documentacin HTML es diferente para
cada categora de informacin:
vaaccesocdhtml/doc/htmlcd/%L/categora
donde:
v vaaccesocdhtml es el directorio donde est instalado el CD de HTML.
v %L es el identificador de idioma. Por ejemplo, es_ES.
v categora es el identificador de categora. Por ejemplo, core para la
informacin bsica de DB2.
En la columna de nombre de archivo PDF de las tablas siguientes, el carcter
situado en la sexta posicin del nombre de archivo indica la versin de
idioma de un manual. Por ejemplo, el nombre de archivo db2d1e80 identifica
la versin inglesa del manual Administration Guide: Planning y el nombre de
archivo db2d1g80 identifica la versin alemana del mismo manual. En la sexta
posicin de los nombres de archivo se utilizan las letras siguientes para
indicar el idioma del manual:
Idioma Identificador
Alemn g
Blgaro u
Checo x
Chino simplificado c
Chino tradicional t
Coreano k
Croata 9
Dans d
Eslovaco 7
Esloveno l
Espaol z
Finlands y
Francs f
Griego a
Holands q
Hngaro h
Ingls e
Italiano i
Japons j
Noruego n
Polaco p
Portugus de Brasil b
Portugus v
Rumano 8
Ruso r
Sueco s
Turco m
rabe w
Sin nmero de documento indica que el manual slo est disponible en lnea
y no tiene una versin impresa.
Informacin bsica de DB2
La informacin de esta categora incluye temas de DB2 que son
fundamentales para todos los usuarios de DB2. Encontrar til la informacin
de esta categora tanto si es programador o administrador de bases de datos
como si trabaja con DB2 Connect, DB2 Warehouse Manager u otros productos
DB2.
El directorio de instalacin de esta categora es doc/htmlcd/%L/core.
Tabla 39. Informacin bsica de DB2
Nombre Nmero de documento Nombre de archivo PDF
IBM DB2 Universal Database
SC10-3725 db2n0x80
Glosario
Sin nmero de documento db2t0x80
Master Index
SC09-4839 db2w0x80
Consulta de mensajes, Volumen
1
GC10-3728 db2m1x80
Consulta de mensajes, Volumen
2
GC10-3729 db2m2x80
Novedades
SC10-3734 db2q0x80
Informacin de administracin
La informacin de esta categora incluye los temas necesarios para disear,
implementar y mantener de forma efectiva bases de datos de DB2, depsitos
de datos y sistemas federados.
Informacin tcnica sobre DB2 Universal Database 575
El directorio de instalacin de esta categora es doc/htmlcd/%L/admin.
Tabla 40. Informacin de administracin
Administration Guide:
Planning
SC09-4822 db2d1x80
Implementation
SC09-4820 db2d2x80
Performance
SC09-4821 db2d3x80
SC09-4824 db2b0x80
Data Movement Utilities Guide
and Reference
SC09-4830 db2dmx80
Data Recovery and High
Availability Guide and
Reference
SC09-4831 db2hax80
Data Warehouse Center
Administration Guide
SC27-1123 db2ddx80
Federated Systems Guide
GC27-1224 db2fpx80
Gua de las herramientas de la
GUI para la administracin y el
desarrollo
SC10-3732 db2atx80
Replication Guide and Reference
SC27-1121 db2e0x80
IBM DB2 Instalacin y
administracin de un entorno
de satlites
GC10-3770 db2dsx80
SC10-3730 db2s1x80
SC10-3731 db2s2x80
System Monitor Guide and
Reference
SC09-4847 db2f0x80
Informacin para el desarrollo de aplicaciones
La informacin de esta categora es de especial inters para los programadores
de aplicaciones o programadores que trabajan con DB2. Encontrar
informacin acerca de los lenguajes y compiladores soportados, as como la
documentacin necesaria para acceder a DB2 utilizando las diversas interfaces
de programacin soportadas, por ejemplo SQL incorporado, ODBC, JDBC,
SQLj y CLI. Si visualiza esta informacin en lnea en HTML, tambin podr
acceder a un conjunto de programas de DB2 de ejemplo en HTML.
El directorio de instalacin de esta categora es doc/htmlcd/%L/ad.
Tabla 41. Informacin para el desarrollo de aplicaciones
Gua de desarrollo de
aplicaciones: Creacin y
ejecucin de aplicaciones
SC10-3733 db2axx80
aplicaciones: Programacin de
aplicaciones de cliente
SC10-3723 db2a1x80
aplicaciones: Programacin de
aplicaciones de servidor
SC10-3724 db2a2x80
Call Level Interface Guide and
Reference, Volume 1
SC09-4849 db2l1x80
Call Level Interface Guide and
Reference, Volume 2
SC09-4850 db2l2x80
Data Warehouse Center
Application Integration Guide
SC27-1124 db2adx80
IBM DB2 XML Extender
Administracin y programacin
SC10-3750 db2sxx80
Informacin de inteligencia empresarial
La informacin de esta categora describe cmo utilizar los componentes que
mejoran las posibilidades de anlisis y de depsito de datos de DB2 Universal
Database.
El directorio de instalacin de esta categora es doc/htmlcd/%L/wareh.
Tabla 42. Informacin de Inteligencia empresarial
IBM DB2 Warehouse Manager
Information Catalog Center
Administration Guide
SC27-1125 db2dix80
IBM DB2 Warehouse Manager
Gua de instalacin
GC10-3746 db2idx80
Informacin de DB2 Connect
La informacin de esta categora describe cmo acceder a los datos de sistema
principal o de iSeries utilizando DB2 Connect Enterprise Edition o DB2
Connect Personal Edition.
El directorio de instalacin de esta categora es doc/htmlcd/%L/conn.
Tabla 43. Informacin de DB2 Connect
APPC, CPI-C, and SNA Sense
Codes
Sin nmero de documento db2apx80
IBM Connectivity Supplement Sin nmero de documento db2h1x80
IBM DB2 Connect Gua rpida
de iniciacin para DB2
Enterprise Edition
GC10-3774 db2c6x80
IBM DB2 Connect Quick
Beginnings for DB2 Connect
Personal Edition
GC09-4834 db2c1x80
IBM DB2 Connect Users
Guide
SC09-4835 db2c0x80
Informacin de iniciacin
La informacin de esta categora es til cuando se van a instalar y configurar
servidores, clientes y otros productos de DB2.
El directorio de instalacin de esta categora es doc/htmlcd/%L/start.
Tabla 44. Informacin de iniciacin
Gua rpida de iniciacin para
clientes de DB2
GC10-3775 db2itx80
servidores de DB2
GC10-3773 db2isx80
DB2 Personal Edition
GC10-3771 db2i1x80
Suplemento de instalacin y
configuracin
GC10-3772 db2iyx80
DB2 Data Links Manager
GC10-3726 db2z6x80
Informacin de aprendizaje
La informacin de aprendizaje presenta las caractersticas de DB2 y explica
cmo realizar diversas tareas.
El directorio de instalacin de esta categora es doc/htmlcd/%L/tutr.
Tabla 45. Informacin de aprendizaje
Gua de aprendizaje de
Inteligencia empresarial:
Introduccin al depsito de
datos
Sin nmero de documento db2tux80
Gua de aprendizaje de
Inteligencia empresarial:
Lecciones ampliadas sobre el
depsito de datos
Sin nmero de documento db2tax80
Development Center Tutorial
for Video Online using
Microsoft Visual Basic
Sin nmero de documento db2tdx80
Tabla 45. Informacin de aprendizaje (continuacin)
Information Catalog Center
Tutorial
Sin nmero de documento db2aix80
Gua de aprendizaje de Video
Central para e-business
Sin nmero de documento db2twx80
Gua de aprendizaje de Visual
Explain
Sin nmero de documento db2tvx80
Informacin sobre componentes opcionales
La informacin de esta categora describe cmo trabajar con los componentes
opcionales de DB2.
El directorio de instalacin de esta categora es doc/htmlcd/%L/opt.
Tabla 46. Informacin sobre componentes opcionales
IBM DB2 Life Sciences Data
Connect Gua de planificacin,
instalacin y configuracin
SC10-3747 db2lsx80
IBM DB2 Spatial Extender
Gua del usuario y de consulta
SC10-3755 db2sbx80
Data Links Manager
Administration Guide and
Reference
SC27-1221 db2z0x80
Net Search Extender Gua de
administracin y programacin
Nota: El HTML para este
documento no se instala
desde el CD de
documentacin HTML.
SH10-9305 N/D
Notas del release
Las notas del release proporcionan informacin adicional especfica del release
y nivel de FixPak del producto. Tambin proporcionan resmenes de las
actualizaciones de la documentacin que se han incorporado en cada release y
FixPak.
Tabla 47. Notas del release
Notas del release de DB2 Ver nota. Ver nota.
Notas de instalacin de DB2 Slo disponible en el
CD-ROM del producto.
Slo disponible en el
CD-ROM del producto.
Nota: La versin HTML de las notas del release est disponible en el Centro
de informacin y en los CD-ROM del producto. Para ver el archivo
ASCII en plataformas basadas en UNIX, consulte el archivo
Release.Notes. Este archivo se encuentra en el directorio
DB2DIR/Readme/%L, donde %L representa el nombre de entorno
nacional y DB2DIR representa:
v /usr/opt/db2_08_01 en AIX
v /opt/IBM/db2/V8.1 en todos los dems sistemas operativos UNIX
v Impresin de manuales de DB2 desde archivos PDF en la pgina 581
v Solicitud de manuales de DB2 impresos en la pgina 582
v Acceso a la ayuda en lnea en la pgina 583
v Bsqueda de informacin de productos mediante el acceso al Centro de
informacin de DB2 desde las herramientas de administracin en la pgina
587
v Cmo ver documentacin tcnica en lnea directamente desde el CD de
documentacin HTML de DB2 en la pgina 589
Impresin de manuales de DB2 desde archivos PDF
Puede imprimir los manuales de DB2 desde los archivos PDF del CD de
documentacin PDF de DB2. Mediante la utilizacin de Adobe Acrobat Reader,
puede imprimir el manual entero o un rango especfico de pginas.
Prerrequisitos:
Asegrese de tener Adobe Acrobat Reader. Est disponible en el sitio Web de
Adobe en www.adobe.com
Procedimiento:
Para imprimir un manual de DB2 desde un archivo PDF:
1. Inserte el CD de documentacin PDF de DB2. En sistemas operativos UNIX,
monte el CD de documentacin PDF de DB2. Consulte el manual Iniciacin
rpida para obtener detalles sobre cmo montar un CD en sistemas
operativos UNIX.
2. Inicie Adobe Acrobat Reader.
3. Abra un archivo PDF desde una de las ubicaciones siguientes:
v En sistemas operativos Windows:
x:\doc\idioma, donde x representa la letra de unidad del CD-ROM e
idioma representa el cdigo de territorio de dos caracteres que representa
el idioma (por ejemplo, EN para ingls).
v En sistemas operativos UNIX:
/cdrom/doc/%L del CD-ROM, donde /cdrom representa el punto de
montaje del CD-ROM y %L representa el entorno nacional deseado.
v Solicitud de manuales de DB2 impresos en la pgina 582
587
v Visin general de la informacin tcnica de DB2 Universal Database en la
pgina 573
Solicitud de manuales de DB2 impresos
Procedimiento:
Para solicitar manuales impresos:
v Pngase en contacto con el distribuidor autorizado o representante de
mrketing de IBM. Para encontrar un representante local de IBM, consulte
el directorio mundial de contactos de IBM en la pgina Web
www.ibm.com/planetwide
v Llame al telfono 1-800-879-2755, si est en los EE.UU. o al
1-800-IBM-4YOU, si est en Canad.
v Visite el Centro de publicaciones de IBM en
www.ibm.com/shop/publications/order
Tambin puede obtener manuales de DB2 impresos si solicita los Doc Pack
para el producto DB2 a su distribuidor de IBM. Los Doc Pack son
subconjuntos de los manuales de la biblioteca de DB2 seleccionados con el
objeto de ayudar al usuario a empezar a utilizar el producto DB2 que ha
adquirido. Los manuales de los Doc Pack son los mismos que los que se
encuentran en formato PDF en el CD de documentacin PDF de DB2 y
presentan el mismo contenido que la documentacin que se encuentra en el
CD de documentacin HTML de DB2.
v Impresin de manuales de DB2 desde archivos PDF en la pgina 581
v Bsqueda de temas mediante el acceso al Centro de informacin de DB2
desde un navegador en la pgina 585
pgina 573
Acceso a la ayuda en lnea
La ayuda en lnea que viene con todos los componentes de DB2 est
disponible en tres tipos:
v Ayuda de ventana y de cuaderno
v Ayuda de lnea de mandatos
v Ayuda de sentencia de SQL
La ayuda de ventana y de cuaderno explica las tareas que se pueden realizar
en una ventana o un cuaderno y describe los controles. Esta ayuda tiene dos
tipos:
v Ayuda accesible desde el botn Ayuda
v Ventanas emergentes de informacin
El botn Ayuda proporciona acceso a la informacin de visin general y de
prerrequisitos. Las ventanas emergentes de informacin describen los
controles de la ventana o del cuaderno. La ayuda de ventana y de cuaderno
est disponible en los centros y componentes de DB2 que tienen interfaces de
usuario.
La ayuda de lnea de mandatos incluye ayuda de mandatos y ayuda de
mensajes. La ayuda de mandatos explica la sintaxis de los mandatos del
procesador de lnea de mandatos. La ayuda de mensajes describe la causa de
un mensaje de error y describe la accin que se debe realizar en respuesta al
error.
La ayuda de sentencia de SQL incluye la ayuda de SQL y la ayuda de
SQLSTATE. DB2 devuelve un valor de SQLSTATE para las condiciones que
pueden ser el resultado de una sentencia de SQL. La ayuda de SQLSTATE
explica la sintaxis de las sentencias de SQL (cdigos de clase y estados de
SQL).
Nota: Para los sistemas operativos UNIX no hay ayuda de SQL disponible.
Procedimiento:
Para acceder a la ayuda en lnea:
v Para la ayuda de ventana y cuaderno, pulse Ayuda o pulse dicho control y,
a continuacin, pulse F1. Si se selecciona el recuadro de seleccin Visualizar
automticamente ventanas emergentes de informacin en la pgina
General del cuaderno Valores de herramientas, tambin podr ver la
ventana emergente de informacin para un control determinado
manteniendo el cursor del ratn sobre el control.
v Para la ayuda de lnea de mandatos, abra el procesador de lnea de
mandatos y entre:
Para la ayuda de mandatos:
? mandato
donde mandato representa una palabra clave o el mandato completo.
Por ejemplo, ? catalog visualiza la ayuda para todos los mandatos
CATALOG, mientras que ? catalog database visualiza la ayuda para el
mandato CATALOG DATABASE.
v Para la ayuda de mensajes:
? XXXnnnnn
donde XXXnnnnn representa un identificador de mensaje vlido.
Por ejemplo, ? SQL30081 visualiza la ayuda acerca del mensaje SQL30081.
v Para la ayuda de sentencia de SQL, abra el procesador de lnea de
mandatos y entre:
? sqlstate o ? cdigo de clase
donde sqlstate representa un estado de SQL vlido de cinco dgitos y cdigo
de clase representa los dos primeros dgitos del estado de SQL.
Por ejemplo, ? 08003 visualiza la ayuda para el estado de SQL 08003,
mientras que ? 08 visualiza la ayuda para el cdigo de clase 08.
Bsqueda de temas mediante el acceso al Centro de informacin de DB2 desde
un navegador
Si accede al Centro de informacin de DB2 desde un navegador podr acceder
a la informacin que necesita para obtener el mximo provecho de DB2
Universal Database y DB2 Connect. El Centro de informacin de DB2 tambin
documenta las caractersticas y los componentes principales de DB2, entre
ellos, la duplicacin, el almacenamiento de datos, los metadatos y DB2
Extenders.
El Centro de informacin de DB2 al que se accede desde un navegador se
compone de los siguientes elementos principales:
rbol de navegacin
El rbol de navegacin est ubicado en el marco izquierdo de la
ventana del navegador. El rbol se expande y se contrae para mostrar
y ocultar los temas, el glosario y el ndice maestro del Centro de
informacin de DB2.
Barra de herramientas de navegacin
La barra de herramientas de navegacin est ubicada en el marco
superior derecho de la ventana del navegador. La barra de
herramientas de navegacin contiene botones que permiten realizar
bsquedas en el Centro de informacin de DB2, ocultar el rbol de
navegacin y buscar el tema visualizado actualmente en el rbol de
navegacin.
Marco de contenido
El marco de contenido est ubicado en el marco inferior derecho de la
ventana del navegador. El marco de contenido visualiza los temas del
Centro de informacin de DB2 cuando se pulsa un enlace en el rbol
de navegacin, se pulsa un resultado de bsqueda o se sigue un
enlace desde otro tema o desde el ndice maestro.
Prerrequisitos:
Para acceder al Centro de informacin de DB2 desde un navegador, deber
utilizar uno de los navegadores siguientes:
v Microsoft Explorer, versin 5 o posterior
v Netscape Navigator, versin 6.1 o posterior
Restricciones:
El Centro de informacin de DB2 slo contiene los conjuntos de temas que se
elige instalar desde el CD de documentacin HTML de DB2. Si el navegador
Web devuelve un error Archivo no encontrado cuando se intenta seguir un
enlace a un tema, habr que instalar uno o varios conjuntos de temas
adicionales del CD de documentacin HTML de DB2.
Procedimiento:
Para encontrar un tema buscndolo mediante palabras clave:
1. En la barra de herramientas de navegacin, pulse Buscar.
2. En el campo de entrada de texto superior de la ventana Buscar, escriba
uno o ms trminos relacionados con el rea de inters, y pulse Buscar. Se
visualiza una lista de temas clasificados por exactitud en el campo
Resultados. La clasificacin numrica junto al acierto proporciona una
indicacin de la importancia de la coincidencia (los nmeros ms altos
indican resultados coincidentes ms importantes).
La entrada de ms trminos aumentar la precisin de la consulta al
mismo tiempo que reducir el nmero de temas devueltos.
3. En el campo Resultados, pulse el ttulo del tema que desea leer. El tema
se visualiza en el marco de contenido.
Para buscar un tema en el rbol de navegacin:
1. En el rbol de navegacin, pulse el icono de libro de la categora de temas
relacionados con el rea de inters. Se visualiza una lista de subcategoras
bajo el icono.
2. Contine pulsando los iconos de libro hasta que encuentre la categora
que contiene los temas en los que est interesado. Las categoras que
enlazan con temas visualizan el ttulo de categora como un enlace
subrayado al mover el cursor sobre el ttulo de categora. El rbol de
navegacin identifica los temas con un icono de pgina.
3. Pulse el enlace al tema. El tema se visualiza en el marco de contenido.
Para buscar un tema o un trmino en el ndice maestro:
1. En el rbol de navegacin, pulse la categora ndice. La categora se
expande para visualizar una lista de enlaces ordenados alfabticamente en
el rbol de navegacin.
2. En el rbol de navegacin, pulse el enlace correspondiente al primer
carcter del trmino relacionado con el tema en el que est interesado. En
el marco de contenido se visualiza una lista de trminos con dicho carcter
inicial. Los trminos que tienen varias entradas de ndice se identifican
mediante un icono de libro.
3. Pulse el icono de libro correspondiente al trmino en el que est
interesado. Se visualiza una lista de subtrminos y temas debajo del
trmino que ha pulsado. Los temas se identifican mediante iconos de
pgina con un ttulo subrayado.
4. Pulse el ttulo del tema que satisface sus necesidades. El tema se visualiza
en el marco de contenido.
v Accesibilidad en la pgina 595
v Acceso al Centro de informacin de DB2 desde un navegador en la
pgina 597
587
v Actualizacin de la documentacin HTML instalada en la mquina en la
pgina 590
v Resolucin de problemas de bsqueda de documentacin de DB2 con
Netscape 4.x en la pgina 592
v Bsqueda en la documentacin de DB2 en la pgina 593
pgina 573
Bsqueda de informacin de productos mediante el acceso al Centro de
informacin de DB2 desde las herramientas de administracin
El Centro de informacin de DB2 proporciona acceso rpido a la informacin
de productos de DB2 y est disponible en todos los sistemas operativos para
los que estn disponibles las herramientas de administracin de DB2.
El Centro de informacin de DB2 al que se accede desde las herramientas
proporciona seis tipos de informacin.
Tareas Tareas clave que puede realizar mediante DB2.
Conceptos
Conceptos clave para DB2.
Consulta
Informacin de consulta de DB2, tal como palabras clave, mandatos y
las API.
Resolucin de problemas
Mensajes de error e informacin para ayudarle con los problemas
comunes de DB2.
Ejemplos
Enlaces a listados HTML de los programas de ejemplo proporcionados
con DB2.
Guas de aprendizaje
Ayuda con instrucciones diseada para ayudarle a conocer una
caracterstica de DB2.
Prerrequisitos:
Algunos enlaces del Centro de informacin de DB2 apuntan a sitios Web de
Internet. Para visualizar el contenido de estos enlaces, primero tendr que
conectarse a Internet.
Procedimiento:
Para buscar informacin del producto accediendo al Centro de informacin de
DB2 desde las herramientas:
1. Inicie el Centro de informacin de DB2, de uno de los modos siguientes:
v Desde las herramientas de administracin grficas, pulse el icono
Centro de informacin de la barra de herramientas. Tambin lo puede
seleccionar desde el men Ayuda.
v En la lnea de mandatos, entre db2ic.
2. Pulse la pestaa del tipo de informacin relacionado con la informacin
que est buscando.
3. Navegue por el rbol y pulse el tema en el que est interesado. El Centro
de informacin lanzar un navegador Web para visualizar la informacin.
4. Para buscar informacin sin examinar las listas, pulse el icono Buscar
situado a la derecha de la lista.
Una vez que el Centro de informacin haya lanzado un navegador para
visualizar la informacin, podr realizar una bsqueda de texto completo
pulsando el icono Buscar en la barra de herramientas de navegacin.
v Accesibilidad en la pgina 595
pgina 597
Cmo ver documentacin tcnica en lnea directamente desde el CD de
documentacin HTML de DB2
Todos los temas HTML que se pueden instalar desde el CD de documentacin
HTML de DB2 tambin se pueden leer directamente del CD. Por consiguiente,
puede ver la documentacin sin tener que instalarla.
Restricciones:
Dado que la ayuda de Herramientas se instala desde el CD del producto DB2
y no desde el CD de documentacin HTML de DB2, deber instalar el producto
DB2 para poder ver la ayuda.
Procedimiento:
1. Inserte el CD de documentacin HTML de DB2. En los sistemas operativos
UNIX, monte el CD de documentacin HTML de DB2. Consulte el manual
Iniciacin rpida para obtener informacin ms detallada sobre cmo
montar un CD en sistemas operativos UNIX.
2. Inicie el navegador HTML y abra el archivo apropiado:
v Para sistemas operativos Windows:
e:\archivos de programa\IBM\SQLLIB\doc\htmlcd\%L\index.htm
donde e representa la unidad de CD-ROM y %L es el entorno nacional
de la documentacin que desea utilizar, por ejemplo es_ES para el
espaol.
v Para sistemas operativos UNIX:
/cdrom/archivos de programa/IBM/SQLLIB/doc/htmlcd/%L/index.htm
donde /cdrom/ representa el lugar en el que est montado el CD y %L es
el entorno nacional de la documentacin que desea utilizar, por ejemplo
es_Es para el espaol.
v Copia de archivos desde el CD de documentacin HTML de DB2 en un
servidor Web en la pgina 591
pgina 573
Actualizacin de la documentacin HTML instalada en la mquina
Ahora es posible actualizar el cdigo HTML instalado desde el CD de
documentacin HTML de DB2 cuando IBM pone las actualizaciones a
disposicin de los usuarios. Esta tarea puede realizarse de una de las dos
maneras siguientes:
v Utilizando el Centro de informacin (si tiene instaladas las herramientas de
GUI de administracin de DB2).
v Bajando y aplicando un FixPak de documentacin HTML de DB2.
Nota: Esto NO actualizar el cdigo de DB2; slo actualizar la
documentacin HTML instalada desde el CD de documentacin HTML de
DB2.
Procedimiento:
Si desea utilizar el Centro de informacin para actualizar la documentacin
local:
1. Inicie el Centro de informacin de DB2, de uno de los modos siguientes:
v Desde las herramientas de administracin grficas, pulse el icono
Centro de informacin de la barra de herramientas. Tambin lo puede
seleccionar desde el men Ayuda.
v En la lnea de mandatos, entre db2ic.
2. Asegrese de que la mquina tiene acceso a la Internet externa; el
actualizador bajar el FixPak de documentacin ms reciente del servidor
IBM si es necesario.
3. Seleccione Centro de informacin > Actualizar documentacin local en
el men para iniciar la actualizacin.
4. Proporcione la informacin de proxy (si es necesaria) para conectarse a la
Internet externa.
El Centro de informacin bajar y aplicar el FixPak de documentacin ms
reciente, si hay alguno disponible.
Para bajar y aplicar manualmente el FixPak de documentacin:
1. Asegrese de que la mquina est conectada a Internet.
2. Abra la pgina de soporte de DB2 en el navegador Web, en la siguiente
direccin: www.ibm.com/software/data/db2/udb/winos2unix/support.
3. Siga el enlace correspondiente a la Versin 8 y busque el enlace FixPaks
de documentacin.
4. Determine si la versin de la documentacin local est anticuada,
comparando el nivel de FixPak de documentacin con el nivel de
documentacin que tiene instalado. Esta documentacin actual de la
mquina est en el nivel siguiente: DB2 v8.1 GA.
5. Si se encuentra disponible una versin ms reciente de la documentacin,
baje el FixPak aplicable al sistema operativo. Existe un FixPak para todas
las plataformas Windows y un FixPak para todas las plataformas UNIX.
6. Aplique el FixPak:
v Para sistemas operativos Windows: el FixPak de documentacin es un
archivo zip de autoextraccin. Coloque el FixPak de documentacin que
ha bajado en un directorio vaco y ejectelo. Crear un mandato setup
que puede ejecutar para instalar el FixPak de documentacin.
v Para sistemas operativos UNIX: el FixPak de documentacin es un
archivo tar.Z comprimido. Descomprima y desempaquete el archivo
mediante tar. Crear un directorio denominado delta_install con un
script denominado installdocfix. Ejecute este script para instalar el
FixPak de documentacin.
v Copia de archivos desde el CD de documentacin HTML de DB2 en un
servidor Web en la pgina 591
pgina 573
Copia de archivos desde el CD de documentacin HTML de DB2 en un servidor
Web
La biblioteca de informacin de DB2 entera se entrega al usuario en el CD de
documentacin HTML de DB2 y se puede instalar en un servidor Web para
acceder ms fcilmente a ella. Simplemente copie en el servidor Web la
documentacin para los idiomas que desee.
Nota: Puede encontrarse con un rendimiento bajo si accede a la
documentacin HTML desde un servidor Web mediante una conexin
de baja velocidad.
Procedimiento:
Para copiar archivos desde el CD de documentacin HTML de DB2 en un
servidor Web, utilice la va de acceso origen apropiada:
v Para sistemas operativos Windows:
E:\archivos de programa\IBM\SQLLIB\doc\htmlcd\%L\*.*
donde E representa la unidad de CD-ROM y %L representa el identificador
de idioma.
v Para sistemas operativos UNIX:
/cdrom/archivos de programa/IBM/SQLLIB/doc/htmlcd/%L/*.*
donde cdrom representa el punto de montaje para la unidad de CD-ROM y
%L representa el identificador de idioma
v Idiomas, entornos locales y pginas de cdigos soportados por DB2 en el
manual Gua rpida de iniciacin para servidores de DB2
pgina 573
Resolucin de problemas de bsqueda de documentacin de DB2 con Netscape
4.x
La mayora de los problemas de bsqueda estn relacionados con el soporte
Java proporcionado por los navegadores web. Esta tarea describe soluciones
provisionales posibles.
Procedimiento:
Un problema comn con Netscape 4.x implica la ausencia o la colocacin
errnea de una clase de seguridad. Intente la solucin provisional siguiente,
especialmente si ve la lnea siguiente en la consola Java del navegador:
Cannot find class java/security/InvalidParameterException
v En sistemas operativos Windows:
Desde el CD de documentacin HTML de DB2, copie el archivo x:archivos de
programa\IBM\SQLLIB\doc\htmlcd\entorno_nacional
\InvalidParameterException.class proporcionado en el directorio
java\classes\java\security\ relativo a la instalacin del navegador
Netscape, donde x representa la letra de unidad de CD-ROM y
entorno_nacional representa el nombre del entorno nacional deseado.
Nota: Puede que tenga que crear la estructura de subdirectorios
java\security\.
v En sistemas operativos UNIX:
Desde el CD de documentacin HTML de DB2, copie el archivo
/cdrom/archivos de programa/IBM/SQLLIB/doc/htmlcd/entorno_nacional
/InvalidParameterException.class proporcionado en el directorio
java/classes/java/security/ relativo a la instalacin del navegador
Netscape, donde cdrom representa el punto de montaje del CD-ROM y
entorno_nacional representa el nombre del entorno nacional deseado.
Nota: Puede que tenga que crear la estructura de subdirectorios
java/security/.
Si el navegador Netscape sigue sin visualizar la ventana de entrada de
bsqueda, intente lo siguiente:
v Detenga todas las instancias de los navegadores Netscape para asegurarse
de que no hay ningn cdigo de Netscape en ejecucin en la mquina. A
continuacin, abra una instancia nueva del navegador Netscape e intente
iniciar la bsqueda otra vez.
v Depure la antememoria del navegador.
v Pruebe una versin diferente de Netscape o un navegador diferente.
Bsqueda en la documentacin de DB2
Puede efectuar bsquedas en la biblioteca de documentacin de DB2 para
encontrar la informacin que necesita. Al pulsar el icono de bsqueda de la
barra de herramientas de navegacin del Centro de informacin de DB2 (al
que se accede desde un navegador), se abre una ventana emergente. La
bsqueda pueda tardar un minuto en cargarse, en funcin de la velocidad del
sistema y de la red.
Prerrequisitos:
Necesita Netscape 6.1 o posterior, o bien Internet Explorer 5 o posterior de
Microsoft. Asegrese de que el soporte Java del navegador est habilitado.
Restricciones:
Al utilizar la bsqueda de documentacin se aplican las restricciones
siguientes:
v La bsqueda no distingue entre maysculas y minsculas.
v No se soportan las bsquedas booleanas.
v No se da soporte a bsquedas mediante caracteres comodn o parciales.
Una bsqueda de java* (o java) slo buscar la serie literal java* (o java) y no
encontrar, por ejemplo, javadoc.
Procedimiento:
Si desea realizar bsquedas en la documentacin de DB2:
1. En la barra de herramientas de navegacin, pulse el icono Buscar.
2. En el campo de entrada de texto superior de la ventana Buscar, escriba
uno o varios trminos (separados por un espacio) relacionados con el rea
de inters y pulse Buscar. Se visualiza una lista de temas clasificados por
exactitud en el campo Resultados. La clasificacin numrica junto al
acierto proporciona una indicacin de la importancia de la coincidencia
(los nmeros ms altos indican resultados coincidentes ms importantes).
La entrada de ms trminos aumentar la precisin de la consulta al
mismo tiempo que reducir el nmero de temas devueltos.
3. En la lista Resultados, pulse el ttulo del tema que desea leer. El tema se
visualiza en el marco de contenido del Centro de informacin de DB2.
Nota: Cuando se realiza una bsqueda, el primer resultado (clasificacin ms
alta) se carga automticamente en el marco del navegador. Para ver el
contenido de otros resultados de la bsqueda, pulse el resultado en la
lista de resultados.
v Resolucin de problemas de bsqueda de documentacin de DB2 con
Netscape 4.x en la pgina 592
Informacin en lnea de resolucin de problemas de DB2
En el release de DB2 UDB Versin 8, ya no hay una Gua para la resolucin de
problemas. La informacin de resolucin de problemas que antes estaba
contenida en esta gua se ha integrado en las publicaciones de DB2. De este
modo, podemos proporcionar la informacin ms actualizada posible. Para
buscar informacin sobre los programas de utilidad y las funciones para la
resolucin de problemas de DB2, acceda el Centro de informacin de DB2
desde cualquiera de las herramientas.
Consulte el sitio de soporte en lnea de DB2 si tiene problemas y desea
obtener ayuda para encontrar las causas y las soluciones posibles. El sitio de
soporte contiene una gran base de datos de publicaciones, notas tcnicas,
registros APAR (problema de producto), FixPaks y otros recursos de DB2 que
se actualiza constantemente. Puede utilizar el sitio de soporte para buscar en
esta base de conocimiento y encontrar posibles soluciones a los problemas.
Acceda al sitio de Soporte en lnea en la direccin
www.ibm.com/software/data/db2/udb/winos2unix/support o pulsando el
botn Soporte en lnea en el Centro de informacin de DB2. En este sitio,
ahora tambin se encuentra disponible informacin que cambia
frecuentemente, por ejemplo el listado de cdigos de error internos de DB2.
pgina 597
587
Accesibilidad
Las caractersticas de accesibilidad ayudan a los usuarios con discapacidades
fsicas, por ejemplo movilidad o visin limitada, a utilizar los productos de
software satisfactoriamente. En DB2 Universal Database Versin 8, las
caractersticas de accesibilidad principales son las siguientes:
v DB2 permite trabajar con todas las caractersticas utilizando el teclado en
lugar del ratn. Consulte Entrada de teclado y navegacin.
v DB2 permite personalizar el tamao y el color de los fonts. Consulte
Pantalla accesible en la pgina 596.
v DB2 permite recibir seales de alerta visuales o sonoras. Consulte Seales
de alerta alternativas en la pgina 596.
v DB2 soporta las aplicaciones de accesibilidad que utilizan la API de
accesibilidad de Java. Consulte Compatibilidad con tecnologas de
asistencia en la pgina 596.
v DB2 viene con documentacin que se proporciona en un formato accesible.
Consulte Documentacin accesible en la pgina 596.
Entrada de teclado y navegacin
Entrada de teclado
Puede trabajar con las Herramientas de DB2 utilizando slo el teclado. Puede
utilizar teclas o combinaciones de teclas para llevar a cabo la mayora de las
operaciones que tambin se pueden realizar con el ratn.
Foco del teclado
En sistemas basados en UNIX, la posicin del foco del teclado est resaltada,
lo que indica qu rea de la ventana est activa y dnde sern efectivas las
pulsaciones.
Pantalla accesible
Las Herramientas de DB2 tienen caractersticas que amplan la interfaz de
usuario y mejoran la accesibilidad para los usuarios con visin reducida. Estas
mejoras de la accesibilidad incluyen soporte para propiedades de font
personalizables.
Valores de font
Las Herramientas de DB2 permiten seleccionar el color, el tamao y el font
para el texto de los mens y las ventanas de dilogo, utilizando el cuaderno
Valores de herramientas.
No dependencia del color
No es necesario distinguir los colores para utilizar cualquiera de las funciones
de este producto.
Seales de alerta alternativas
Puede especificar si desea recibir las alertas a travs de seales visuales o
sonoras, utilizando el cuaderno Valores de herramientas.
Compatibilidad con tecnologas de asistencia
La interfaz de las Herramientas de DB2 soporta la API de accesibilidad de
Java que permite el uso de lectores de pantalla y otras tecnologas de
asistencia utilizadas por las personas discapacitadas.
Documentacin accesible
La documentacin para la familia de productos DB2 est disponible en
formato HTML. Esto permite ver la documentacin de acuerdo con las
preferencias de pantalla establecidas en el navegador. Tambin permite utilizar
lectores de pantalla y otras tecnologas de asistencia.
Guas de aprendizaje de DB2
Las guas de aprendizaje de DB2 ayudan a conocer los diversos aspectos de
DB2 Universal Database. Las guas de aprendizaje proporcionan ejercicios con
instrucciones paso a paso en las reas de desarrollo de aplicaciones, ajuste del
rendimiento de las consultas de SQL, trabajo con depsitos de datos, gestin
de metadatos y desarrollo de servicios Web utilizando DB2.
Antes de empezar:
Para poder acceder a estas guas de aprendizaje utilizando los enlaces que
figuran abajo, deber instalar las guas de aprendizaje desde el CD de
documentacin HTML de DB2.
Si no desea instalar las guas de aprendizaje, puede ver las versiones HTML
de las mismas directamente desde el CD de documentacin HTML de DB2. En el
CD de documentacin PDF de DB2 tambin se encuentran disponibles versiones
PDF de estas guas de aprendizaje.
Algunos ejercicios de las guas de aprendizaje utilizan datos o cdigo de
ejemplo. Consulte cada gua de aprendizaje individual para obtener una
descripcin de los prerrequisitos para las tareas especficas.
Guas de aprendizaje de DB2 Universal Database:
Si ha instalado las guas de aprendizaje desde el CD de documentacin HTML
de DB2, puede pulsar el ttulo de una gua de aprendizaje de la lista que se
indica a continuacin para ver dicha gua.
Gua de aprendizaje de Inteligencia empresarial: Introduccin al Centro de depsito de
datos Realizar tareas de introduccin de depsito de datos utilizando el
Centro de depsito de datos.
Gua de aprendizaje de Inteligencia empresarial: Lecciones ampliadas sobre el depsito
de datos
Realizar tareas avanzadas de depsito de datos utilizando el Centro
de depsito de datos.
Gua de aprendizaje del Centro de desarrollo para Video Online utilizando Microsoft
Visual Basic
Crear diversos componentes de una aplicacin utilizando la Macro
automtica del Centro de desarrollo para Microsoft Visual Basic.
Gua de aprendizaje del Centro de catlogos de informacin
Crear y gestionar un catlogo de informacin para localizar y usar
metadatos utilizando el Centro de catlogos de informacin.
Gua de aprendizaje de Video Central para e-business
Desarrollar y desplegar una aplicacin avanzada de Servicios Web
DB2 utilizando productos WebSphere.
Gua de aprendizaje de Visual Explain
Analizar, optimizar y ajustar sentencias de SQL para obtener un mejor
rendimiento al utilizar Visual Explain.
Acceso al Centro de informacin de DB2 desde un navegador
El Centro de informacin de DB2 proporciona acceso a toda la informacin
que necesita para obtener el mximo provecho de DB2 Universal Database y
DB2 Connect en su empresa. El Centro de informacin de DB2 tambin
documenta las caractersticas y los componentes principales de DB2,
incluyendo la duplicacin, el depsito de datos, el Centro de catlogos de
informacin, Life Sciences Data Connect y DB2 Extenders.
El Centro de informacin de DB2 al que se accede desde un navegador
presenta las caractersticas siguientes si se visualiza en Netscape Navigator 6.1
o posterior o bien Microsoft Internet Explorer 5 o posterior. Algunas
caractersticas requieren que se habilite el soporte de Java o JavaScript:
Documentacin actualizada con regularidad
Mantenga los temas actualizados bajando el cdigo HTML
actualizado.
Bsqueda
Busque todos los temas instalados en la estacin de trabajo pulsando
Buscar en la barra de herramientas de navegacin.
rbol de navegacin integrado
Localice cualquier tema de la biblioteca de DB2 desde un solo rbol
de navegacin. El rbol de navegacin est organizado por tipo de
informacin, como se indica a continuacin:
v Las tareas proporcionan instrucciones paso a paso sobre cmo
lograr un objetivo.
v Los conceptos proporcionan una visin general de un tema.
v Los temas de consulta proporcionan informacin detallada sobre un
tema, incluyendo la sintaxis de sentencias y mandatos, la ayuda de
mensajes y los requisitos.
ndice maestro
Acceda a la informacin instalada desde el CD de documentacin HTML
de DB2 desde el ndice maestro. El ndice est organizado en orden
alfabtico por trminos del ndice.
Glosario maestro
El glosario maestro define los trminos utilizados en el Centro de
informacin de DB2. El glosario est organizado en orden alfabtico
por trminos del glosario.
587
v Actualizacin de la documentacin HTML instalada en la mquina en la
pgina 590
Avisos
Es posible que IBM no comercialice en todos los pases algunos productos,
servicios o caractersticas descritos en este manual. Consulte al representante
local de IBM para obtener informacin sobre los productos y servicios que
actualmente pueden adquirirse en su zona. Cualquier referencia a un
producto, programa o servicio de IBM no pretende afirmar ni implicar que
slo se pueda utilizar dicho producto, programa o servicio de IBM. En su
lugar se puede utilizar cualquier producto, programa o servicio
funcionalmente equivalente que no vulnere ninguno de los derechos de
propiedad intelectual de IBM. Sin embargo, es responsabilidad del usuario
evaluar y verificar el funcionamiento de cualquier producto, programa o
servicio que no sea de IBM.
IBM puede tener patentes o solicitudes de patentes en tramitacin que afecten
al tema tratado en este documento. La posesin de este documento no
confiere ninguna licencia sobre dichas patentes. Puede realizar consultas sobre
licencias escribiendo a:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
EE.UU.
Para realizar consultas sobre licencias referentes a informacin de doble byte
(DBCS), puede ponerse en contacto con el Departamento de Propiedad
Intelectual de IBM de su pas/regin o escribir a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokio 106, Japn
El prrafo siguiente no es aplicable al Reino Unido ni a ningn pas/regin
en donde tales disposiciones sean incompatibles con la legislacin local:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA
ESTA PUBLICACIN TAL CUAL, SIN GARANTA DE NINGUNA CLASE,
NI EXPLCITA NI IMPLCITA, INCLUIDAS, PERO SIN LIMITARSE A
ELLAS, LAS GARANTAS IMPLCITAS DE NO VULNERACIN DE
DERECHOS, COMERCIALIZACIN O IDONEIDAD PARA UN FIN
DETERMINADO. Algunos estados no permiten la exclusin de garantas
expresas o implcitas en determinadas transacciones, por lo que es posible que
esta declaracin no sea aplicable en su caso.
Esta publicacin puede contener inexactitudes tcnicas o errores tipogrficos.
Peridicamente se efectan cambios en la informacin aqu contenida; dichos
cambios se incorporarn a las nuevas ediciones de la publicacin. IBM puede
efectuar, en cualquier momento y sin previo aviso, mejoras y cambios en los
productos y programas descritos en esta publicacin.
Las referencias hechas en esta publicacin a sitios Web que no son de IBM se
proporcionan slo para la comodidad del usuario y no constituyen un aval de
esos sitios Web. La informacin contenida en esos sitios Web no forma parte
de la informacin del presente producto IBM y el usuario es responsable de la
utilizacin de dichos sitios Web.
IBM puede utilizar o distribuir cualquier informacin que se le facilite de la
manera que considere adecuada, sin contraer por ello ninguna obligacin con
el remitente.
Los licenciatarios de este programa que deseen obtener informacin sobre l
con el fin de habilitar: (i) el intercambio de informacin entre programas
creados de forma independiente y otros programas (incluido ste) y (ii) el uso
mutuo de la informacin intercambiada, deben ponerse en contacto con:
IBM Canada Limited
Office of the Lab Director
8200 Warden Avenue
Markham, Ontario
L6G 1C7
CANAD
Dicha informacin puede estar disponible, sujeta a los trminos y condiciones
apropiados, incluido en algunos casos el pago de una tarifa.
El programa bajo licencia descrito en este documento y todo el material bajo
licencia asociado a l, los proporciona IBM segn los trminos del Acuerdo de
Cliente de IBM, el Acuerdo Internacional de Programas Bajo Licencia de IBM
o cualquier acuerdo equivalente entre el usuario e IBM.
Los datos de rendimiento contenidos en este documento se obtuvieron en un
entorno controlado. Por lo tanto, los resultados obtenidos en otros entornos
operativos pueden variar significativamente. Algunas mediciones pueden
haberse realizado en sistemas experimentales y no es seguro que estas
mediciones sean las mismas en los sistemas disponibles comercialmente.
Adems, algunas mediciones pueden haberse calculado mediante
extrapolacin. Los resultados reales pueden variar. Los usuarios del presente
manual deben verificar los datos aplicables para su entorno especfico.
La informacin referente a productos que no son de IBM se ha obtenido de
los proveedores de esos productos, de sus anuncios publicados o de otras
fuentes disponibles pblicamente. IBM no ha probado esos productos y no
puede confirmar la exactitud del rendimiento, la compatibilidad ni ninguna
otra afirmacin referente a productos que no son de IBM. Las preguntas sobre
las prestaciones de productos que no son de IBM deben dirigirse a los
proveedores de esos productos.
Todas las declaraciones de intenciones de IBM estn sujetas a cambio o
cancelacin sin previo aviso, y slo representan objetivos.
Este manual puede contener ejemplos de datos e informes que se utilizan en
operaciones comerciales diarias. Para ilustrarlos de la forma ms completa
posible, los ejemplos incluyen nombres de personas, empresas, marcas y
productos. Todos estos nombres son ficticios y cualquier similitud con
nombres y direcciones utilizados por una empresa real es totalmente fortuita.
LICENCIA DE COPYRIGHT:
Este manual puede contener programas de aplicaciones de ejemplo escritos en
lenguaje fuente, que muestran tcnicas de programacin en diversas
plataformas operativas. Puede copiar, modificar y distribuir estos programas
de ejemplo como desee, sin pago alguno a IBM, con la intencin de
desarrollar, utilizar, comercializar o distribuir programas de aplicaciones de
acuerdo con la interfaz de programacin de aplicaciones correspondiente a la
plataforma operativa para la que estn escritos los programas de ejemplo.
Estos ejemplos no se han probado exhaustivamente bajo todas las condiciones.
Por lo tanto, IBM no puede asegurar ni implicar la fiabilidad, utilidad o
funcin de estos programas.
Cada copia o parte de estos programas de ejemplo o cualquier trabajo
derivado debe incluir una nota de copyright como la siguiente:
(nombre de la empresa) (ao). Partes de este cdigo proceden de programas de
ejemplo de IBM Corp. Copyright IBM Corp. _entre el o los aos_. Reservados
todos los derechos.
Avisos 601
Marcas registradas
Los trminos siguientes son marcas registradas de International Business
Machines Corporation en los EE.UU. y/o en otros pases y se han utilizado
como mnimo en uno de los documentos de la biblioteca de documentacin
de DB2 UDB.
ACF/VTAM
AISPO
AIX
AIXwindows
AnyNet
APPN
AS/400
BookManager
C Set++
C/370
CICS
Database 2
DataHub
DataJoiner
DataPropagator
DataRefresher
DB2
DB2 Connect
DB2 Extenders
DB2 OLAP Server
Distributed Relational
Database Architecture
DRDA
eServer
Extended Services
FFST
First Failure Support Technology
IBM
IMS
IMS/ESA
iSeries
LAN Distance
MVS
MVS/ESA
MVS/XA
Net.Data
NetView
OS/390
OS/400
PowerPC
pSeries
QBIC
QMF
RACF
RISC System/6000
RS/6000
S/370
SP
SQL/400
SQL/DS
System/370
System/390
SystemView
Tivoli
VisualAge
VM/ESA
VSE/ESA
VTAM
WebExplorer
WebSphere
WIN-OS/2
z/OS
zSeries
Los trminos siguientes son marcas registradas de otras empresas y se han
utilizado como mnimo en uno de los documentos de la biblioteca de
documentacin de DB2 UDB:
Microsoft, Windows, Windows NT y el logotipo de Windows son marcas
registradas de Microsoft Corporation en los EE.UU. y/o en otros pases.
Intel y Pentium son marcas registradas de Intel Corporation en los EE.UU.
y/o en otros pases.
Java y todas las marcas registradas basadas en Java son marcas registradas de
Sun Microsystems, Inc. en los EE.UU. y/o en otros pases.
UNIX es marca registrada de The Open Group en los EE.UU. y/o en otros
pases.
Otros nombres de empresas, productos o servicios, pueden ser marcas
registradas o marcas de servicio de otras empresas.
Avisos 603
Cmo ponerse en contacto con IBM
En los EE.UU., puede ponerse en contacto con IBM llamando a uno de los
siguientes nmeros:
v 1-800-237-5511 para servicio al cliente
v 1-888-426-4343 para obtener informacin sobre las opciones de servicio
tcnico disponibles
v 1-800-IBM-4YOU (426-4968) para mrketing y ventas de DB2
En Canad, puede ponerse en contacto con IBM llamando a uno de los
siguientes nmeros:
v 1-800-IBM-SERV (1-800-426-7378) para servicio al cliente
v 1-800-465-9600 para obtener informacin sobre las opciones de servicio
tcnico disponibles
v 1-800-IBM-4YOU (1-800-426-4968) para mrketing y ventas de DB2
Para localizar una oficina de IBM en su pas o regin, consulte IBM Directory
of Worldwide Contacts en el sitio Web www.ibm.com/planetwide
Informacin sobre productos
La informacin relacionada con productos DB2 Universal Database se
encuentra disponible por telfono o a travs de la World Wide Web en el sitio
www.ibm.com/software/data/db2/udb
Este sitio contiene la informacin ms reciente sobre la biblioteca tcnica,
pedidos de manuales, descargas de clientes, grupos de noticias, FixPacks,
novedades y enlaces con recursos de la Web.
Si vive en los EE.UU., puede llamar a uno de los nmeros siguientes:
v 1-800-IBM-CALL (1-800-426-2255) para solicitar productos u obtener
informacin general.
v 1-800-879-2755 para solicitar publicaciones.
Para obtener informacin sobre cmo ponerse en contacto con IBM desde
fuera de los EE.UU., vaya a la pgina IBM Worldwide en el sitio
www.ibm.com/planetwide
Nmero Pieza: CT17TES

Printed in Denmark by IBM Danmark A/S
SC10-3723-00
(
1
P
)
P
/
N
:
C
T
1
7
T
E
S

Guia de Desarrollo de Aplicaciones

Cargado por

Copyright:

Formatos disponibles

Guia de Desarrollo de Aplicaciones

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia de Desarrollo de Aplicaciones

Cargado por

Copyright:

Formatos disponibles

IBM

DB2 Universal Database

Gua de desarrollo de aplicaciones:

DB2 Universal Database

Gua de desarrollo de aplicaciones:

246 Programacin de aplicaciones cliente

Consideraciones sobre las variables del lenguaje principal LOB:

Consideraciones sobre las variables numricas del lenguaje principal:

A continuacin se muestra la sintaxis de las variables de tipo carcter de

Consideraciones sobre las variables del lenguaje principal LOB:

Consideraciones sobre las variables del lenguaje principal de localizador de

Consideraciones sobre las variables del lenguaje principal de referencia de

Debe declarar las variables del lenguaje principal de localizador de LOB en la

Captulo 13. Programacin en REXX 379

Figura 10. Pgina de cdigos 500

SS050000 SM700000 SM030000

SM570000 SM770000 SP050000

SM570001 SM320000 SP060000

SM910000 SM600000 SP110000

SM690000 SV040000 SP120000

Nmero Pieza: CT17TES

También podría gustarte