You are on page 1of 626

IBM

DB2 Universal Database

Gua de desarrollo de aplicaciones:


Programacin de aplicaciones de cliente
Versin 8
SC10-3723-00

IBM

DB2 Universal Database

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
Finalizacin de una transaccin con la
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
Control de valores de datos mediante
restricciones de comprobacin de tabla . . 54
Control de valores de datos mediante
restricciones de integridad referencial . . 54
Control de valores de datos mediante
vistas con la opcin Check . . . . . . 55
Control de valores de datos mediante
lgica de aplicacin y tipos de variables de
programa . . . . . . . . . . . . 55
Control de relaciones de datos . . . . . 56
Control de relaciones de datos mediante
restricciones de integridad referencial . . 56
Control de relaciones de datos mediante
activadores . . . . . . . . . . . 57
Control de relaciones de datos mediante
activadores anteriores . . . . . . . . 57
Control de relaciones de datos mediante
activadores posteriores . . . . . . . 58
Control de relaciones de datos mediante
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
Consideraciones sobre autorizacin para
SQL dinmico . . . . . . . . . . 61
Consideraciones sobre autorizacin para
SQL esttico . . . . . . . . . . . 63
Consideraciones sobre autorizacin para
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
proyectos de IBM DB2 Universal Database
para Microsoft Visual C++ . . . . . . 73
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
Declaracin de variables del lenguaje
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
programas de SQL esttico. . . . . . 119
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
Declaracin y utilizacin de cursores en
programas de SQL dinmico . . . . . 144
Ejemplo de un cursor en un programa de
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
un programa de SQL dinmico . . . . 156
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
programas de SQL dinmico . . . . . 164
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
un programa de SQL dinmico . . . . 167
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
Sintaxis de las variables del lenguaje
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
Sintaxis de las variables del lenguaje
principal de objeto grande (LOB) en C o
C++ . . . . . . . . . . . . . 195
Sintaxis de las variables del lenguaje
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
Variables del lenguaje principal en
COBOL . . . . . . . . . . . . 240
Nombres de variables del lenguaje
principal en COBOL . . . . . . . . 241
Declaraciones de variables del lenguaje
principal en COBOL . . . . . . . . 242
Sintaxis de las variables numricas del
lenguaje principal en COBOL . . . . . 242
Sintaxis de las variables del lenguaje
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
Sintaxis de las variables del lenguaje
principal LOB en COBOL . . . . . . 246
Sintaxis de las variables del lenguaje
principal de localizador de LOB en
COBOL . . . . . . . . . . . . 248
Sintaxis de las variables del lenguaje
principal de referencia de archivos en
COBOL . . . . . . . . . . . . 248
Soporte de estructura del lenguaje
principal en COBOL . . . . . . . . 249
Tablas de indicadores en COBOL . . . 251
REDEFINES en elementos de datos de
grupos COBOL . . . . . . . . . 252
Seccin declare de SQL con variables del
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
Consideraciones sobre EUC en japons o
chino tradicional y UCS-2 para COBOL . . 258
COBOL orientado a objetos . . . . . . 259
Captulo 9. Programacin en FORTRAN 261
Consideraciones sobre la programacin en
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 . . . . . . . . . . 263
Archivos include para FORTRAN . . . 263
Archivos include en aplicaciones
FORTRAN . . . . . . . . . . . 266
Sentencias de SQL incorporado en
FORTRAN . . . . . . . . . . . . 267
Variables del lenguaje principal en
FORTRAN . . . . . . . . . . . . 268
Variables del lenguaje principal en
FORTRAN . . . . . . . . . . . 269
Nombres de variables del lenguaje
principal en FORTRAN . . . . . . . 269
Declaraciones de variables del lenguaje
principal en FORTRAN . . . . . . . 270
Sintaxis de las variables numricas del
lenguaje principal en FORTRAN . . . . 271
Sintaxis de las variables de tipo carcter
del lenguaje principal en FORTRAN . . 271
Variables de indicador en FORTRAN . . 273
Sintaxis de las variables del lenguaje
principal de objeto grande (LOB) en
FORTRAN . . . . . . . . . . . 273
Contenido vii
Sintaxis de las variables del lenguaje
principal de localizador de objeto grande
(LOB) en FORTRAN . . . . . . . . 274
Sintaxis de las variables del lenguaje
principal de referencia de archivos en
FORTRAN . . . . . . . . . . . 275
Seccin declare de SQL con variables del
lenguaje principal para FORTRAN . . . 276
Tipos de datos SQL soportados en
FORTRAN . . . . . . . . . . . . 276
Consideraciones sobre juegos de caracteres
de varios bytes en FORTRAN. . . . . . 278
Consideraciones sobre EUC en japons o
chino tradicional y UCS-2 para FORTRAN . 278
Variables SQLSTATE y SQLCODE en
FORTRAN . . . . . . . . . . . . 279
Parte 3. Java . . . . . . . . . 281
Captulo 10. Programacin en Java . . . 283
Consideraciones sobre la programacin en
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
controlador de tipo 3. . . . . . . . 293
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
Acceso a datos de DB2 mediante
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
Enterprise Edition. . . . . . . . . 346
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
Consideraciones sobre la programacin en
Perl . . . . . . . . . . . . . . 363
Restricciones de Perl . . . . . . . . . 363
Acceso a bases de datos de varias hebras en
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
Consideraciones sobre la programacin en
REXX . . . . . . . . . . . . . . 369
Restricciones del lenguaje en REXX . . . . 370
Restricciones del lenguaje en REXX . . . 370
Registro de SQLEXEC, SQLDBS y
SQLDB2 en REXX. . . . . . . . . 370
Acceso a bases de datos de varias hebras
en REXX. . . . . . . . . . . . 372
Consideraciones sobre EUC en japons o
chino tradicional para REXX . . . . . 372
SQL incorporado en aplicaciones REXX . . 372
Variables del lenguaje principal en REXX 374
Variables del lenguaje principal en REXX 374
Nombres de variables del lenguaje
principal en REXX . . . . . . . . 375
Referencias a variables del lenguaje
principal en REXX . . . . . . . . 375
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
Conversin de datos para establecer datos
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
Soporte de IBM OLE DB Provider de
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
Cursores desplazables actualizables en
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
actualizacin mltiple . . . . . . . 465
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
datos particionadas . . . . . . . . 478
Elusin local en entornos de bases de
datos particionadas . . . . . . . . 479
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
inserciones en almacenamiento
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
datos particionadas . . . . . . . . 494
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
sistemas de bases de datos relacionales de
IBM . . . . . . . . . . . . . . 535
Bloqueo y portabilidad de aplicaciones. . . 536
Diferencias en SQLCODE y SQLSTATE entre
sistemas de bases de datos relacionales de
IBM . . . . . . . . . . . . . . 536
Diferencias en el catlogo del sistema entre
sistemas de bases de datos relacionales de
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
Sentencias de SQL de servidor de sistema
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.
Copyright IBM Corp. 1993-2002 3
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)
4 Programacin de aplicaciones cliente
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
6 Programacin de aplicaciones cliente
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
Captulo 1. Visin general de las interfaces de programacin soportadas 7
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
8 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Captulo 1. Visin general de las interfaces de programacin soportadas 9
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.
10 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Captulo 1. Visin general de las interfaces de programacin soportadas 11
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.
Conceptos relacionados:
v API administrativas en SQL incorporado o en programas de CLI de DB2
en la pgina 52
v Interfaz de nivel de llamada de DB2 (CLI) frente a SQL dinmico
incorporado en la pgina 169
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
12 Programacin de aplicaciones cliente
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
Captulo 1. Visin general de las interfaces de programacin soportadas 13
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.
14 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Interfaz de nivel de llamada de DB2 (CLI) frente a SQL dinmico
incorporado en la pgina 169
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.
Captulo 1. Visin general de las interfaces de programacin soportadas 15
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
Conceptos relacionados:
v Comparacin entre SQLj y JDBC en la pgina 284
Tareas relacionadas:
16 Programacin de aplicaciones cliente
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
Conceptos relacionados:
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
Captulo 1. Visin general de las interfaces de programacin soportadas 17
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
Tareas relacionadas:
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
desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones ADO con Visual C++ en el manual Gua de
desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
Consulta relacionada:
v Programas de ejemplo Visual Basic en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
v Programas de ejemplo Visual C++ en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
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.
Conceptos relacionados:
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.
18 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Captulo 1. Visin general de las interfaces de programacin soportadas 19
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.
Conceptos relacionados:
v Enterprise Java Beans en la pgina 348
Consulta relacionada:
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
20 Programacin de aplicaciones cliente
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
Conceptos relacionados:
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
Captulo 1. Visin general de las interfaces de programacin soportadas 21
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.
Conceptos relacionados:
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
22 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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:
Captulo 1. Visin general de las interfaces de programacin soportadas 23
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.
Conceptos relacionados:
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.
24 Programacin de aplicaciones cliente
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
Captulo 1. Visin general de las interfaces de programacin soportadas 25
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.
Conceptos relacionados:
v Procedimientos almacenados de DB2 en la pgina 23
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
26 Programacin de aplicaciones cliente
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
Captulo 1. Visin general de las interfaces de programacin soportadas 27
(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.
Conceptos relacionados:
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.
Conceptos relacionados:
v Procedimientos almacenados de DB2 en la pgina 23
v Centro de desarrollo en la pgina 25
28 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Consulta relacionada:
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:
Captulo 1. Visin general de las interfaces de programacin soportadas 29
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.
Conceptos relacionados:
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
30 Programacin de aplicaciones cliente
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
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
Finalizacin de una transaccin con la
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
Control de valores de datos mediante
restricciones exclusivas . . . . . . . 53
Control de valores de datos mediante
restricciones de comprobacin de tabla . . 54
Control de valores de datos mediante
restricciones de integridad referencial . . 54
Control de valores de datos mediante
vistas con la opcin Check . . . . . . 55
Control de valores de datos mediante
lgica de aplicacin y tipos de variables de
programa . . . . . . . . . . . . 55
Control de relaciones de datos . . . . . 56
Control de relaciones de datos mediante
restricciones de integridad referencial . . 56
Control de relaciones de datos mediante
activadores . . . . . . . . . . . 57
Control de relaciones de datos mediante
activadores anteriores . . . . . . . . 57
Control de relaciones de datos mediante
activadores posteriores . . . . . . . 58
Control de relaciones de datos mediante
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
Consideraciones sobre autorizacin para
SQL dinmico . . . . . . . . . . 61
Consideraciones sobre autorizacin para
SQL esttico . . . . . . . . . . . 63
Consideraciones sobre autorizacin para
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
Copyright IBM Corp. 1993-2002 31
Terminologa de la macro automtica de
proyectos de IBM DB2 Universal Database
para Microsoft Visual C++ . . . . . . 72
Activacin de la macro automtica de
proyectos de IBM DB2 Universal Database
para Microsoft Visual C++ . . . . . . 73
Activacin 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.
Tareas relacionadas:
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
de aplicaciones: Creacin y ejecucin de aplicaciones
32 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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:
Creacin y ejecucin de aplicaciones
v Programas de ejemplo: estructura y diseo en el manual Gua de desarrollo
de aplicaciones: Creacin y ejecucin de aplicaciones
Tareas relacionadas:
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.
Conceptos relacionados:
v Valores de SQLSTATE y SQLCODE en Java en la pgina 335
Tareas relacionadas:
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.
34 Programacin de aplicaciones cliente
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.
Consulta relacionada:
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
Captulo 2. Codificacin de una aplicacin DB2 35
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;
Conceptos relacionados:
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
36 Programacin de aplicaciones cliente
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
Consulta relacionada:
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
v Sintaxis de las variables del lenguaje principal de tipo carcter de longitud
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
COBOL en la pgina 248
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
COBOL en la pgina 248
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
v Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
FORTRAN en la pgina 273
v Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en FORTRAN en la pgina 274
Captulo 2. Codificacin de una aplicacin DB2 37
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
FORTRAN en la pgina 275
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;
Consulta relacionada:
v db2dclgn - Mandato Generador de declaraciones en el manual Consulta de
mandatos
38 Programacin de aplicaciones cliente
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.
Captulo 2. Codificacin de una aplicacin DB2 39
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.
Conceptos relacionados:
v Vistas de catlogo en el manual Consulta de SQL, Volumen 1
Tareas relacionadas:
v Declaracin de variables que interactan con el gestor de bases de datos
en la pgina 34
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Creacin de una seccin de declaracin de una aplicacin autnoma en la
pgina 34
Consulta relacionada:
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 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.
40 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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 Valores de SQLSTATE y SQLCODE en Java en la pgina 335
v Variables SQLSTATE y SQLCODE en Perl en la pgina 366
Tareas relacionadas:
v Creacin de una seccin de declaracin de una aplicacin autnoma en la
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
Captulo 2. Codificacin de una aplicacin DB2 41
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.
42 Programacin de aplicaciones cliente
Consulta relacionada:
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
Tareas relacionadas:
v Creacin de una seccin de declaracin de una aplicacin autnoma en la
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:
Captulo 2. Codificacin de una aplicacin DB2 43
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.
Conceptos relacionados:
v Actualizacin mltiple en la pgina 461
Consulta relacionada:
v CONNECT (Tipo 1) sentencia en el manual Consulta de SQL, Volumen 2
v CONNECT (Tipo 2) 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)
44 Programacin de aplicaciones cliente
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
Tareas relacionadas:
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,
Captulo 2. Codificacin de una aplicacin DB2 45
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.
Conceptos relacionados:
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
Tareas relacionadas:
v Finalizacin de un programa de aplicacin en la pgina 48
Consulta relacionada:
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.
46 Programacin de aplicaciones cliente
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
variables del lenguaje principal.
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.
Conceptos relacionados:
v Finalizacin implcita de una transaccin en una aplicacin autnoma en
la pgina 48
v Unidad de trabajo remota en la pgina 461
v Actualizacin mltiple en la pgina 461
Consulta relacionada:
v CONNECT (Tipo 1) sentencia en el manual Consulta de SQL, Volumen 2
v CONNECT (Tipo 2) sentencia en el manual Consulta de SQL, Volumen 2
v WHENEVER sentencia en el manual Consulta de SQL, Volumen 2
Captulo 2. Codificacin de una aplicacin DB2 47
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.
Conceptos relacionados:
v Finalizacin implcita de una transaccin en una aplicacin autnoma en
la pgina 48
Consulta relacionada:
v CONNECT (Tipo 1) sentencia en el manual Consulta de SQL, Volumen 2
v CONNECT (Tipo 2) sentencia en el manual Consulta de SQL, Volumen 2
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
48 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Objetivo del acceso a base de datos de varias hebras en la pgina 227
Tareas relacionadas:
v Finalizacin de un programa de aplicacin en la pgina 48
Consulta relacionada:
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
Captulo 2. Codificacin de una aplicacin DB2 49
(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 SELECT ... |
EXEC SQL DELETE ... | Segunda unidad
(ms sentencias de SQL) | de trabajo
EXEC SQL COMMIT |
(ms lgica de programa)
EXEC SQL CONNECT TO base_de_datos A |
EXEC SQL SELECT ... |
EXEC SQL DELETE ... | Tercera unidad
(ms sentencias de SQL) | de trabajo
EXEC SQL COMMIT |
(ms lgica de programa)
EXEC SQL CONNECT RESET |
ERRCHK |
| Limpieza de
(comprobar informacin de error en SQLCA) | aplicacin
|
Finalizar programa
Tareas relacionadas:
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.
50 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Administration Guide: Performance
v SQL explain facility en el manual Administration Guide: Performance
v Herramientas de DB2 Universal Database para desarrollar aplicaciones en
la pgina 5
Consulta relacionada:
v Apndice A, Sentencias de SQL soportadas en la pgina 521
Captulo 2. Codificacin de una aplicacin DB2 51
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.
Conceptos relacionados:
v Consideraciones sobre autorizacin para API en la pgina 63
v Programas de ejemplo: estructura y diseo en el manual Gua de desarrollo
de aplicaciones: Creacin y ejecucin de aplicaciones
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
52 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Conceptos relacionados:
v Tipos diferenciados definidos por el usuario en el manual Gua de
desarrollo de aplicaciones: Programacin de aplicaciones de servidor
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
Captulo 2. Codificacin de una aplicacin DB2 53
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.
Tareas relacionadas:
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.
Tareas relacionadas:
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.
54 Programacin de aplicaciones cliente
Conceptos relacionados:
v Restricciones en el manual Consulta de SQL, Volumen 1
v Control de relaciones de datos mediante restricciones de integridad
referencial en la pgina 56
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.
Consulta relacionada:
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.
Conceptos relacionados:
v Control de valores de datos mediante vistas con la opcin Check en la
pgina 55
Captulo 2. Codificacin de una aplicacin DB2 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.
Conceptos relacionados:
v Control de relaciones de datos mediante restricciones de integridad
referencial en la pgina 56
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.
Conceptos relacionados:
v Restricciones en el manual Consulta de SQL, Volumen 1
Tareas relacionadas:
v Defining referential constraints en el manual Administration Guide:
Implementation
Consulta relacionada:
v ALTER TABLE sentencia en el manual Consulta de SQL, Volumen 2
56 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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 Activadores de DB2 en la pgina 29
Tareas relacionadas:
v Creating a trigger en el manual Administration Guide: Implementation
v Creacin de activadores en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
Consulta relacionada:
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.
Conceptos relacionados:
v Control de relaciones de datos mediante activadores posteriores en la
pgina 58
v Activadores de DB2 en la pgina 29
Tareas relacionadas:
v Creating a trigger en el manual Administration Guide: Implementation
Captulo 2. Codificacin de una aplicacin DB2 57
v Creacin de activadores en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
Consulta relacionada:
v CREATE TRIGGER sentencia en el manual Consulta de SQL, Volumen 2
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.
Conceptos relacionados:
v Control de relaciones de datos mediante activadores anteriores en la
pgina 57
v Activadores de DB2 en la pgina 29
Tareas relacionadas:
v Creating a trigger en el manual Administration Guide: Implementation
v Creacin de activadores en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
Consulta relacionada:
v CREATE TRIGGER sentencia en el manual Consulta de SQL, Volumen 2
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.
58 Programacin de aplicaciones cliente
Conceptos relacionados:
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:
v Procedimientos almacenados
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.
Conceptos relacionados:
Captulo 2. Codificacin de una aplicacin DB2 59
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 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
v Procedimientos almacenados de DB2 en la pgina 23
v Mtodos y funciones definidas por el usuario de DB2 en la pgina 24
v Activadores de DB2 en la pgina 29
Tareas relacionadas:
v Creating a trigger en el manual Administration Guide: Implementation
v Creacin de activadores en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
Consulta relacionada:
v CREATE TRIGGER sentencia en el manual Consulta de SQL, Volumen 2
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).
60 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Consideraciones sobre autorizacin para SQL dinmico en la pgina 61
v Consideraciones sobre autorizacin para SQL esttico en la pgina 63
v Consideraciones sobre autorizacin para API 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
Captulo 2. Codificacin de una aplicacin DB2 61
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.
Conceptos relacionados:
v Consideraciones sobre autorizacin para SQL incorporado en la pgina 60
v Consideraciones sobre autorizacin para SQL esttico en la pgina 63
v Consideraciones sobre autorizacin para API en la pgina 63
v Efectos de DYNAMICRULES en SQL dinmico en la pgina 147
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
62 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Consideraciones sobre autorizacin para SQL incorporado en la pgina 60
v Consideraciones sobre autorizacin para SQL dinmico en la pgina 61
v Consideraciones sobre autorizacin para API en la pgina 63
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
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.
Captulo 2. Codificacin de una aplicacin DB2 63
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.
Conceptos relacionados:
v Consideraciones sobre autorizacin para SQL incorporado en la pgina 60
v Consideraciones sobre autorizacin para SQL dinmico en la pgina 61
v Consideraciones sobre autorizacin para SQL esttico en la pgina 63
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.
64 Programacin de aplicaciones cliente
Tareas relacionadas:
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
Consulta relacionada:
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
Captulo 2. Codificacin de una aplicacin DB2 65
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.
Tareas relacionadas:
v Generacin de datos de prueba en la pgina 66
Consulta relacionada:
v CREATE TABLE sentencia en el manual Consulta de SQL, Volumen 2
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.
66 Programacin de aplicaciones cliente
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
Captulo 2. Codificacin de una aplicacin DB2 67
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.
Conceptos relacionados:
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 Mtodos y funciones definidas por el usuario de DB2 en la pgina 24
Tareas relacionadas:
v Depuracin y optimizacin de una aplicacin en la pgina 68
Consulta relacionada:
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:
68 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Catalog statistics for modeling and what-if planning en el manual
Administration Guide: Performance
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++
La macro automtica de proyectos de IBM DB2 Universal Database para
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:
Captulo 2. Codificacin de una aplicacin DB2 69
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++
La macro automtica de proyectos de IBM DB2 Universal Database para
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++
La macro automtica de proyectos de IBM DB2 Universal Database para
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
70 Programacin de aplicaciones cliente
Desplegar proyecto de DB2
Despliega los archivos externos de proyecto de DB2 empaquetado
La macro automtica de proyectos de IBM DB2 Universal Database para
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
La macro automtica de proyectos de IBM DB2 Universal Database para
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
Tareas relacionadas:
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
Database para Microsoft Visual C++ en la pgina 74
Consulta relacionada:
v Terminologa de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++ en la pgina 72
Captulo 2. Codificacin de una aplicacin DB2 71
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.
Conceptos relacionados:
v La macro automtica de proyectos de IBM DB2 Universal Database para
Microsoft Visual C++ en la pgina 69
Tareas relacionadas:
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
Database para Microsoft Visual C++ en la pgina 74
72 Programacin de aplicaciones cliente
Activacin de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++
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.
Conceptos relacionados:
v La macro automtica de proyectos de IBM DB2 Universal Database para
Microsoft Visual C++ en la pgina 69
Tareas relacionadas:
v Activacin de la macro automtica de herramientas de IBM DB2 Universal
Database para Microsoft Visual C++ en la pgina 74
Consulta relacionada:
v Terminologa de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++ en la pgina 72
Captulo 2. Codificacin de una aplicacin DB2 73
Activacin de la macro automtica de herramientas de IBM DB2 Universal
Database para Microsoft Visual C++
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.
Conceptos relacionados:
v La macro automtica de proyectos de IBM DB2 Universal Database para
Microsoft Visual C++ en la pgina 69
Tareas relacionadas:
v Activacin de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++ en la pgina 73
Consulta relacionada:
v Terminologa de la macro automtica de proyectos de IBM DB2 Universal
Database para Microsoft Visual C++ en la pgina 72
74 Programacin de aplicaciones cliente
Parte 2. SQL incorporado
Copyright IBM Corp. 1993-2002 75
76 Programacin de aplicaciones cliente
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() );
}
Copyright IBM Corp. 1993-2002 77
Tabla 2. Incorporacin de sentencias de SQL en un lenguaje principal (continuacin)
Lenguaje Cdigo fuente de ejemplo
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
Lenguaje Cdigo fuente de ejemplo
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++ */
78 Programacin de aplicaciones cliente
Tabla 3. Incorporacin de sentencias de SQL en un lenguaje principal (continuacin)
Lenguaje Cdigo fuente de ejemplo
SQLj
/* Aqu slo se permiten comentarios de Java */
#sql c1 = {
-- Aqu se permiten comentarios de SQL
/* 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
-- Aqu se permiten comentarios de 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
Conceptos relacionados:
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.
80 Programacin de aplicaciones cliente
Conceptos relacionados:
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
Captulo 3. Visin general sobre SQL incorporado 81
v Requisitos del archivo fuente para aplicaciones de SQL incorporado en la
pgina 86
v Compilacin y enlace de archivos fuente que contienen SQL incorporado
en la pgina 88
v SQL incorporado en la pgina 9
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
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:
82 Programacin de aplicaciones cliente
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
Captulo 3. Visin general sobre SQL incorporado 83
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.
Conceptos relacionados:
v Precompilacin de archivos fuente que contienen SQL incorporado en la
pgina 84
v Requisitos del archivo fuente para aplicaciones de SQL incorporado en la
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
Consulta relacionada:
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.
84 Programacin de aplicaciones cliente
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
Captulo 3. Visin general sobre SQL incorporado 85
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.
Conceptos relacionados:
v Creacin de versiones de paquetes en la pgina 90
Consulta relacionada:
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.
86 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Ventajas de la vinculacin diferida en la pgina 94
Captulo 3. Visin general sobre SQL incorporado 87
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
Consulta relacionada:
v Mandato PRECOMPILE en el manual Consulta de mandatos
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.
88 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Procedimientos almacenados de DB2 en la pgina 23
Tareas relacionadas:
v Creacin y ejecucin de aplicaciones REXX en la pgina 383
v Creacin de applets JDBC en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones JDBC en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de applets SQLJ en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones SQLJ en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones C en AIX en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones C++ en AIX en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones IBM COBOL en AIX en el manual Gua de
desarrollo de aplicaciones: Creacin y ejecucin de aplicaciones
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
Captulo 3. Visin general sobre SQL incorporado 89
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)).
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
v Mandato PRECOMPILE en el manual Consulta de mandatos
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
90 Programacin de aplicaciones cliente
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).
Conceptos relacionados:
v Indicaciones horarias generadas por el precompilador en la pgina 96
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
v Mandato PRECOMPILE en el manual Consulta de mandatos
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.
Captulo 3. Visin general sobre SQL incorporado 91
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.
Consulta relacionada:
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.
Consulta relacionada:
v SET CURRENT PACKAGESET sentencia en el manual Consulta de SQL,
Volumen 2
v Mandato BIND en el manual Consulta de mandatos
92 Programacin de aplicaciones cliente
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.
Captulo 3. Visin general sobre SQL incorporado 93
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.
Conceptos relacionados:
v Binding utilities to the database en el manual Administration Guide:
Implementation
v Conversin de caracteres entre distintas pginas de cdigos en la pgina
436
v Sustitucin de caracteres durante conversiones de pginas de cdigos en
la pgina 438
v Factor de expansin de conversin de pgina de cdigos en la pgina 440
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
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.
Consulta relacionada:
v sqlabndx - Bind en el manual Administrative API Reference
94 Programacin de aplicaciones cliente
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.
Consulta relacionada:
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
Captulo 3. Visin general sobre SQL incorporado 95
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.
Conceptos relacionados:
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
96 Programacin de aplicaciones cliente
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:
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. Luego genere la aplicacin asociada A2.
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.
Conceptos relacionados:
v Creacin de paquetes mediante el mandato BIND en la pgina 89
Captulo 3. Visin general sobre SQL incorporado 97
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.
Conceptos relacionados:
v Statement dependencies when changing objects en el manual
Administration Guide: Implementation
98 Programacin de aplicaciones cliente
Consulta relacionada:
v Mandato BIND en el manual Consulta de mandatos
v Mandato REBIND en el manual Consulta de mandatos
Captulo 3. Visin general sobre SQL incorporado 99
100 Programacin de aplicaciones cliente
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
Variables del lenguaje principal en
programas de SQL esttico. . . . . . . 106
Variables del lenguaje principal en SQL
esttico . . . . . . . . . . . . 106
Declaracin de variables del lenguaje
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
programas de SQL esttico. . . . . . 119
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
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.
Copyright IBM Corp. 1993-2002 101
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.
102 Programacin de aplicaciones cliente
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.
Consulta relacionada:
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
Conceptos relacionados:
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
Tareas relacionadas:
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
de aplicaciones: Creacin y ejecucin de aplicaciones
Consulta relacionada:
104 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Captulo 4. Cmo escribir programas de SQL esttico 105
Tareas relacionadas:
v Declaracin de variables del lenguaje principal en programas de SQL
esttico en la pgina 108
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 Seleccin de varias filas utilizando un cursor en la pgina 118
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.
106 Programacin de aplicaciones cliente
v El precompilador desconoce las normas de establecimiento de mbito de
variables del lenguaje principal.
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);
.
.
.
Captulo 4. Cmo escribir programas de SQL esttico 107
}
foo2(int x){
.
.
.
y=x;
.
.
.
}
Conceptos relacionados:
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
Tareas relacionadas:
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Declaracin de variables del lenguaje principal en programas de SQL
esttico en la pgina 108
v Cmo hacer referencia a variables del lenguaje principal en programas de
SQL esttico en la pgina 110
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.
108 Programacin de aplicaciones cliente
Tabla 4. Declaraciones de variables del lenguaje principal por lenguaje principal
Lenguaje Cdigo fuente de ejemplo
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;
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
short dept=38, age=26;
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
Tareas relacionadas:
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Cmo hacer referencia a variables del lenguaje principal en programas de
SQL esttico en la pgina 110
Captulo 4. Cmo escribir programas de SQL esttico 109
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
Lenguaje Cdigo fuente de ejemplo
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
Tareas relacionadas:
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Declaracin de variables del lenguaje principal en programas de SQL
esttico en la pgina 108
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
110 Programacin de aplicaciones cliente
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
Lenguaje Cdigo fuente de ejemplo
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.
Captulo 4. Cmo escribir programas de SQL esttico 111
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.
112 Programacin de aplicaciones cliente
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).
Tareas relacionadas:
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Declaracin de variables del lenguaje principal en programas de SQL
esttico en la pgina 108
v Cmo hacer referencia a variables del lenguaje principal en programas de
SQL esttico en la pgina 110
Consulta relacionada:
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.
Captulo 4. Cmo escribir programas de SQL esttico 113
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.
114 Programacin de aplicaciones cliente
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:
Captulo 4. Cmo escribir programas de SQL esttico 115
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.
Conceptos relacionados:
v Consideraciones sobre la conversin de datos en el manual Gua de
desarrollo de aplicaciones: Programacin de aplicaciones de servidor
v Conversin de caracteres entre distintas pginas de cdigos en la pgina
436
Consulta relacionada:
v CREATE TABLE sentencia en el manual Consulta de SQL, Volumen 2
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
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.
EXEC SQL BEGIN DECLARE SECTION;
char wd[3];
short wd_ind;
char firstname[13];
EXEC SQL END DECLARE SECTION;
/* conectar con base de datos de ejemplo */
EXEC SQL SELECT FIRSTNME, WORKDEPT
INTO :firstname, :wd:wdind
FROM EMPLOYEE
WHERE LASTNAME = JOHNSON;
116 Programacin de aplicaciones cliente
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:
EXEC SQL BEGIN DECLARE SECTION;
SQL TYPE IS BLOB_FILE blobFilePhoto;
char photoFormat[10];
char empno[7];
short lobind;
EXEC SQL END DECLARE SECTION;
/* 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.
Conceptos relacionados:
v Programa de SQL esttico de ejemplo en la pgina 103
Tareas relacionadas:
v Inclusin de variables de indicador en programas de SQL esttico en la
pgina 110
Consulta relacionada:
v Tipos de datos para variables de indicador en programas de SQL esttico
en la pgina 113
Ejemplos relacionados:
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++)
Captulo 4. Cmo escribir programas de SQL esttico 117
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.
Conceptos relacionados:
v Ejemplo de un cursor en un programa de SQL esttico en la pgina 122
118 Programacin de aplicaciones cliente
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
Lenguaje Cdigo fuente de ejemplo
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
EXEC SQL DECLARE C1 CURSOR FOR
SELECT NAME, DEPT FROM STAFF
WHERE JOB=:host-var END-EXEC.
FORTRAN
EXEC SQL DECLARE C1 CURSOR FOR
+ SELECT NAME, DEPT FROM STAFF
+ WHERE JOB=:host_var
Conceptos relacionados:
v Consideraciones sobre tipos de cursor y unidad de trabajo en la pgina
120
Tareas relacionadas:
v Seleccin de varias filas utilizando un cursor en la pgina 118
Consulta relacionada:
Captulo 4. Cmo escribir programas de SQL esttico 119
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.
120 Programacin de aplicaciones cliente
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.
Captulo 4. Cmo escribir programas de SQL esttico 121
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.
Tareas relacionadas:
v Seleccin de varias filas utilizando un cursor en la pgina 118
v Declaracin y utilizacin de cursores en programas de SQL esttico en la
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:
122 Programacin de aplicaciones cliente
// 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
#sql {FETCH :cur2 INTO :deptnumb, :deptname};
// recuperar y mostrar el resultado de la sentencia SELECT
while (!cur2.endFetch())
{
System.out.println(deptnumb + ", " + deptname);
#sql {FETCH :cur2 INTO :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
EXEC SQL DECLARE c1 CURSOR FOR
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.
Conceptos relacionados:
v Consideraciones sobre tipos de cursor y unidad de trabajo en la pgina
120
v Recuperacin de mensajes de error en una aplicacin en la pgina 137
Tareas relacionadas:
v Seleccin de varias filas utilizando un cursor en la pgina 118
v Declaracin y utilizacin de cursores en programas de SQL esttico en la
pgina 119
Consulta relacionada:
v Tipos de cursor en la pgina 125
Captulo 4. Cmo escribir programas de SQL esttico 123
Ejemplos relacionados:
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.
124 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Consultas en el manual Consulta de SQL, Volumen 1
Consulta relacionada:
v Mandato PRECOMPILE en el manual Consulta de mandatos
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.
Captulo 4. Cmo escribir programas de SQL esttico 125
Conceptos relacionados:
v Modalidades de cursor soportadas en IBM OLE DB Provider en la pgina
396
Tareas relacionadas:
v Actualizacin y supresin de datos recuperados en programas de SQL
esttico en la pgina 124
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.
EXEC SQL DECLARE c1 CURSOR FOR
SELECT name, dept FROM staff
WHERE job=Mgr
126 Programacin de aplicaciones cliente
FOR UPDATE OF job END-EXEC.
EXEC SQL OPEN c1 END-EXEC
* llamar a FETCH y al bucle UPDATE/DELETE.
perform Fetch-Loop thru End-Fetch-Loop
until SQLCODE not equal 0.
EXEC SQL CLOSE c1 END-EXEC.
Conceptos relacionados:
v Recuperacin de mensajes de error en una aplicacin en la pgina 137
Ejemplos relacionados:
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:
Captulo 4. Cmo escribir programas de SQL esttico 127
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.
Conceptos relacionados:
v Especificacin JDBC en la pgina 295
Tareas relacionadas:
v Cmo conservar una copia de los datos en la pgina 128
v Recuperacin de datos por segunda vez en la pgina 129
Consulta relacionada:
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.
Conceptos relacionados:
v Diferencias en el orden de filas entre la primera y la segunda tabla de
resultados en la pgina 130
128 Programacin de aplicaciones cliente
Tareas relacionadas:
v Recuperacin de datos por segunda vez en la pgina 129
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:
SELECT * FROM DEPARTMENT
WHERE LOCATION = 'CALIFORNIA'
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:
SELECT * FROM DEPARTMENT
WHERE LOCATION = 'CALIFORNIA'
ORDER BY DEPTNO
Captulo 4. Cmo escribir programas de SQL esttico 129
Para recuperar las mismas filas en orden inverso, especifique que el orden
debe ser descendente, como en la siguiente sentencia:
SELECT * FROM DEPARTMENT
WHERE LOCATION = 'CALIFORNIA'
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.
Conceptos relacionados:
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
130 Programacin de aplicaciones cliente
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:
SELECT * FROM DEPARTMENT
WHERE LOCATION = 'CALIFORNIA'
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.
Tareas relacionadas:
v Recuperacin de datos por segunda vez en la pgina 129
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:
SELECT * FROM DEPARTMENT
ORDER BY DEPTNO DESC
v La sentencia siguiente coloca el cursor en la fila que tiene el valor de DEPTNO
ms alto:
SELECT * FROM DEPARTMENT
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.
Captulo 4. Cmo escribir programas de SQL esttico 131
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.
Tareas relacionadas:
v Actualizacin y supresin de datos recuperados en programas de SQL
esttico en la pgina 124
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
ejemplo para ver un programa completo que muestra cmo modificar datos
de tablas en SQLj.
132 Programacin de aplicaciones cliente
El siguiente ejemplo muestra cmo insertar datos de tablas:
#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:
#sql {UPDATE staff
SET salary = salary + 1000
WHERE id >= 310 AND dept = 84};
El siguiente ejemplo muestra cmo suprimir datos de una tabla:
#sql {DELETE FROM staff
WHERE id >= 310 AND salary > 20000};
v COBOL (updat.sqb)
Los tres ejemplos siguientes proceden del ejemplo updat. Consulte este
ejemplo para ver un programa completo que muestra cmo modificar datos
de tablas en COBOL.
El siguiente ejemplo muestra cmo insertar datos de tablas:
EXEC SQL INSERT INTO staff
VALUES (999, Testing, 99, :job-update, 0, 0, 0)
END-EXEC.
El siguiente ejemplo muestra cmo actualizar datos de tablas:
EXEC SQL UPDATE staff
SET job=:job-update
WHERE job=Mgr
END-EXEC.
El siguiente ejemplo muestra cmo suprimir datos de una tabla:
EXEC SQL DELETE
FROM staff
WHERE job=:job-update
END-EXEC.
Conceptos relacionados:
v Recuperacin de mensajes de error en una aplicacin en la pgina 137
Ejemplos relacionados:
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++)
Captulo 4. Cmo escribir programas de SQL esttico 133
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.
Consulta relacionada:
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.
134 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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 Valores de SQLSTATE y SQLCODE en Java en la pgina 335
v Variables SQLSTATE y SQLCODE en Perl en la pgina 366
Consulta relacionada:
v SQLCA en el manual Administrative API Reference
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
Captulo 4. Cmo escribir programas de SQL esttico 135
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.
Consulta relacionada:
v SQLCA en el manual Administrative API Reference
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
136 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Conceptos relacionados:
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 Valores de SQLSTATE y SQLCODE en Java en la pgina 335
v Variables SQLSTATE y SQLCODE en Perl en la pgina 366
Consulta relacionada:
v sqlaintp - Get Error Message en el manual Administrative API Reference
Captulo 4. Cmo escribir programas de SQL esttico 137
138 Programacin de aplicaciones cliente
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
Declaracin y utilizacin de cursores en
programas de SQL dinmico . . . . . 144
Ejemplo de un cursor en un programa de
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
un programa de SQL dinmico . . . . 156
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
programas de SQL dinmico . . . . . 164
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
un programa de SQL dinmico . . . . 167
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.
Copyright IBM Corp. 1993-2002 139
v Desea modificar el entorno de compilacin de la sentencia, es decir,
experimentar con los registros especiales.
Conceptos relacionados:
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.
140 Programacin de aplicaciones cliente
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 (;).
Consulta relacionada:
v Apndice A, Sentencias de SQL soportadas en la pgina 521
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.
142 Programacin de aplicaciones cliente
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.
Captulo 5. Cmo escribir programas de SQL dinmico 143
La recomendacin es utilizar SQL esttico con variables del lenguaje
principal o SQL dinmico sin marcadores de parmetros como las
opciones ms eficientes.
Conceptos relacionados:
v Ejemplo de marcadores de parmetros en un programa de SQL dinmico
en la pgina 167
Tareas relacionadas:
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:
144 Programacin de aplicaciones cliente
Tabla 9. Sentencia declare asociada con una sentencia SELECT dinmica
Lenguaje Cdigo fuente de ejemplo
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
Conceptos relacionados:
v Ejemplo de un cursor en un programa de SQL dinmico en la pgina 145
v Cursores en REXX en la pgina 381
Tareas relacionadas:
v Seleccin de varias filas utilizando un cursor en la pgina 118
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:
Captulo 5. Cmo escribir programas de SQL dinmico 145
EXEC SQL BEGIN DECLARE SECTION;
char hostVarStmt[50];
EXEC SQL END DECLARE SECTION;
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
EXEC SQL BEGIN DECLARE SECTION;
char st[80];
char parm_var[19};
EXEC SQL END DECLARE SECTION;
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:
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 st pic x(80).
01 parm-var pic x(18).
EXEC SQL END DECLARE SECTION END-EXEC.
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.
146 Programacin de aplicaciones cliente
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:
EXEC SQL BEGIN DECLARE SECTION;
char stmt1[50];
EXEC SQL END DECLARE SECTION;
strcpy(stmt1, "CREATE TABLE table1(col1 INTEGER)");
EXEC SQL EXECUTE IMMEDIATE :stmt1;
Conceptos relacionados:
v Recuperacin de mensajes de error en una aplicacin en la pgina 137
Ejemplos relacionados:
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
Captulo 5. Cmo escribir programas de SQL dinmico 147
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
148 Programacin de aplicaciones cliente
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.
Captulo 5. Cmo escribir programas de SQL dinmico 149
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
Conceptos relacionados:
v Consideraciones sobre autorizacin para SQL dinmico en la pgina 61
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
150 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Ejemplo de un cursor en un programa de SQL dinmico en la pgina 145
Consulta relacionada:
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.
Captulo 5. Cmo escribir programas de SQL dinmico 151
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)
152 Programacin de aplicaciones cliente
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.
Tareas relacionadas:
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
Consulta relacionada:
v SQLDA en el manual Administrative API Reference
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;
Captulo 5. Cmo escribir programas de SQL dinmico 153
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.
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 +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.
No se establece ninguna entrada SQLVAR y SQLDOUBLED se establece en
blanco. Se emite un aviso SQLCODE +238 (SQLSTATE 01005)
(independientemente del valor de la opcin de vinculacin SQLWARN).
154 Programacin de aplicaciones cliente
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.
Tareas relacionadas:
v Declaracin de la estructura SQLDA en un programa de SQL dinmico en
la pgina 151
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
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
Captulo 5. Cmo escribir programas de SQL dinmico 155
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.
Tareas relacionadas:
v Declaracin de la estructura SQLDA en un programa de SQL dinmico en
la pgina 151
v Preparacin de una sentencia de SQL dinmico utilizando la estructura
SQLDA mnima en la pgina 153
v Asignacin de una estructura SQLDA para un programa de SQL
dinmico en la pgina 158
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.
156 Programacin de aplicaciones cliente
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.
Tareas relacionadas:
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
Captulo 5. Cmo escribir programas de SQL dinmico 157
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.
Conceptos relacionados:
v Uso de objetos grandes en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
Tareas relacionadas:
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.
158 Programacin de aplicaciones cliente
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.
Captulo 5. Cmo escribir programas de SQL dinmico 159
La tabla siguiente muestra la declaracin y uso de una estructura SQLDA con
un elemento SQLVAR.
Lenguaje Cdigo fuente de ejemplo
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
160 Programacin de aplicaciones cliente
Lenguaje Cdigo fuente de ejemplo
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
Captulo 5. Cmo escribir programas de SQL dinmico 161
nmero deseado de elementos SQLVAR. Asegrese de declarar el nmero
suficiente de elementos SQLVAR segn los requisitos de la aplicacin.
Tareas relacionadas:
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 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
162 Programacin de aplicaciones cliente
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.
Tareas relacionadas:
v Descripcin de una sentencia SELECT en un programa de SQL dinmico
en la pgina 156
v Adquisicin de almacenamiento para albergar una fila en la pgina 157
v Proceso del cursor en un programa de SQL dinmico en la pgina 158
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.
Captulo 5. Cmo escribir programas de SQL dinmico 163
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.
Conceptos relacionados:
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.
Consulta relacionada:
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:
164 Programacin de aplicaciones cliente
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.
Tareas relacionadas:
v Declaracin de la estructura SQLDA en un programa de SQL dinmico en
la pgina 151
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 Descripcin de una sentencia SELECT en un programa de SQL dinmico
en la pgina 156
v Adquisicin de almacenamiento para albergar una fila en la pgina 157
v Proceso del cursor en un programa de SQL dinmico en la pgina 158
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
Captulo 5. Cmo escribir programas de SQL dinmico 165
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
166 Programacin de aplicaciones cliente
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.
Consulta relacionada:
v PREPARE sentencia en el manual Consulta de SQL, Volumen 2
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:
EXEC SQL BEGIN DECLARE SECTION;
char hostVarStmt1[50];
short hostVarDeptnumb;
EXEC SQL END DECLARE SECTION;
/* preparar la sentencia con un marcador de parmetro */
strcpy(hostVarStmt1, "DELETE FROM org WHERE deptnumb = ?");
EXEC SQL PREPARE Stmt1 FROM :hostVarStmt1;
Captulo 5. Cmo escribir programas de SQL dinmico 167
/* 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:
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 pname pic x(10).
01 dept pic s9(4) comp-5.
01 st pic x(127).
01 parm-var pic x(5).
EXEC SQL END DECLARE SECTION END-EXEC.
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.
perform Fetch-Loop thru End-Fetch-Loop
until SQLCODE not equal 0.
EXEC SQL CLOSE c1 END-EXEC.
Conceptos relacionados:
v Recuperacin de mensajes de error en una aplicacin en la pgina 137
168 Programacin de aplicaciones cliente
Ejemplos relacionados:
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.
Captulo 5. Cmo escribir programas de SQL dinmico 169
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.
170 Programacin de aplicaciones cliente
Consulta relacionada:
v Apndice A, Sentencias de SQL soportadas en la pgina 521
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.
Captulo 5. Cmo escribir programas de SQL dinmico 171
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.
172 Programacin de aplicaciones cliente
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.
Captulo 5. Cmo escribir programas de SQL dinmico 173
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.
Conceptos relacionados:
v Recurso de rastreo de CLI/ODBC/JDBC en la pgina 313
Tareas relacionadas:
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
174 Programacin de aplicaciones cliente
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 . . . . . . . . . . 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
Sintaxis de las variables del lenguaje
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
Sintaxis de las variables del lenguaje
principal de objeto grande (LOB) en C o
C++ . . . . . . . . . . . . . 195
Sintaxis de las variables del lenguaje
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
Copyright IBM Corp. 1993-2002 175
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.
Consulta relacionada:
v Programas de ejemplo C/C++ en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
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:
176 Programacin de aplicaciones cliente
.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
178 Programacin de aplicaciones cliente
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.
SQLE850A (sqle850a.h)
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
sistema principal. La API CREATE DATABASE utiliza este archivo.
SQLE850B (sqle850b.h)
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 037 (EBCDIC ingls de EE.UU.)
del sistema principal. La API CREATE DATABASE utiliza este
archivo.
SQLE932A (sqle932a.h)
Si la pgina de cdigos de la base de datos es 932 (ASCII japons),
esta secuencia clasifica series de caracteres que no son FOR BIT DATA
segn la clasificacin binaria CCSID 5035 (EBCDIC japons) del
sistema principal. La API CREATE DATABASE utiliza este archivo.
SQLE932B (sqle932b.h)
Si la pgina de cdigos de la base de datos es 932 (ASCII japons),
esta secuencia clasifica series de caracteres que no son FOR BIT DATA
segn la clasificacin binaria CCSID 5026 (EBCDIC japons) del
sistema principal. La API CREATE DATABASE utiliza este archivo.
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.
Captulo 6. Programacin en C y C++ 179
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.
Conceptos relacionados:
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
180 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Expansin de macros en C en la pgina 200
Consulta relacionada:
v PREPARE sentencia en el manual Consulta de SQL, Volumen 2
v Archivos include para C y C++ en la pgina 177
Captulo 6. Programacin en C y C++ 181
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
182 Programacin de aplicaciones cliente
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.
Consulta relacionada:
v Apndice A, Sentencias de SQL soportadas en la pgina 521
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.
Captulo 6. Programacin en C y C++ 183
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.
Conceptos relacionados:
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 Sintaxis de las variables del lenguaje principal de tipo carcter fijas y
terminadas en nulo en C y C++ en la pgina 189
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
Consulta relacionada:
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 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
184 Programacin de aplicaciones cliente
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:
EXEC SQL BEGIN DECLARE SECTION;
char varsql; /* permitido */
char sqlvar; /* no permitido */
char SQL_VAR; /* no permitido */
EXEC SQL END DECLARE SECTION;
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)
{
EXEC SQL BEGIN DECLARE SECTION;
short host_var_1;
EXEC SQL END DECLARE SECTION;
EXEC SQL SELECT COL1 INTO :host_var_1 from TBL1;
}
void f2(int i)
{
EXEC SQL BEGIN DECLARE SECTION;
short host_var_2;
EXEC SQL END DECLARE SECTION;
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)
{
EXEC SQL BEGIN DECLARE SECTION;
char host_var_3[25];
EXEC SQL END DECLARE SECTION;
EXEC SQL SELECT COL2 INTO :host_var_3 FROM TBL2;
}
void f4(int i)
Captulo 6. Programacin en C y C++ 185
{
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.
Conceptos relacionados:
v Declaraciones de variables del lenguaje principal en C y C++ en la pgina
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.
Conceptos relacionados:
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 Variables grficas del lenguaje principal en C y C++ en la pgina 191
v Soporte de estructuras del lenguaje principal en C y C++ en la pgina 201
v Miembros de datos de clase utilizados como variables del lenguaje
principal en C y C++ en la pgina 208
Tareas relacionadas:
186 Programacin de aplicaciones cliente
v Declaracin de variables del lenguaje principal con el Generador de
declaraciones db2dclgn en la pgina 38
v Declaracin de variables del lenguaje principal de tipo estructurado en el
manual Gua de desarrollo de aplicaciones: Programacin de aplicaciones de
servidor
Consulta relacionada:
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
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
Captulo 6. Programacin en C y C++ 187
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.
188 Programacin de aplicaciones cliente
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
Captulo 6. Programacin en C y C++ 189
Sintaxis de las variables del lenguaje principal de tipo carcter de
longitud variable en C o C++
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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.
190 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Conceptos relacionados:
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
Captulo 6. Programacin en C y C++ 191
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.
Conceptos relacionados:
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 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 Tablas de indicadores en C y C++ en la pgina 203
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
Consulta relacionada:
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
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.
192 Programacin de aplicaciones cliente
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.
Captulo 6. Programacin en C y C++ 193
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.
Conceptos relacionados:
v Series terminadas en nulo en C y C++ en la pgina 205
v Tipos de datos wchar_t y sqldbchar en C y C++ en la pgina 211
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
194 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Tipos de datos wchar_t y sqldbchar en C y C++ en la pgina 211
Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
C o C++
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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
Captulo 6. Programacin en C y C++ 195
={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.
196 Programacin de aplicaciones cliente
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"};
Tiene como resultado la generacin de la estructura siguiente:
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");
Captulo 6. Programacin en C y C++ 197
Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en C o C++
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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;
198 Programacin de aplicaciones cliente
Sintaxis de declaraciones de variables del lenguaje principal de referencia
de archivos en C o C++
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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;
Tiene como resultado la generacin de la estructura siguiente:
static volatile struct {
sqluint32 name_length;
sqluint32 data_length;
sqluint32 file_options;
char name[255];
} my_file;
Captulo 6. Programacin en C y C++ 199
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:
EXEC SQL BEGIN DECLARE SECTION;
short my_short_2 = 5; /* correcto */
short my_short_1(5); /* incorrecto */
EXEC SQL END DECLARE SECTION;
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
200 Programacin de aplicaciones cliente
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
EXEC SQL BEGIN DECLARE SECTION;
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;
EXEC SQL END DECLARE SECTION;
Las declaraciones anteriores se resuelven de la manera siguiente despus de
utilizar la opcin PREPROCESSOR:
EXEC SQL BEGIN DECLARE SECTION;
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;
EXEC SQL END DECLARE SECTION;
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:
Captulo 6. Programacin en C y C++ 201
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.
EXEC SQL SELECT id, name, years, salary
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
202 Programacin de aplicaciones cliente
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).
Conceptos relacionados:
v Tablas de indicadores en C y C++ en la pgina 203
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:
EXEC SQL SELECT id, name, years, salary
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]
Captulo 6. Programacin en C y C++ 203
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;
EXEC SQL SELECT id, name, years, salary
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].
Conceptos relacionados:
v Soporte de estructuras del lenguaje principal en C y C++ en la pgina 201
204 Programacin de aplicaciones cliente
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
lenguaje principal de destino, SQLWARN1
se establece en 'N' 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
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
especificado una variable de indicador con
la variable del lenguaje principal, el valor
de la variable de indicador se establece en
0.
Para la entrada:
Cuando el gestor de bases de datos encuentre una variable
del lenguaje principal de entrada que tiene uno de estos
Captulo 6. Programacin en C y C++ 205
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
lenguaje principal de destino, SQLWARN1
se establece en 'W' y SQLCODE es 0
(SQLSTATE 01004). El carcter nmero n se
establece como terminador nulo. 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 + 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
especificado una variable de indicador con
la variable del lenguaje principal, el valor
de la variable de indicador se establece en
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
especificado una variable de indicador con
la variable del lenguaje principal, el valor
de la variable de indicador se establece en
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.
206 Programacin de aplicaciones cliente
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:
EXEC SQL BEGIN DECLARE SECTION;
char (*arr)[10]; /* correcto */
char *(arr); /* incorrecto */
char *arr[10]; /* incorrecto */
EXEC SQL END DECLARE SECTION;
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:
EXEC SQL BEGIN DECLARE SECTION;
char (*mychar)[20]; /* Puntero a matriz de caracteres de 20 bytes */
EXEC SQL END DECLARE SECTION;
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.
Captulo 6. Programacin en C y C++ 207
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:
EXEC SQL BEGIN DECLARE SECTION;
char staff_name[20];
short int staff_id;
double staff_salary;
EXEC SQL END DECLARE SECTION;
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.
208 Programacin de aplicaciones cliente
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 )
{
EXEC SQL BEGIN DECLARE SECTION;
short &otherID = otherGuy.staff_id
double otherSalary;
EXEC SQL END DECLARE SECTION;
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
Captulo 6. Programacin en C y C++ 209
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:
EXEC SQL BEGIN DECLARE SECTION;
char (& localName)[20] = ::name;
EXEC SQL END DECLARE SECTION;
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.
Conceptos relacionados:
v Variables grficas del lenguaje principal en C y C++ en la pgina 191
v Tipos de datos wchar_t y sqldbchar en C y C++ en la pgina 211
210 Programacin de aplicaciones cliente
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).
Conceptos relacionados:
v Opcin del precompilador WCHARTYPE en C y C++ en la pgina 211
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:
Captulo 6. Programacin en C y C++ 211
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
212 Programacin de aplicaciones cliente
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
Captulo 6. Programacin en C y C++ 213
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
214 Programacin de aplicaciones cliente
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.
Consulta relacionada:
v PREPARE sentencia en el manual Consulta de SQL, Volumen 2
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.
Captulo 6. Programacin en C y C++ 215
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.
Conceptos relacionados:
v Consideraciones sobre los juegos de cdigos EUC y UCS-2 de japons y
chino tradicional en la pgina 444
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:
EXEC SQL BEGIN DECLARE SECTION;
.
.
.
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 */
216 Programacin de aplicaciones cliente
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;
sqldbchar data[100];
} vargraphic1; /* tipo de SQL 464 */
/* Precompilado con la
opcin WCHARTYPE NOCONVERT */
struct {
short len;
wchar_t data[100];
} vargraphic2; /* tipo de SQL 464 */
/* Precompilado con la
opcin WCHARTYPE CONVERT */
struct {
short len;
sqldbchar data[10000];
} long_vargraphic1; /* tipo de SQL 472 */
/* Precompilado con la
opcin WCHARTYPE NOCONVERT */
struct {
short len;
wchar_t data[10000];
} long_vargraphic2; /* tipo de SQL 472 */
/* Precompilado con la
opcin WCHARTYPE CONVERT */
sqldbchar graphic1[100]; /* tipo de SQL 468 */
/* Precompilado con la
opcin WCHARTYPE NOCONVERT */
Captulo 6. Programacin en C y C++ 217
wchar_t graphic2[100]; /* tipo de SQL 468 */
/* Precompilado con la
opcin WCHARTYPE CONVERT */
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 */
.
.
.
EXEC SQL END DECLARE SECTION;
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
Entero con signo de 32 bits
BIGINT
(492 493)
long long
long
__int64
sqlint64
3
Entero con signo de 64 bits
REAL
4
(480 481)
float Coma flotante de precisin simple
DOUBLE
5
(480 481)
double Coma flotante de precisin doble
218 Programacin de aplicaciones cliente
Tabla 13. Tipos de datos SQL correlacionados con declaraciones C/C++ (continuacin)
Tipo de columna SQL
1
Tipo de datos C/C++ Descripcin del tipo de columna SQL
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)
No existe un equivalente exacto;
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
suficientemente grande para
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
Serie de caracteres de longitud variable no
terminada en nulo con indicador de longitud
de serie de 2 bytes
CLOB(n)
(408 409)
sql type is
clob(n)
1<=n<=2 147 483 647
Serie de caracteres de longitud variable no
terminada en nulo con indicador de longitud
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
Variable de referencia de archivo
BLOB
6
(916 917)
sql type is
blob_file
Descriptor del archivo que contiene datos
BLOB
Captulo 6. Programacin en C y C++ 219
Tabla 13. Tipos de datos SQL correlacionados con declaraciones C/C++ (continuacin)
Tipo de columna SQL
1
Tipo de datos C/C++ Descripcin del tipo de columna SQL
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
Admitir como mnimo 9 caracteres para
acomodar el terminador nulo.
Formato estructurado VARCHAR Admitir como mnimo 8 caracteres.
TIMESTAMP
(392 393)
Formato de caracteres terminado
en nulo
Admitir como mnimo 27 caracteres para
acomodar el terminador nulo.
Formato estructurado VARCHAR Admitir como mnimo 26 caracteres.
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)
No existe un equivalente exacto;
utilice sqldbchar[n+1], donde n es
suficientemente grande para
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
Serie de caracteres de doble byte y longitud
variable no terminada en nulo con indicador
de longitud de serie de 2 bytes
Como alternativa, utilice
sqldbchar[n+1], donde n es
suficientemente grande para
contener los datos
1<=n<=16 336
Serie de caracteres de doble byte y longitud
variable terminada en nulo
Nota: se le asigna un tipo SQL de 400/401.
LONG VARGRAPHIC
(472 473)
struct tag {
short int;
sqldbchar[n]
}
16 337<=n<=16 350
Serie de caracteres de doble byte y longitud
variable no terminada en nulo con indicador
de longitud de serie de 2 bytes
Nota: los tipos de datos siguientes slo estn disponibles en los entornos DBCS o EUC si se compilan previamente
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)
No existe un equivalente exacto;
utilice wchar_t [n+1], donde n es
suficientemente grande para
contener los datos
1<=n<=127
Serie de caracteres de doble byte y longitud
fija
220 Programacin de aplicaciones cliente
Tabla 13. Tipos de datos SQL correlacionados con declaraciones C/C++ (continuacin)
Tipo de columna SQL
1
Tipo de datos C/C++ Descripcin del tipo de columna SQL
VARGRAPHIC(n)
(464 465)
struct tag {
short int;
wchar_t [n]
}
1<=n<=16 336
Serie de caracteres de doble byte y longitud
variable no terminada en nulo con indicador
de longitud de serie de 2 bytes
Como alternativa, utilice
char[n+1], donde n es
suficientemente grande para
contener los datos
1<=n<=16 336
Serie de caracteres de doble byte y longitud
variable terminada en nulo
Nota: se le asigna un tipo SQL de 400/401.
LONG VARGRAPHIC
(472 473)
struct tag {
short int;
wchar_t [n]
}
16 337<=n<=16 350
Serie de caracteres de doble byte y longitud
variable no terminada en nulo con indicador
de longitud de serie de 2 bytes
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
Serie de caracteres de doble byte y longitud
variable no terminada en nulo con indicador
de longitud de serie de 4 bytes
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
Descriptor del archivo que contiene datos
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.
Captulo 6. Programacin en C y C++ 221
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.
Conceptos relacionados:
v Seccin declare de SQL con variables del lenguaje principal para C y C++
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).
Conceptos relacionados:
v Seccin declare de SQL con variables del lenguaje principal para C y C++
en la pgina 216
Consulta relacionada:
222 Programacin de aplicaciones cliente
v Tipos de datos SQL soportados en C y C++ en la pgina 218
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)
float Coma flotante de precisin simple
DOUBLE
(480 481)
double Coma flotante de precisin doble
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
suficientemente grande para
contener los datos
1<=n<=254
Serie de caracteres de longitud fija terminada
en nulo
CHAR(n) FOR BIT DATA
(452 453)
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) (460 461)
char[n+1] donde n es
suficientemente grande para
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
Serie de caracteres de longitud variable no
terminada en nulo
LONG VARCHAR
(456 457)
struct {
sqluint16 length;
char[n]
}
32 673<=n<=32 700
Serie de caracteres de longitud variable no
terminada en nulo
Captulo 6. Programacin en C y C++ 223
Tabla 14. Tipos de datos SQL correlacionados con declaraciones C/C++ (continuacin)
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
Serie de caracteres de longitud variable no
terminada en nulo con indicador de longitud
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
terminada en nulo con indicador de longitud
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
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(n)
(468 469)
sqldbchar[n+1] donde n es
suficientemente grande para
contener los datos
1<=n<=127
Serie de caracteres de doble byte y longitud
fija terminada en nulo
VARGRAPHIC(n)
(400 401)
sqldbchar[n+1] donde n es
suficientemente grande para
contener los datos
1<=n<=16 336
Serie de caracteres de doble byte y longitud
variable no terminada en nulo
LONG VARGRAPHIC
(472 473)
struct {
sqluint16 length;
sqldbchar[n]
}
16 337<=n<=16 350
Serie de caracteres de doble byte y longitud
variable no terminada en nulo
DBCLOB(n)
(412 413)
struct {
sqluint32 length;
sqldbchar data[n];
}
1<=n<=1 073 741 823
Serie de caracteres de longitud variable no
terminada en nulo con indicador de longitud
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:
224 Programacin de aplicaciones cliente
EXEC SQL BEGIN DECLARE SECTION;
char SQLSTATE[6]
sqlint32 SQLCODE;
.
.
.
EXEC SQL END DECLARE SECTION;
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 6. Programacin en C y C++ 225
226 Programacin de aplicaciones cliente
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
Copyright IBM Corp. 1993-2002 227
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.
Conceptos relacionados:
v Transacciones simultneas en la pgina 469
Consulta relacionada:
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
Administrative API Reference
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
Administrative API Reference
228 Programacin de aplicaciones cliente
Ejemplos relacionados:
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.
Conceptos relacionados:
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
230 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Conceptos relacionados:
v Problemas potenciales con varias hebras en la pgina 230
232 Programacin de aplicaciones cliente
Captulo 8. Programacin en COBOL
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
Variables del lenguaje principal en
COBOL . . . . . . . . . . . . 240
Nombres de variables del lenguaje
principal en COBOL . . . . . . . . 241
Declaraciones de variables del lenguaje
principal en COBOL . . . . . . . . 242
Sintaxis de las variables numricas del
lenguaje principal en COBOL . . . . . 242
Sintaxis de las variables del lenguaje
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
Sintaxis de las variables del lenguaje
principal LOB en COBOL . . . . . . 246
Sintaxis de las variables del lenguaje
principal de localizador de LOB en
COBOL . . . . . . . . . . . . 248
Sintaxis de las variables del lenguaje
principal de referencia de archivos en
COBOL . . . . . . . . . . . . 248
Soporte de estructura del lenguaje
principal en COBOL . . . . . . . . 249
Tablas de indicadores en COBOL . . . 251
REDEFINES en elementos de datos de
grupos COBOL . . . . . . . . . 252
Seccin declare de SQL con variables del
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
Consideraciones sobre EUC en japons o
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
restricciones de lenguaje, los archivos include especficos del lenguaje
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.
Consulta relacionada:
v Programas de ejemplo COBOL en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
Copyright IBM Corp. 1993-2002 233
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.
234 Programacin de aplicaciones cliente
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)
Este archivo define constantes para el campo SQLCODE de la
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)
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.
SQLE850A (sqle850a.cbl)
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 sistema principal. La API CREATE
DATABASE utiliza este archivo.
SQLE850B (sqle850b.cbl)
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 037
(EBCDIC ingls de EE.UU.) del sistema principal. La API
CREATE DATABASE utiliza este archivo.
SQLE932A (sqle932a.cbl)
Si la pgina de cdigos de la base de datos es 932 (ASCII
japons), esta secuencia clasifica series de caracteres que no
son FOR BIT DATA segn la clasificacin binaria CCSID 5035
(EBCDIC japons) del sistema principal. La API CREATE
DATABASE utiliza este archivo.
SQLE932B (sqle932b.cbl)
Si la pgina de cdigos de la base de datos es 932 (ASCII
japons), esta secuencia clasifica series de caracteres que no
son FOR BIT DATA segn la clasificacin binaria CCSID 5026
(EBCDIC japons) del sistema principal. La API CREATE
DATABASE utiliza este archivo.
SQL1252A (sql1252a.cbl)
Si la pgina de cdigos de la base de datos es 1252 (Windows
236 Programacin de aplicaciones cliente
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.
SQL1252B (sql1252b.cbl)
Si la pgina de cdigos de la base de datos es 1252 (Windows
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.
SQLMON (sqlmon.cbl)
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.
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)
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.
Sentencias de SQL incorporado en COBOL
Las sentencias de SQL incorporado constan de los tres elementos siguientes:
Captulo 8. Programacin en COBOL 237
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.
Se aplican las normas siguientes a las sentencias de SQL incorporado:
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.
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 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.
238 Programacin de aplicaciones cliente
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
absoluta, se utiliza el contenido de DB2INCLUDE para buscar el archivo,
aadindole como prefijo la va de acceso especificada en el nombre del
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.
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.
Captulo 8. Programacin en COBOL 239
Si aparecen dentro de las comillas, los caracteres de fin de lnea
desaparecen, siempre que se contine correctamente la serie para un
programa COBOL. 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, 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.
Consulta relacionada:
v Apndice A, Sentencias de SQL soportadas en la pgina 521
Variables del lenguaje principal en COBOL
Las secciones siguientes describen cmo declarar y utilizar variables del
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.
Conceptos relacionados:
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
Consulta relacionada:
v Sintaxis de las variables numricas del lenguaje principal en COBOL en
la pgina 242
v Sintaxis de las variables del lenguaje principal de tipo carcter de longitud
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
COBOL en la pgina 248
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
COBOL en la pgina 248
240 Programacin de aplicaciones cliente
Nombres de variables del lenguaje principal en COBOL
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, 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.
Conceptos relacionados:
v Declaraciones de variables del lenguaje principal en COBOL en la pgina
242
Consulta relacionada:
v Sintaxis de las variables numricas del lenguaje principal en COBOL en
la pgina 242
v Sintaxis de las variables del lenguaje principal de tipo carcter de longitud
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
COBOL en la pgina 248
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
COBOL en la pgina 248
Captulo 8. Programacin en COBOL 241
Declaraciones de variables del lenguaje principal en COBOL
Se debe utilizar una seccin de declaracin de SQL para identificar las
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.
Tareas relacionadas:
v Declaracin de variables del lenguaje principal de tipo estructurado en el
manual Gua de desarrollo de aplicaciones: Programacin de aplicaciones de
servidor
Consulta relacionada:
v Sintaxis de las variables numricas del lenguaje principal en COBOL en
la pgina 242
v Sintaxis de las variables del lenguaje principal de tipo carcter de longitud
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
COBOL en la pgina 248
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
COBOL en la pgina 248
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
242 Programacin de aplicaciones cliente

(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
nombre-variable PICTURE
PIC
IS
serie-imagen
Captulo 8. Programacin en COBOL 243

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
.
49 identificador-2 PICTURE
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.
244 Programacin de aplicaciones cliente
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:
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
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).
EXEC SQL END DECLARE SECTION END-EXEC.
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
nombre-variable PICTURE
PIC
IS
serie-imagen USAGE

IS
DISPLAY-1
IS
VALUE valor
.
Longitud variable
01 nombre-variable .
Captulo 8. Programacin en COBOL 245
49 identificador-1 PICTURE
PIC
IS
S9(4)

COMP-5
IS COMPUTATIONAL-5
USAGE
IS
VALUE valor
.
49 identificador-2 PICTURE
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.
Conceptos relacionados:
v Tablas de indicadores en COBOL en la pgina 251
Sintaxis de las variables del lenguaje principal LOB en COBOL
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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

246 Programacin de aplicaciones cliente


( longitud ) .
K
M
G

Consideraciones sobre las variables del lenguaje principal LOB:


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).
Tiene como resultado la generacin de la estructura siguiente:
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).
Tiene como resultado la generacin de la estructura siguiente:
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).
Tiene como resultado la generacin de la estructura siguiente:
01 MY-DBCLOB.
49 MY-DBCLOB-LENGTH PIC S9(9) COMP-5.
49 MY-DBCLOB-DATA PIC G(30000) DISPLAY-1.
Captulo 8. Programacin en COBOL 247
Sintaxis de las variables del lenguaje principal de localizador de LOB en
COBOL
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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
.
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 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.
Tiene como resultado la generacin de la declaracin siguiente:
01 MY-LOCATOR PIC S9(9) COMP-5.
Sintaxis de las variables del lenguaje principal de referencia de archivos
en COBOL
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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):
248 Programacin de aplicaciones cliente
La declaracin:
01 MY-FILE USAGE IS SQL TYPE IS BLOB-FILE.
Tiene como resultado la generacin de la declaracin siguiente:
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:
Captulo 8. Programacin en COBOL 249
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:
EXEC SQL SELECT id, name, dept, job
INTO
:staff-record.staff-id,
:staff-record.staff-name,
:staff-record.staff-info.staff-dept,
:staff-record.staff-info.staff-job
FROM staff WHERE id = 10 END-EXEC.
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:
EXEC SQL SELECT id, name, dept, job
INTO
:staff-id,
:staff-name,
:staff-dept,
:staff-job
FROM staff WHERE id = 10 END-EXEC.
Como en COBOL puro, este mtodo resulta aceptable para el precompilador
siempre que un elemento subordinado determinado se pueda calificar de
250 Programacin de aplicaciones cliente
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:
EXEC SQL SELECT id, name, dept, job
INTO
:staff-id,
:staff-name,
:staff-info.staff-dept,
:staff-info.staff-job
FROM staff WHERE id = 10 END-EXEC.
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:
Captulo 8. Programacin en COBOL 251
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:
EXEC SQL SELECT id, name, dept, job
INTO :staff-record :staff-indicator
FROM staff WHERE id = 10 END-EXEC.
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.
Conceptos relacionados:
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 ...
252 Programacin de aplicaciones cliente
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.
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
*
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.
*
EXEC SQL END DECLARE SECTION END-EXEC.
Consulta relacionada:
v Tipos de datos de SQL soportados en COBOL en la pgina 254
Captulo 8. Programacin en COBOL 253
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.
Nota: no existe soporte de variables del lenguaje principal para el tipo de
datos DATALINK en ninguno de los lenguajes principales de DB2.
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
254 Programacin de aplicaciones cliente
Tabla 15. Tipos de datos SQL correlacionados con declaraciones COBOL (continuacin)
Tipo de columna SQL
1
Tipo de datos de COBOL Descripcin del tipo de
columna SQL
LONG VARCHAR
(456 457)
01 name.
49 length PIC S9(4) COMP-5.
49 data PIC X(n).
32 673<=n<=32 700
Serie de caracteres de
longitud variable larga
CLOB(n)
(408 409)
01 MY-CLOB USAGE IS SQL TYPE IS CLOB(n).
1<=n<=2 147 483 647
Serie de caracteres de
longitud variable y objeto
grande
Variable de localizador CLOB
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
Variable de localizador BLOB
4
(960 961)
01 MY-BLOB-LOCATOR USAGE IS SQL TYPE IS
BLOB-LOCATOR.
Identifica las entidades
BLOB que residen en el
servidor
Variable de referencia de archivo
BLOB
4
(916 917)
01 MY-CLOB-FILE USAGE IS SQL TYPE IS
CLOB-FILE.
Descriptor de archivo que
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 length PIC S9(4) COMP-5.
49 name PIC G(n) DISPLAY-1.
1<=n<=16 336
Serie de caracteres de
doble byte y longitud
variable con indicador de
longitud de serie de 2
bytes
LONG VARGRAPHIC
(472 473)
01 name.
49 length PIC S9(4) COMP-5.
49 name PIC G(n) DISPLAY-1.
16 337<=n<=16 350
Serie de caracteres de
doble byte y longitud
variable con indicador de
longitud de serie de 2
bytes
Captulo 8. Programacin en COBOL 255
Tabla 15. Tipos de datos SQL correlacionados con declaraciones COBOL (continuacin)
Tipo de columna SQL
1
Tipo de datos de COBOL Descripcin del tipo de
columna SQL
DBCLOB(n)
(412 413)
01 MY-DBCLOB USAGE IS SQL TYPE IS DBCLOB(n).
1<=n<=1 073 741 823
Serie de caracteres de
doble byte, longitud
variable y objeto grande
con indicador de longitud
de serie de 4 bytes
Variable de localizador DBCLOB
4
(968 969)
01 MY-DBCLOB-LOCATOR USAGE IS SQL TYPE IS
DBCLOB-LOCATOR.
Identifica las entidades
DBCLOB que residen en el
servidor
Variable de referencia de
archivos DBCLOB
4
(924 925)
01 MY-DBCLOB-FILE USAGE IS SQL TYPE IS
DBCLOB-FILE.
Descriptor de archivo que
contiene datos 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. 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).
3. Los tipos SQL siguientes son sinnimos de DOUBLE:
v FLOAT
v FLOAT(n) donde 24 < n < 54 es
v DOUBLE PRECISION
4. 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 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:
256 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Consulta relacionada:
v Tipos de datos de SQL soportados en COBOL en la pgina 254
Variables SQLSTATE y SQLCODE en COBOL
Cuando se utiliza la opcin de precompilacin LANGLEVEL con el valor
SQL92E, se pueden incluir las dos declaraciones siguientes como variables del
lenguaje principal:
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 SQLSTATE PICTURE X(5).
01 SQLCODE PICTURE S9(9) USAGE COMP.
.
Captulo 8. Programacin en COBOL 257
.
.
EXEC SQL END DECLARE SECTION END-EXEC.
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.
Conceptos relacionados:
v Consideraciones sobre los juegos de cdigos EUC y UCS-2 de japons y
chino tradicional en la pgina 444
Consulta relacionada:
v Funcin escalar VARCHAR en el manual Consulta de SQL, Volumen 1
v Funcin escalar VARGRAPHIC en el manual Consulta de SQL, Volumen 1
258 Programacin de aplicaciones cliente
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 8. Programacin en COBOL 259
260 Programacin de aplicaciones cliente
Captulo 9. Programacin en FORTRAN
Consideraciones sobre la programacin en
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 . . . . . . . . . . 263
Archivos include para FORTRAN . . . 263
Archivos include en aplicaciones
FORTRAN . . . . . . . . . . . 266
Sentencias de SQL incorporado en
FORTRAN . . . . . . . . . . . . 267
Variables del lenguaje principal en
FORTRAN . . . . . . . . . . . . 268
Variables del lenguaje principal en
FORTRAN . . . . . . . . . . . 269
Nombres de variables del lenguaje
principal en FORTRAN . . . . . . . 269
Declaraciones de variables del lenguaje
principal en FORTRAN . . . . . . . 270
Sintaxis de las variables numricas del
lenguaje principal en FORTRAN . . . . 271
Sintaxis de las variables de tipo carcter
del lenguaje principal en FORTRAN . . 271
Variables de indicador en FORTRAN . . 273
Sintaxis de las variables del lenguaje
principal de objeto grande (LOB) en
FORTRAN . . . . . . . . . . . 273
Sintaxis de las variables del lenguaje
principal de localizador de objeto grande
(LOB) en FORTRAN . . . . . . . . 274
Sintaxis de las variables del lenguaje
principal de referencia de archivos en
FORTRAN . . . . . . . . . . . 275
Seccin declare de SQL con variables del
lenguaje principal para FORTRAN . . . 276
Tipos de datos SQL soportados en
FORTRAN . . . . . . . . . . . . 276
Consideraciones sobre juegos de caracteres
de varios bytes en FORTRAN. . . . . . 278
Consideraciones sobre EUC en japons o
chino tradicional y UCS-2 para FORTRAN . 278
Variables SQLSTATE y SQLCODE en
FORTRAN . . . . . . . . . . . . 279
Consideraciones sobre la programacin en FORTRAN
En las secciones siguientes se explican las consideraciones especiales sobre la
programacin en el lenguaje principal. 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.
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.
Copyright IBM Corp. 1993-2002 261
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.
Consulta relacionada:
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
262 Programacin de aplicaciones cliente
embargo, puede utilizar la opcin de precompilacin OUTPUT para
especificar un nuevo nombre y va de acceso para el archivo fuente de salida
modificado.
Consulta relacionada:
v Mandato PRECOMPILE en el manual Consulta de mandatos
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
Captulo 9. Programacin en FORTRAN 263
incluye automticamente el archivo sqlca_92.f cuando la
opcin LANGLEVEL del precompilador se establece en
SQL92E.
SQLCODES (sqlcodes.f)
Este archivo define constantes para el campo SQLCODE de la
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)
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.
SQLE819A (sqle819a.f)
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.f)
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.
SQLE850A (sqle850a.f)
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 sistema principal. La API CREATE
DATABASE utiliza este archivo.
264 Programacin de aplicaciones cliente
SQLE850B (sqle850b.f)
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 037
(EBCDIC ingls de EE.UU.) del sistema principal. La API
CREATE DATABASE utiliza este archivo.
SQLE932A (sqle932a.f)
Si la pgina de cdigos de la base de datos es 932 (ASCII
japons), esta secuencia clasifica series de caracteres que no
son FOR BIT DATA segn la clasificacin binaria CCSID 5035
(EBCDIC japons) del sistema principal. La API CREATE
DATABASE utiliza este archivo.
SQLE932B (sqle932b.f)
Si la pgina de cdigos de la base de datos es 932 (ASCII
japons), esta secuencia clasifica series de caracteres que no
son FOR BIT DATA segn la clasificacin binaria CCSID 5026
(EBCDIC japons) del sistema principal. La API CREATE
DATABASE utiliza este archivo.
SQL1252A (sql1252a.f)
Si la pgina de cdigos de la base de datos es 1252 (Windows
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.
SQL1252B (sql1252b.f)
Si la pgina de cdigos de la base de datos es 1252 (Windows
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.
SQLMON (sqlmon.f)
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.f)
Este archivo define constantes correspondientes al campo
SQLSTATE de la estructura SQLCA.
SQLUTIL (sqlutil.f)
Este archivo define las llamadas especficas del lenguaje
Captulo 9. Programacin en FORTRAN 265
correspondientes a las API de programas de utilidad y las
estructuras, constantes y cdigos necesarios para dichas
interfaces.
Conceptos relacionados:
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
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, 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.
266 Programacin de aplicaciones cliente
Conceptos relacionados:
v DB2 registry and environment variables en el manual Administration
Guide: Performance
Consulta relacionada:
v Archivos include para FORTRAN en la pgina 263
Sentencias de SQL incorporado en FORTRAN
Las sentencias de SQL incorporado constan de los tres elementos siguientes:
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
Se aplican las normas siguientes a las sentencias de SQL incorporado:
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.
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 terminada por un fin de lnea.
Captulo 9. Programacin en FORTRAN 267
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.
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 FORTRAN. 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, 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.
Consulta relacionada:
v Apndice A, Sentencias de SQL soportadas en la pgina 521
Variables del lenguaje principal en FORTRAN
Las secciones siguientes describen cmo declarar y utilizar variables del
lenguaje principal en programas FORTRAN.
268 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Consulta relacionada:
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
v Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
FORTRAN en la pgina 273
v Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en FORTRAN en la pgina 274
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
FORTRAN en la pgina 275
Nombres de variables del lenguaje principal en FORTRAN
El precompilador SQL identifica las variables del lenguaje principal por el
nombre declarado para stas. Se aplican las sugerencias 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, que estn reservados para uso del sistema.
Conceptos relacionados:
v Declaraciones de variables del lenguaje principal en FORTRAN en la
pgina 270
Consulta relacionada:
v Sintaxis de las variables numricas del lenguaje principal en FORTRAN
en la pgina 271
Captulo 9. Programacin en FORTRAN 269
v Sintaxis de las variables de tipo carcter del lenguaje principal en
FORTRAN en la pgina 271
v Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
FORTRAN en la pgina 273
v Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en FORTRAN en la pgina 274
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
FORTRAN en la pgina 275
Declaraciones de variables del lenguaje principal en FORTRAN
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 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.
Tareas relacionadas:
v Declaracin de variables del lenguaje principal de tipo estructurado en el
manual Gua de desarrollo de aplicaciones: Programacin de aplicaciones de
servidor
Consulta relacionada:
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
v Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
FORTRAN en la pgina 273
v Sintaxis de las variables del lenguaje principal de localizador de objeto
grande (LOB) en FORTRAN en la pgina 274
v Sintaxis de las variables del lenguaje principal de referencia de archivos en
FORTRAN en la pgina 275
270 Programacin de aplicaciones cliente
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).
Captulo 9. Programacin en FORTRAN 271
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
Tiene como resultado la generacin de la estructura siguiente:
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
Tiene como resultado la generacin de la estructura siguiente:
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.
272 Programacin de aplicaciones cliente
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:
EXEC SQL BEGIN DECLARE SECTION
character*8 dbname, userid
sql type is varchar(18) passwd
EXEC SQL END DECLARE SECTION
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.
Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
FORTRAN
A continuacin se muestra la sintaxis para declarar variables del lenguaje
principal de objeto grande (LOB) en FORTRAN.
Sintaxis de las variables del lenguaje principal de objeto grande (LOB) en
FORTRAN


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

Consideraciones sobre las variables del lenguaje principal LOB:


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.
Captulo 9. Programacin en FORTRAN 273
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
Tiene como resultado la generacin de la estructura siguiente:
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
Tiene como resultado la generacin de la estructura siguiente:
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
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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

Consideraciones sobre las variables del lenguaje principal de localizador de


LOB:
1. Los tipos GRAPHIC no se soportan en FORTRAN.
274 Programacin de aplicaciones cliente
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
Tiene como resultado la generacin de la declaracin siguiente:
integer*4 my_locator
Sintaxis de las variables del lenguaje principal de referencia de archivos
en FORTRAN
A continuacin se muestra la sintaxis para declarar variables del lenguaje
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:
1. Los tipos GRAPHIC no se soportan en FORTRAN.
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
Tiene como resultado la generacin de la declaracin siguiente:
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 )
equivalence( my_file(5),
+ my_file_data_length )
Captulo 9. Programacin en FORTRAN 275
equivalence( my_file(9),
+ my_file_file_options )
equivalence( my_file(13),
+ 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:
EXEC SQL BEGIN DECLARE SECTION
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
EXEC SQL END DECLARE SECTION
Consulta relacionada:
v Tipos de datos SQL soportados en FORTRAN en la pgina 276
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.
Nota: no existe soporte de variables del lenguaje principal para el tipo de
datos DATALINK en ninguno de los lenguajes principales de DB2.
276 Programacin de aplicaciones cliente
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
Variable de localizador CLOB
4
(964 965)
SQL TYPE IS CLOB_LOCATOR Identifica las entidades CLOB que residen en
el servidor
Variable de referencia de archivo
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
Variable de referencia de
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
Captulo 9. Programacin en FORTRAN 277
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:
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. 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).
3. Los tipos SQL siguientes son sinnimos de DOUBLE:
v FLOAT
v FLOAT(n) donde 24 < n < 54 es
v DOUBLE PRECISION
4. ste no es un tipo de columna, sino un tipo de variable del lenguaje principal.
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.
Conceptos relacionados:
v Seccin declare de SQL con variables del lenguaje principal para
FORTRAN en la pgina 276
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
278 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Consideraciones sobre los juegos de cdigos EUC y UCS-2 de japons y
chino tradicional en la pgina 444
Consulta relacionada:
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
SQL92E, se pueden incluir las dos declaraciones siguientes como variables del
lenguaje principal:
EXEC SQL BEGIN DECLARE SECTION;
CHARACTER*5 SQLSTATE
INTEGER SQLCOD
.
.
.
EXEC SQL END DECLARE SECTION
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.
Consulta relacionada:
v Mandato PRECOMPILE en el manual Consulta de mandatos
Captulo 9. Programacin en FORTRAN 279
280 Programacin de aplicaciones cliente
Parte 3. Java
Copyright IBM Corp. 1993-2002 281
282 Programacin de aplicaciones cliente
Captulo 10. Programacin en Java
Consideraciones sobre la programacin en
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
controlador de tipo 3. . . . . . . . 293
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
Copyright IBM Corp. 1993-2002 283
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.
Consulta relacionada:
v Programas de ejemplo JDBC en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin de aplicaciones
v Programas de ejemplo SQLJ en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin 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.
284 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Conceptos relacionados:
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
286 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Captulo 10. Programacin en Java 287
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
Sistemas operativos Windows
nombre_instancia\function, donde nombre_instancia representa el
valor del valor de registro especfico de la instancia DB2INSTPROF.
288 Programacin de aplicaciones cliente
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.
Tareas relacionadas:
v Actualizacin de clases Java para tiempo de ejecucin en la pgina 289
Consulta relacionada:
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.
Captulo 10. Programacin en Java 289
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
290 Programacin de aplicaciones cliente
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)
float Coma flotante de precisin simple
DOUBLE
(480 481)
double Coma flotante de precisin doble
DECIMAL(p,s)(484 485) java.math.BigDecimal Decimal empaquetado
CHAR(n)
(452 453)
java.lang.String Serie de caracteres de longitud fija con
longitud n, donde n va de 1 a 254
CHAR(n)
FOR BIT DATA
byte[] Serie de caracteres de longitud fija con
longitud n, donde n va de 1 a 254
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
Captulo 10. Programacin en Java 291
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
Conceptos relacionados:
v Programacin en SQLj en la pgina 302
Tareas relacionadas:
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.
292 Programacin de aplicaciones cliente
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
Captulo 10. Programacin en Java 293
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
294 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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.
Conceptos relacionados:
Captulo 10. Programacin en Java 295
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();
296 Programacin de aplicaciones cliente
Ejemplo de una sentencia UPDATE
Statement stmt = con.createStatement();
stmt.executeUpdate(
"UPDATE staff " +
" SET salary = salary + 1000 " +
" WHERE id >= 310 AND dept = 84");
stmt.close();
Ejemplo de una sentencia DELETE
Statement stmt = con.createStatement();
stmt.executeUpdate("DELETE FROM staff " +
" WHERE id >= 310 AND salary > 20000");
stmt.close();
Ejemplos relacionados:
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.
Tareas relacionadas:
v Creacin de aplicaciones JDBC en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
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>:
Captulo 10. Programacin en Java 297
<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.
Tareas relacionadas:
v Creacin de applets JDBC en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin 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
298 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Tareas relacionadas:
v Configuracin del entorno Java en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
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
Captulo 10. Programacin en Java 299
v Conjuntos de resultados sensibles desplazables (tipo de desplazamiento
ResultSet.TYPE_SCROLL_SENSITIVE)
Conceptos relacionados:
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
Restricciones de la API central JDBC 2.1 impuestas por el controlador
JDBC de DB2 de tipo 4
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.
300 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
Captulo 10. Programacin en Java 301
v Restricciones de la API central de JDBC 2.1 por parte del controlador JDBC
de DB2 de tipo 2 en la pgina 299
Soporte de la API Paquete opcional de JDBC 2.1 por parte del controlador
JDBC de DB2 de tipo 4
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
302 Programacin de aplicaciones cliente
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) )
Conceptos relacionados:
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
Captulo 10. Programacin en Java 303
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.
Conceptos relacionados:
v Restricciones de DB2 en SQLj en la pgina 304
Consulta relacionada:
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
Consulta de mandatos
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
304 Programacin de aplicaciones cliente
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
Captulo 10. Programacin en Java 305
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;
#sql [ctx] itr[i] = { SELECT id, name FROM staff };
i=1;
#sql [ctx] itr[i] = { SELECT id, name FROM staff };
306 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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:
Captulo 10. Programacin en Java 307
{
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.
Conceptos relacionados:
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
308 Programacin de aplicaciones cliente
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();
Ejemplos relacionados:
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:
Captulo 10. Programacin en Java 309
{
int x;
#sql x = { VALUES( F(34) ) };
}
Conceptos relacionados:
v Referencias a funciones en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
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
Tareas relacionadas:
v Creacin de rutinas SQLJ en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin de aplicaciones
v Invocacin de procedimientos almacenados en el manual Gua de
desarrollo de aplicaciones: Programacin de aplicaciones de servidor
v Invocacin de rutinas en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
v Invocacin de UDF en el manual Gua de desarrollo de aplicaciones:
Programacin de aplicaciones de servidor
v Invocacin de funciones de tabla definidas por el usuario en el manual
Gua de desarrollo de aplicaciones: Programacin de aplicaciones de servidor
Consulta relacionada:
v Programas de ejemplo SQLJ en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin 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:
310 Programacin de aplicaciones cliente
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"
MyClass_SJProfile1.ser
...
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:
Captulo 10. Programacin en Java 311
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.
Tareas relacionadas:
v Creacin de applets SQLJ en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin de aplicaciones
v Creacin de aplicaciones SQLJ en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
v Creacin de rutinas SQLJ en el manual Gua de desarrollo de aplicaciones:
Creacin y ejecucin de aplicaciones
v Creacin de programas SQLJ en el manual Gua de desarrollo de
aplicaciones: Creacin y ejecucin de aplicaciones
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:
312 Programacin de aplicaciones cliente
db2profp -user=user-name -password=user-password -url=jdbc:db2:dbname
MyClass_SJProfile0.ser
db2profp -user=user-name -password=user-password -url=jdbc:db2:dbname
MyClass_SJProfile1.ser
...
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.
Conceptos relacionados:
v Recurso de rastreo de CLI/ODBC/JDBC en la pgina 313
v Archivos de rastreo de CLI y JDBC en la pgina 324
Consulta relacionada:
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
Captulo 10. Programacin en Java 313
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
314 Programacin de aplicaciones cliente
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
Captulo 10. Programacin en Java 315
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.
316 Programacin de aplicaciones cliente
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
Captulo 10. Programacin en Java 317
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
318 Programacin de aplicaciones cliente
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
Captulo 10. Programacin en Java 319
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
320 Programacin de aplicaciones cliente
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.
Captulo 10. Programacin en Java 321
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).
322 Programacin de aplicaciones cliente
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.
Captulo 10. Programacin en Java 323
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.
Conceptos relacionados:
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
Consulta relacionada:
v SQLSetEnvAttr Function (CLI) - Set Environment Attribute en el manual
CLI Guide and Reference, Volume 2
v db2trc - Mandato Rastrear en el manual Consulta de mandatos
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
CLI Guide and Reference, Volume 1
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
324 Programacin de aplicaciones cliente
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.
Captulo 10. Programacin en Java 325
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,
326 Programacin de aplicaciones cliente
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 )
12 > Time elapsed - +2.334000E-003 seconds
13 SQLAllocConnect( phDbc=0:1 )
14 < SQL_SUCCESS Time elapsed - +5.280000E-004 seconds
15 SQLSetConnectOption( hDbc=0:1, fOption=SQL_ATTR_AUTOCOMMIT, vParam=0 )
16 > Time elapsed - +2.301000E-003 seconds
17 SQLSetConnectOption( )
18 < SQL_SUCCESS Time elapsed - +3.150000E-004 seconds
19 SQLConnect( hDbc=0:1, szDSN="SAMPLE", cbDSN=-3, szUID="", cbUID=-3,
szAuthStr="", cbAuthStr=-3 )
20 > Time elapsed - +7.000000E-005 seconds
21 ( DBMS NAME="DB2/LINUX", Version="07.01.0000", Fixpack="0x22010105" )
22 SQLConnect( )
23 < SQL_SUCCESS Time elapsed - +5.209880E-001 seconds
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
Captulo 10. Programacin en Java 327
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 )
28 > Time elapsed - +1.868000E-003 seconds
328 Programacin de aplicaciones cliente
29 SQLAllocStmt( phStmt=1:1 )
30 < SQL_SUCCESS Time elapsed - +6.890000E-004 seconds
31 SQLExecDirect( hStmt=1:1, pszSqlStr="CREATE TABLE GREETING (MSG
VARCHAR(10))", cbSqlStr=-3 )
32 > Time elapsed - +2.863000E-003 seconds
33 ( StmtOut="CREATE TABLE GREETING (MSG VARCHAR(10))" )
34 SQLExecDirect( )
35 < SQL_SUCCESS Time elapsed - +2.387800E-002 seconds
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:
Captulo 10. Programacin en Java 329
36 SQLAllocStmt( hDbc=0:1, phStmt=&bffff684 )
37 > Time elapsed - +1.532000E-003 seconds
38 SQLAllocStmt( phStmt=1:2 )
39 < SQL_SUCCESS Time elapsed - +6.820000E-004 seconds
40 SQLPrepare( hStmt=1:2, pszSqlStr="INSERT INTO GREETING VALUES ( ? )",
cbSqlStr=-3 )
41 > Time elapsed - +2.733000E-003 seconds
42 ( StmtOut="INSERT INTO GREETING VALUES ( ? )" )
43 SQLPrepare( )
44 < SQL_SUCCESS Time elapsed - +9.150000E-004 seconds
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 )
46 > Time elapsed - +4.091000E-003 seconds
47 SQLBindParameter( )
48 < SQL_SUCCESS Time elapsed - +6.780000E-004 seconds
49 SQLExecute( hStmt=1:2 )
50 > Time elapsed - +1.337000E-003 seconds
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 )
55 > Time elapsed - +1.512000E-003 seconds
56 SQLError( pszSqlState="22001", pfNativeError=-302, pszErrorMsg="[IBM][CLI
Driver][DB2/LINUX] SQL0302N El valor de una variable del lenguaje
330 Programacin de aplicaciones cliente
principal de la sentencia EXECUTE u OPEN es demasiado alto para su
uso correspondiente.
SQLSTATE=22001", pcbErrorMsg=157 )
57 < SQL_SUCCESS Time elapsed - +8.060000E-004 seconds
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( )
< SQL_SUCCESS Time elapsed - +1.734130E-001 seconds
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 )
59 > Time elapsed - +6.085000E-003 seconds
60 ( ROLLBACK=0 )
61 SQLTransact( )
< SQL_SUCCESS Time elapsed - +2.220750E-001 seconds
62 SQLDisconnect( hDbc=0:1 )
63 > Time elapsed - +1.511000E-003 seconds
64 SQLDisconnect( )
Captulo 10. Programacin en Java 331
65 < SQL_SUCCESS Time elapsed - +1.531340E-001 seconds
66 SQLFreeConnect( hDbc=0:1 )
67 > Time elapsed - +2.389000E-003 seconds
68 SQLFreeConnect( )
69 < SQL_SUCCESS Time elapsed - +3.140000E-004 seconds
70 SQLFreeEnv( hEnv=0:1 )
71 > Time elapsed - +1.129000E-003 seconds
72 SQLFreeEnv( )
73 < SQL_SUCCESS Time elapsed - +2.870000E-004 seconds
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
332 Programacin de aplicaciones cliente
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]
Captulo 10. Programacin en Java 333
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.
Conceptos relacionados:
v Recurso de rastreo de CLI/ODBC/JDBC en la pgina 313
Consulta relacionada:
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
Guide and Reference, Volume 1
334 Programacin de aplicaciones cliente
v TRACEFILENAME CLI/ODBC Configuration Keyword en el manual CLI
Guide and Reference, Volume 1
v TRACEPATHNAME CLI/ODBC Configuration Keyword en el manual
CLI Guide and Reference, Volume 1
v TRACEPIDLIST CLI/ODBC Configuration Keyword en el manual CLI
Guide and Reference, Volume 1
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
Captulo 10. Programacin en Java 335
}
System.err.println(e.getMessage()) ; // Imprimir la excepcin
System.exit(1); // Salir
}
336 Programacin de aplicaciones cliente
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
Acceso a datos de DB2 mediante
consultas basadas en XML . . . . . . 342
Acceso a datos de DB2 mediante
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
Enterprise Edition. . . . . . . . . 346
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
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
Copyright IBM Corp. 1993-2002 337
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.
338 Programacin de aplicaciones cliente
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.
340 Programacin de aplicaciones cliente
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.
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 341
Conceptos relacionados:
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.
342 Programacin de aplicaciones cliente
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
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 343
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
Conceptos relacionados:
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
344 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
v Contenedores de Java 2 Platform Enterprise Edition en la pgina 345
v Enterprise Java Beans en la pgina 348
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
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 345
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
Conceptos relacionados:
v Java Naming and Directory Interface (JNDI) en la pgina 346
v Enterprise Java Beans en la pgina 348
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.
Conceptos relacionados:
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
346 Programacin de aplicaciones cliente
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.
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 347
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
348 Programacin de aplicaciones cliente
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());
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 349
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.
Consulta relacionada:
v Programas de ejemplo de Java WebSphere en el manual Gua de desarrollo
de aplicaciones: Creacin y ejecucin de aplicaciones
350 Programacin de aplicaciones cliente
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.
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 351
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.
Conceptos relacionados:
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
Consulta relacionada:
v Programas de ejemplo de Java WebSphere en el manual Gua de desarrollo
de aplicaciones: Creacin y ejecucin de aplicaciones
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.
352 Programacin de aplicaciones cliente
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
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 353
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
354 Programacin de aplicaciones cliente
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
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 355
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
356 Programacin de aplicaciones cliente
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
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 357
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
358 Programacin de aplicaciones cliente
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.
Captulo 11. Aplicaciones Java que utilizan WebSphere Application Servers 359
360 Programacin de aplicaciones cliente
Parte 4. Otras interfaces de programacin
Copyright IBM Corp. 1993-2002 361
362 Programacin de aplicaciones cliente
Captulo 12. Programacin en Perl
Consideraciones sobre la programacin en
Perl . . . . . . . . . . . . . . 363
Restricciones de Perl . . . . . . . . . 363
Acceso a bases de datos de varias hebras en
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.
Copyright IBM Corp. 1993-2002 363
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.
364 Programacin de aplicaciones cliente
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";
}
Conceptos relacionados:
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";
366 Programacin de aplicaciones cliente
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
368 Programacin de aplicaciones cliente
Captulo 13. Programacin en REXX
Consideraciones sobre la programacin en
REXX . . . . . . . . . . . . . . 369
Restricciones del lenguaje en REXX . . . . 370
Restricciones del lenguaje en REXX . . . 370
Registro de SQLEXEC, SQLDBS y
SQLDB2 en REXX. . . . . . . . . 370
Acceso a bases de datos de varias hebras
en REXX. . . . . . . . . . . . 372
Consideraciones sobre EUC en japons o
chino tradicional para REXX . . . . . 372
SQL incorporado en aplicaciones REXX . . 372
Variables del lenguaje principal en REXX 374
Variables del lenguaje principal en REXX 374
Nombres de variables del lenguaje
principal en REXX . . . . . . . . 375
Referencias a variables del lenguaje
principal en REXX . . . . . . . . 375
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
Consideraciones sobre la programacin en REXX
En las secciones siguientes se explican las consideraciones especiales sobre la
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.
Copyright IBM Corp. 1993-2002 369
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.
Conceptos relacionados:
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.
Tareas relacionadas:
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.
370 Programacin de aplicaciones cliente
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:
372 Programacin de aplicaciones cliente
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.
Se aplican las normas siguientes a las sentencias de SQL incorporado:
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:
Captulo 13. Programacin en REXX 373
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
Las secciones siguientes describen cmo declarar y utilizar variables del
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.
Conceptos relacionados:
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
374 Programacin de aplicaciones cliente
Consulta relacionada:
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
v Tipos de datos SQL soportados en REXX en la pgina 381
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.
Captulo 13. Programacin en REXX 375
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.
376 Programacin de aplicaciones cliente
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
REXX de la agrupacin de variables de REXX.
12 La variable SQLCA.SQLERRML de REXX se ha truncado
durante la captacin. La longitud mxima para esta variable
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
REXX de la agrupacin de variables de REXX.
15 La variable SQLCA.SQLERRMC de REXX se ha truncado
durante la captacin. La longitud mxima para esta variable
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
REXX de la agrupacin de variables de REXX.
18 La variable SQLCA.SQLSTATE de REXX se ha truncado
durante la captacin. La longitud mxima para esta variable
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
Captulo 13. Programacin en REXX 377
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).
Consulta relacionada:
v SQLCA en el manual Administrative API Reference
v SQLCHAR en el manual Administrative API Reference
v SQLDA 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
A continuacin se muestra la sintaxis para declarar variables del lenguaje
principal de localizador de LOB en REXX:
378 Programacin de aplicaciones cliente
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.
A continuacin se muestra la sintaxis para declarar variables del lenguaje
principal de referencia de archivos LOB en REXX:
Declaraciones de referencia de archivos en REXX


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

Captulo 13. Programacin en REXX 379


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
380 Programacin de aplicaciones cliente
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;
Consulta relacionada:
v Tipos de datos SQL soportados en REXX en la pgina 381
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.
Nota: no existe soporte de variables del lenguaje principal para el tipo de
datos DATALINK en ninguno de los lenguajes principales 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
Entero con signo de 16 bits
INTEGER
(496 497)
Un nmero sin coma decimal que va
de -2 147 483 648 a 2 147 483 647
Entero con signo de 32 bits
Captulo 13. Programacin en REXX 381
Tabla 18. Tipos de columna de SQL correlacionados con declaraciones de REXX (continuacin)
Tipo de columna SQL
1
Tipo de datos de REXX Descripcin del tipo de columna
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
Serie de caracteres de longitud fija
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)
Equivalente a CHAR(n) Serie de caracteres de longitud
variable con longitud n, donde n va
de 1 a 32 700
CLOB(n)
(408 409)
Equivalente a CHAR(n) Serie de caracteres de longitud
variable y de objeto grande con
longitud n, donde n va de 1 a
2 147 483 647
Variable de localizador CLOB
4
(964 965)
DECLARE :nombre_var LANGUAGE
TYPE CLOB LOCATOR
Identifica las entidades CLOB que
residen en el servidor
Variable de referencia de archivo
CLOB
4
(920 921)
DECLARE :nombre_var LANGUAGE
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
Variable de localizador BLOB
4
(960 961)
DECLARE :nombre_var LANGUAGE
TYPE BLOB LOCATOR
Identifica las entidades BLOB del
servidor
Variable de referencia de archivo
BLOB
4
(916 917)
DECLARE :nombre_var LANGUAGE
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.
382 Programacin de aplicaciones cliente
Tabla 18. Tipos de columna de SQL correlacionados con declaraciones de REXX (continuacin)
Tipo de columna SQL
1
Tipo de datos de REXX Descripcin del tipo de columna
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
longitud n, donde n va de 1 a 127
VARGRAPHIC(n)
(464 465)
Equivalente a GRAPHIC(n) Serie grfica de longitud variable con
longitud n, donde n va de 1 a 2000
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
Variable de localizador DBCLOB
4
(968 969)
DECLARE :nombre_var LANGUAGE
TYPE DBCLOB LOCATOR
Identifica las entidades DBCLOB que
residen en el servidor
Variable de referencia de archivos
DBCLOB
4
(924 925)
DECLARE :nombre_var LANGUAGE
TYPE DBCLOB FILE
Descriptor de archivo que contiene
datos 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.
2. 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).
3. Los tipos SQL siguientes son sinnimos de DOUBLE:
v FLOAT
v FLOAT(n) donde 24 < n < 54 es
v DOUBLE PRECISION
4. ste no es un tipo de columna, sino un tipo de variable del lenguaje principal.
Conceptos relacionados:
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.
Captulo 13. Programacin en REXX 383
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
384 Programacin de aplicaciones cliente
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
Captulo 13. Programacin en REXX 385
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)
386 Programacin de aplicaciones cliente
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.)
Conceptos relacionados:
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
Captulo 13. Programacin en REXX 387
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
388 Programacin de aplicaciones cliente
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.
Conceptos relacionados:
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
Consulta relacionada:
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.
Consulta relacionada:
v Tipos de datos SQL soportados en REXX en la pgina 381
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
Captulo 13. Programacin en REXX 389
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 */
.
.
.
390 Programacin de aplicaciones cliente
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
Conversin de datos para establecer datos
de tipos OLE DB en tipos DB2 . . . . 398
Conversin de datos para establecer datos
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
Soporte de IBM OLE DB Provider de
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
Cursores desplazables actualizables en
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,
Copyright IBM Corp. 1993-2002 391
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.
Consulta relacionada:
v Soporte de IBM OLE DB Provider de interfaces y componentes de OLE
DB en la pgina 403
392 Programacin de aplicaciones cliente
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 %.
394 Programacin de aplicaciones cliente
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
Captulo 14. Cmo escribir aplicaciones mediante IBM OLE DB Provider para servidores DB2 395
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.
396 Programacin de aplicaciones cliente
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
y DBCOLUMNFLAGS_ISLONG
o DBPARAMFLAGS_ISLONG
CLOB
GRAPHIC DBTYPE_WSTR DBTYPE_WCHAR GRAPHIC
VARGRAPHIC DBTYPE_WSTR DBTYPE_WVARCHAR VARGRAPHIC
LONG
VARGRAPHIC
DBTYPE_WSTR DBTYPE_WLONGVARCHAR LONG
VARGRAPHIC
DBCLOB DBTYPE_WSTR
y DBCOLUMNFLAGS_ISLONG
o DBPARAMFLAGS_ISLONG
DBTYPE_WCHAR
DBTYPE_WVARCHAR
DBTYPE_WLONGVARCHAR
y DBCOLUMNFLAGS_ISLONG
o DBPARAMFLAGS_ISLONG
DBCLOB
CHAR(n) FOR
BIT DATA
DBTYPE_BYTES DBTYPE_BINARY
VARCHAR(n)
FOR BIT
DATA
DBTYPE_BYTES DBTYPE_VARBINARY
LONG
VARCHAR