CONNECTION

java.sql.Connection Representa la conexión con la Base de Datos.

El encargado de abrir una conexión es el Driver Manager mediante el método estático: public static Connection getConnection(url, usr, pwr)trows java.sql.SQLException Donde: url: Identificador de la Base de Datos usr: Usuario con el que se abre la conexión (opcional) pwr: Contraseña del Usuario (opcional)

EJEMPLO DE URL Genérico ODBC:

“jdbc:odbc:Driver={Microsoft Access Driver

(*.mdb)};DBQ=" + String SitioBase;

Dónde: String SitioBase: el directorio donde se encuentra la Base de Datos

SQL

Structured Query Language.

Lenguaje Estándar de Interrogación de Bases de Datos.

java.sql.Connection

A través de la conexión nos comunicamos con la Base de Datos, enviándole sentencias SQL. Las sentencias SQL se envían a través de “Statements”.

Existen tres tipos de “Statements” y un método para generar cada tipo.

java.sql.Connection Una vez terminada una Conexión, se debe “Liberar”, que es cerrarla, de modo análogo a como se trabaja con flujos (Streams).

Las conexiones se cierran con el método:

public void close() trows java.sql.SQLException;

Statements

java.sql.Statement:

createStatement();

java.sql.PreparedStatement:

prepareStatement();

java.sql.Statement Se usa para ejecutar sentencias SQL. Lleva asociada una conexión que sirvió como origen para su creación Se crea con el método de la clase:

java.sql.Connection:

public Statement createStament() trows java.sql.SQLException;

java.sql.Statement

Las sentencias se cierran con el método:

public void close() trows java.sql.SQLException;

El método para ejecutarla depende del tipo de sentencia SQL que contenga.

java.sql.Statement Sentencias SELECT:

Se usa el método: executeQuery(String sql).

Devuelve una instancia de java.sql.ResultSet.

Sentencias INSERT, UPDATE, DELETE: se usa el método: executeUpdate(String sql). Devuelve un int con el número de filas afectadas java.sql.ResultSet Representa el resultado de la ejecución de una sentencia SQL. Lleva asociadas las filas y columnas que cumplían con la sentencia SQL. Implementa métodos para: -Acceder a las filas que componen el resultado. -Acceder al valor de cada columna de la fila seleccionada.

java.sql.ResultSet. Los ResultSet se cierran mediante el método:

public boolean close() trows java.sql.SQLException;

El ResultSet se cierra automáticamente al cerrar el Statement que la creó. No obstante no está demás cerrarlo.

Vista Preliminar

Un objeto Connection representa una conexión con una base de datos. Una sesión de conexión incluye las sentencias SQL que se ejecutan y los resultados que son devueltos después de la conexión. Una única aplicación puede tener una o más conexiones con una única base de datos, o puede tener varias conexiones con varias bases de datos diferentes.

Apertura de una conexión

La forma estándar de establecer una conexión a la base de datos es mediante la llamada al método DriverManager.getConnection. Este método toma una cadena que contiene una URL. La clase DriverManager, referida como la capa de gestión JDBC, intenta localizar un driver que pueda conectar con la base de datos representada por la URL. La clase DriverManager mantiene una lista de clases Driver registradas y cuando se llama al método getConnection, se chequea con cada driver de la lista hasta que encuentra uno que pueda conectar con la base de datos especificada en la URL. El método connect de Driver usa esta URL para establecer la conexión.

Un usuario puede evitar la capa de gestión de JDBC y llamar a los métodos de

Driver directamente. Esto puede ser útil en el caso raro que dos drivers puedan conectar con la base de datos y el usuario quiera seleccionar uno explícitamente.

Normalmente, de cualquier modo, es mucho más fácil dejar que la clase

DriverManager maneje la apertura de la conexión.

El siguiente código muestra como ejemplo una conexión a la base de datos

Localizada en la URL “jdbc:odbc:wombat” con un user ID de “oboy” y password

“12java”.

String url = "jdbc:odbc:wombat";

Connection con = DriverManager.getConnection(url, "oboy", "12Java");

Uso general de URL’s

Dado que URL’s causan a menudo cierta confusión, daremos primero una breveexplicación de URL en general y luego entraremos en una discusión sobre URL’s de

JDBC.

Una URL (Uniform Resource Locator) da información para localizar un recurso en

Internet. Puede pensarse en ella como una dirección.

La primera parte de una URL especifica el protocolo usado para acceder a la información y va siempre seguida por dos puntos. Algunos protocolos comunes son ftp, que especifica “file transfer protocol” y http que especifica “hypertext transfer protocol”. Si el protocolo es “file” indica que el recurso está en un sistema de ficheros local mejor que en Internet : veamos unos ejemplos:

ftp://javasoft.com/docs/JDK-1_apidocs.zip

http://java.sun.com/products/jdk/CurrentRelease

file:/home/haroldw/docs/books/tutorial/summary.html

El resto de la URL, todo después de los dos puntos, da información sobre donde se encuentra la fuente de los datos. Si el protocolo es file, el resto de la URL es el path al fichero. Para los protocolos ftp y http, el resto de la URL identifica el host y puede opcionalmente dar un path más específico al sitio. Por ejemplo, el siguiente es la URL para la home page de JavaSoft. Esta URL identifica solo al host:

JDBC y URL’s

Una URL JDBC suministra una forma de identificar una base de datos para que el driver apropiado pueda reconocerla y establecer la conexión con ella. Los

Desarrolladores de drivers son los que determinan actualmente que JDBC URL

Identifica su driver particular. Los usuarios no tienen por qué preocuparse sobre

Como se forma una URL JDBC; ellos simplemente usan la URL suministrada con el driver que usan. El rol de JDBC es recomendar algunas convenciones a los fabricantes de drivers para su uso.

Dado que los JDBC URL se usan con varios tipos de drivers, las convenciones son necesariamente muy flexibles. Primero, permiten a diferentes drivers usar diferentes esquemas para nombrar las bases de datos. EL subprotocolo odbc, por ejemplo, permite que las URL contengan valores de atributos (pero no los requieren).

Segundo, las URL’s JDBC permiten a los desarrolladores de drivers codificar toda la información de la conexión dentro de ella. Esto hace posible, por ejemplo, para un applet que quiera hablar con una base de datos dada el abrir la conexión sin necesitar que el usuario realice ninguna tarea de administración de sistemas.

Tercero, las URL’s JDBC permiten un nivel de indirección. Esto quiere decir que la URL JDBC puede referirse a una base de datos lógica o un host lógico que se traduce dinámicamente al nombre actual por el sistema de nombramiento de la red.

Esto permite a los administradores de sistemas evitar dar especificaciones de sus hosts como parte del nombre JDBC. Hay una variedad de servicios de nomenclatura de red diferentes (tales como DNS, NIS y DCE), y no hay restricción acerca de cuál usar.

La sintaxis para las URL’s JDBC que se muestra a continuación tiene tres partes separadas por dos puntos:

jdbc:<subprotocol>:<subname>

Las tres partes se descomponen como sigue:

1 jdbc – el protocolo. El protocolo en una URL JDBC es siempre jdbc

2 - <subprotocol> - el nombre del driver o el nombre del mecanismo de

conectividad con la base de datos, que puede estar soportado por uno o más

drivers. Un ejemplo sobresaliente de un subprotocolo es “odbc”, que ha sido

reservado para URL’s que especifican nombres de fuentes de datos estilo

ODBC. Por ejemplo para acceder a la base de datos a través del puente

JDBC-ODBC, la URL a usar podría ser algo así como lo siguiente:

jdbc:odbc:fred

En este ejemplo, el subprotocolo es “odbc” y el subnombre “fred” es el

nombre de la fuente de datos ODBC local.

Si se quiere usar un servicio de nombre de la red (ya que el nombre de la

base de datos en la URL JDBC no tiene por que ser su nombre actúal), el

servicio de nombre puede ser el subprotocolo. Por tanto, para el ejemplo,

podría tener una URL como :

jdbc:dcenaming:accounts-payable

En este ejemplo, la URL especifica que el servicio local DCE resolverá el

nombre de la base de datos “accounts-payable” para poder conectar con la

base de datos real.

<subname> - una forma de identificar la base de datos. El subnombre puede

variar dependiendo del subprotocolo, y puede tener un subnombre con

cualquier sintaxis interna que el fabricante del driver haya escogido. El punto

de un subnombre es para dar información suficiente para localizar la base de

datos. En el ejemplo anterior “fred” es suficiente porque ODBC suministra la

información restante. Una base de datos en un servidor remoto requiere más

información. Si la base de datos va a ser accesible a través de Internet, por

ejemplo, la dirección de red debería incluirse en la URL JDBC como parte del subnombre y debería seguir a la convención estándar de nomenclatura de URL.

//hostname:port/subsubname

Suponiendo que “dbnet” es un protocolo para conectar a un host, la URL JDBC

debería parecerse a algo como:

jdbc:dbnet://wombat:356/fred

El subprotocolo “odbc”

El subprotocolo “odbc” es un caso especial. Ha sido reservado para URL’s que

especifican el estilo ODBC de nombres de fuentes de datos y que tiene la

característica de permitir especificar cualquier número de valores de atributos

después del subnombre (el nombre de la fuente de datos) La sintaxis completa para el protocolo “odbc” es:

jdbc:odbc:<data-source-name>[;<attribute-name>=<attribute-value>]*

Todos los siguientes son nombres válidos jdbc:odbc

jdbc:odbc:qeor7

jdbc:odbc:wombat

jdbc:odbc:wombat;CacheSize=20;ExtensionCase=LOWER

jdbc:odbc:qeora;UID=kgh;PWD=fooey

Registro de subprotocolos

Un desarrollador de drivers puede reservar un nombre para usar como el

subprotocolo en una URL JDBC. Cuando la clase DriverManager presenta este nombre a su lista de drivers registrados, el driver para el que este nombre está reservado debería reconocerlo y establecer una conexión a la base de datos que lo identifica. Por ejemplo odbc está reservado para el puente JDBC-ODBC. Si fuera, por poner otro ejemplo, Miracle Corporation, y quisiera registrar “miracle” como el subprotocolo para el driver JDBC que conecte a su DBMS Miracle no tiene que usar sino ese nombre.

Envío de Sentencias SQL

Una vez que la conexión se haya establecido, se usa para pasar sentencias SQL a la base de datos subyacente. JDBC no pone ninguna restricción sobre los tipos de sentencias que pueden enviarse: esto da un alto grado de flexibilidad, permitiendo el uso de sentencias específicas de la base de datos o incluso sentencias no SQL. Se requiere de cualquier modo, que el usuario sea responsable de asegurarse que la base de datos subyacente sea capaz de procesar las sentencias SQL que le están siendo enviadas y soportar las consecuencias si no es así. Por ejemplo, una aplicación que intenta enviar una llamada a un procedimiento almacenado a una DBMS que no soporta procedimientos almacenados no tendrá éxito y generará unaexcepción. JDBC requiere que un driver cumpla al menos ANSI SQL-2 Entry Level para ser designado JDBC COMPLIANT. Esto significa que los usuarios pueden contar al menos con este nivel de funcionalidad.

JDBC suministra tres clases para el envío de sentencias SQL y tres métodos en la interfaz Connection para crear instancias de estas tres clases. Estas clases y métodos son los siguientes:

1.- Statement – creada por el método createStatement. Un objeto

Statement se usa para enviar sentencias SQL simples.

2.- PreparedStatement – creada por el método prepareStatement- Un objeto

PreparedStatement se usa para sentencias SQL que toman uno o más

parámetros como argumentos de entrada (parámetros IN). PreparedStatement tiene un grupo de métodos que fijan los valores de los parámetros IN, los cuales son enviados a la base de datos cuando se procesa la sentencia SQL. Instancias de PreparedStatement extienden Statement y por tanto heredan los métodos de Statement. Un objeto PreparedStatement es potencialmente más eficiente que un objeto Statement porque este ha sido precompilado y almacenado para su uso futuro.

3.- CallableStatement – creado por el método prepareCall.

Los objetos CallableStatement se usan para ejecutar procedimientos almacenados SQL –un grupo de sentencias SQL que son llamados mediante un nombre, algo parecido a una función - . Un objeto CallableStatement hereda métodos para el manejo de los parámetros IN de PreparedStatement, y añade métodos para el manejo de los parámetros OUT e INOUT.

La lista siguiente da una forma rápida de determinar que método Connection es el apropiado para crear los diferentes tipos de sentencias SQL.

El método createStatement se usa para:

• Sentencias SQL simples (sin parámetros).

El método prepareStatement se usa para:

• Sentencias SQL con uno ó más parámetros IN.

• Sentencias SQL simples que se ejecutan frecuentemente.

El método prepareCall se usa para:

• Llamar a procedimientos almacenados.

Transacciones

Una transacción consiste en una o más sentencias que han sido ejecutadas,

completas y, o bien se ha hecho commit o bien roll-back. Cuando se llama al

método commit o rollback , la transacción actúal finaliza y comienza otra.

Una conexión nueva se abre por defecto en modo auto-commit, y esto significa que cuando se completa se llama automáticamente al método commit. En este caso, cada sentencia es ‘commitada’ individualmente, por tanto una transacción se compone de una única sentencia. Si el modo auto-commit es desactivado, la

transacción no terminará hasta que se llame al método commit o al método

rollback explícitamente, por lo tanto incluirá todas las sentencias que han sido ejecutadas desde la última invocación a uno de los métodos commit o rollback. En este segundo caso, todas las sentencias de la transacción son “commitadas’ o deshechas en grupo.

El método commit hace permanente cualquier cambio que una sentencia SQL

realiza en la base de datos, y libera cualquier bloqueo mantenido por la transacción.El método rollback descarta estos cambios.

A veces un usuario no quiere que tenga efecto un determinado cambio a menos que se efectué otro. Esto puede hacerse desactivando el modo auto-commit y agrupando ambas actualizaciones en una transacción. Si ambas actualizaciones tienen éxito se llama al método commit haciendo estos cambios permanentes, si uno o los dos fallan, se llama al método rollback, restaurando los valores existentes l inicio de la transacción. Muchos drivers JDBC soportan transacciones. De hecho, un driver JDBC-compliant debe soportar transacciones. DatabaseMetaData suministra información que describe el nivel de transacción soportado por el DBMS.

Niveles de aislamiento de transacciones

Si un DBMS soporta el proceso de transacciones, tendrá que manejar de alguna forma los potenciales conflictos que puedan surgir cuando dos transacciones están operando sobre una base de datos concurrentemente. El usuario puede especificar un nivel de aislamiento para indicar que nivel de precaución debería ejercitar el DBMS para la resolución de estos conflictos. Por ejemplo, ¿que ocurrirá cuando una transacción cambia un valor y una segunda transacción lee el valor antes de que el cambio haya sido ‘commitado’ o descartado?. ¿Debería permitirse, dado que el valor cambiado leído por la segunda transacción será invalido si la primera transacción ha hecho rollback?. Un usuario JDBC puede instruir a la DBMS para que un valor que ha sido leído antes del ‘commit’ (“dirty reads”) con el siguiente código donde con es el objeto de la actual conexión:

con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);

El nivel de aislamiento más alto, el que más cuidado toma para evitar conflictos. La interfase Connection define cinco niveles de aislamiento con el nivel más bajo que especifica que no soporte transacciones hasta el más alto que especifica que mientras una transacción esté abierta ninguna otra transacción puede realizar cambios en los datos leídos por esa transacción. Normalmente, el nivel de transacción más alto es el más lento en la ejecución de la aplicación.(debido a que se incrementan los bloqueos y se disminuye la concurrencia de los usuarios). El desarrollador debe balancear la necesidad de rendimiento con la necesidad de la consistencia de los datos al tomar la decisión del nivel de aislamiento a usar. Por supuesto, el nivel de aislamiento que pueda soportarse depende de las posibilidades de la base de datos subyacente.

Cuando se crea un nuevo objeto Connection, su nivel de aislamiento depende del driver, pero normalmente por defecto es el de la DBMS subyacente. Un usuario puede llamar al método setIsolationLevel para cambiar el nivel de aislamiento de la transacción, y este nuevo nivel estará efectivo durante la sesión de conexión.

Para cambiar el nivel de aislamiento solo para una transacción, es necesario fijar este antes de la transacción comience y volverlo a situar en su valor anterior una vez que la transacción haya terminado. No se recomienda cambiar el nivel de aislamiento de transacción en medio de una puesto que lanzará una llamada inmediata al método commit, provocando que los cambios hasta ese punto se hagan permanentes en la base de datos.

Clase Java DriverManager

DriverManager es una clase estática de Java™ 2 Plaform, Standard Edition (J2SE) y Java SE Development Kit (JDK). DriverManager gestiona el conjunto de controladores Java Database Connectivity (JDBC) que están disponibles para que los utilice una aplicación.

Las aplicaciones pueden utilizar varios controladores JDBC simultáneamente si es necesario. Cada aplicación especifica un controlador JDBC mediante la utilización de un URL (Localizador universal de recursos). Pasando un URL de un controlador JDBC específico a DriverManager, la aplicación informa a DriverManager acerca del tipo de conexión JDBC que debe devolverse a la aplicación.

Para poder realizar esta operación, DriverManager debe estar al corriente del los controladores JDBC disponibles para que pueda distribuir las conexiones. Efectuando una llamada al método Class.forName, carga una clase en la máquina virtual Java (JVM) que se está ejecutando en función del nombre de serie que se pasa en el método. A continuación figura un ejemplo del método class.forName utilizado para cargar el controlador JDBC nativo:

Ejemplo: cargar el controlador JDBC nativo

// Cargar el controlador JDBC nativo en DriverManager para hacerlo

// disponible para peticiones getConnection.

Class.forName("com.ibm.db2.jdbc.app.DB2Driver");

Los controladores JDBC están diseñados para informar a DriverManager acerca de sí mismos automáticamente cuando se carga su clase de implementación de controlador. Una vez que se ha procesado la línea de código mencionada anteriormente, el controlador JDBC nativo está disponible para la DriverManager con la que debe trabajar. La línea de código siguiente solicita un objeto Connection que utiliza el URL de JDBC nativo:

Ejemplo: solicitar un objeto Connection

// Obtener una conexión que utiliza el controlador JDBC nativo.

Connection c = DriverManager.getConnection("jdbc:db2:*local");

La forma más sencilla de URL JDBC es una lista de tres valores separados mediante dos puntos. El primer valor de la lista representa el protocolo, que es siempre jdbc para los URL JDBC. El segundo valor es el subprotocolo y se utiliza db2 o db2iSeries para especificar el controlador JDBC nativo. El tercer valor es el nombre de sistema para establecer la conexión con un sistema específico. Existen dos valores especiales que pueden utilizarse para conectarse con la base de datos local. Son *LOCAL y localhost (ambos son sensibles a mayúsculas y minúsculas). También puede suministrarse un nombre de sistema específico, de la forma siguiente:

Connection c =

    DriverManager.getConnection("jdbc:db2:rchasmop");

Así se crea una conexión con el sistema rchasmop. Si el sistema al que intenta conectarse es un sistema remoto (por ejemplo, a través de Distributed Relational Database architecture), debe utilizarse el nombre de sistema del directorio de bases de datos relacionales.

Nota: Si no se especifica lo contrario, el ID de usuario y la contraseña utilizados actualmente para iniciar la sesión también se utilizan para establecer la conexión con la base de datos.

Nota: El controlador IBM® DB2 JDBC Universal también utiliza el subprotocolo db2. Para asegurarse de que el controlador JDBC nativo puede manejar el URL, las aplicaciones deben utilizar el URL jdbc:db2iSeries:xxxx en lugar del URL jdbc:db2:xxxx. Si la aplicación no desea que el controlador nativo acepte URLS con el subprotocolo db2, la aplicación deberá cargar la clase com.ibm.db2.jdbc.app.DB2iSeriesDriver, en lugar de com.ibm.db2.jdbc.app.DB2Driver. Al cargarse esta clase, el controlador nativo ya no tiene que manejar los URL que contienen el subprotocolo db2.

Propiedades

El método DriverManager.getConnection toma un URL de una sola serie indicado anteriormente, y solo es uno de los métodos de DriverManager destinado a obtener un objeto Connection. También existe otra versión del método DriverManager.getConnection que toma un ID de usuario y una contraseña. A continuación figura un ejemplo de esta versión:

Ejemplo: método DriverManager.getConnection que toma un ID de usuario y una contraseña

// Obtener una conexión que utiliza el controlador JDBC nativo.

Connection c = DriverManager.getConnection("jdbc:db2:*local", "cujo", "newtiger");

La línea de código intenta conectarse con la base de datos local como usuario cujo con la contraseña newtiger sin importar quién ejecuta la aplicación. También existe una versión del método DriverManager.getConnection que toma un objeto java.util.Properties que permite una mayor personalización. A continuación se ofrece un ejemplo:

Ejemplo: método DriverManager.getConnection que toma un objeto java.util.Properties

// Obtener una conexión que utiliza el controlador JDBC nativo.

Properties prop = new java.util.Properties();

prop.put("user", "cujo");

prop.put("password","newtiger");

Connection c = DriverManager.getConnection("jdbc:db2:*local", prop);

El código es funcionalmente equivalente a la versión mencionada anteriormente que ha pasado el ID de usuario y la contraseña como parámetros.

Consulte las Propiedades de Connection para obtener una lista completa de las propiedades de conexión del controlador JDBC nativo.

Propiedades de URL

Otra forma de especificar propiedades es colocarlas en una lista del propio objeto URL. Cada propiedad de la lista está separada mediante un signo de punto y coma, y la lista debe tener el formato nombre propiedad=valor propiedad. Solo existe un método abreviado que no cambia significativamente la forma en que se realiza el proceso, como muestra el ejemplo siguiente:

Ejemplo: especificar propiedades de URL

// Obtener una conexión que utiliza el controlador JDBC nativo.

Connection c = DriverManager.getConnection("jdbc:db2:*local;user=cujo;password=newtiger");

De nuevo, el código es funcionalmente equivalente a los ejemplos mencionados anteriormente.

Si se especifica un valor de propiedad tanto en un objeto de propiedades como en el objeto URL, la versión de URL tiene preferencia sobre la versión del objeto de propiedades. A continuación se ofrece un ejemplo:

Ejemplo: propiedades de URL

// Obtener una conexión que utiliza el controlador JDBC nativo.

Properties prop = new java.util.Properties();

prop.put("user", "someone");

prop.put("password","something");

Connection c = DriverManager.getConnection("jdbc:db2:*local;user=cujo;password=newtiger",

prop);

El ejemplo utiliza el ID de usuario y la contraseña de la serie de URL en lugar de la versión del objeto Properties. Termina siendo funcionalmente equivalente al código mencionado anteriormente.

Registro del controlador JDBC

Antes de utilizar JDBC para acceder a los datos de un archivo de base de datos del servidor, es necesario registrar el controlador JDBC de IBM® Toolbox para Java™ con DriverManager.

El controlador se puede registrar ya sea utilizando una propiedad de sistema Java o haciendo que el programa Java registre el controlador:

· Registrar mediante una propiedad del sistema

Cada máquina virtual tiene su propio método para establecer las propiedades del sistema. Por ejemplo, el mandato Java de JDK utiliza la opción -D para establecer las propiedades del sistema. Para establecer el controlador mediante las propiedades del sistema, especifique:

            "-Djdbc.drivers=com.ibm.as400.access.AS400JDBCDriver"

· Registrar mediante el programa Java

Para cargar el controlador JDBC de IBM Toolbox para Java, antes de la primera llamada a JDBC, añada al programa Java la línea siguiente:

      Class.forName("com.ibm.as400.access.AS400JDBCDriver");

El controlador JDBC de IBM Toolbox para Java se registra cuando se carga, siendo este es el método preferido de registrar el controlador. También puede registrar explícitamente el controlador JDBC de IBM Toolbox para Java con lo siguiente:

      java.sql.DriverManager.registerDriver (new com.ibm.as400.access.AS400JDBCDriver ());

Si invoca DriverManager.registerDriver(), el controlador JDBC de IBM Toolbox para Java se registra dos veces. Una vez cuando la JVM carga AS400JDBCDriver y otra en la llamada explícita al método registerDriver(). Esto se debe a la implementación de DriverManager, sobre la que IBM Toolbox para Java no tiene control. Tener un controlador que aparece dos veces en la lista del registro de DriverManager normalmente no supone ningún problema. Aunque puede haber casos en los que se utilicen los dos controladores registrados. Por ejemplo, cuando se intenta obtener una conexión con una contraseña incorrecta. DriverManager no podrá obtener una conexión con el primer controlador registrado y, por lo tanto, lo intentará con el segundo controlador registrado.

El controlador JDBC de IBM Toolbox para Java no requiere un objeto AS400 como parámetro de entrada, como lo requieren las demás clases de IBM Toolbox para Java que obtienen datos de un servidor. Sin embargo, internamente sí que se utiliza un objeto AS400 para gestionar el usuario predeterminado y la colocación de contraseñas en memoria caché. Cuando se establece una conexión con el servidor por primera vez, puede solicitarse al usuario que escriba el ID de usuario y la contraseña. El usuario puede optar por guardar el ID de usuario como ID de usuario predeterminado y añadir la contraseña a la memoria caché de contraseñas. Al igual que en las demás funciones de IBM Toolbox para Java, si es el programa Java el que proporciona el ID de usuario y la contraseña, el usuario predeterminado no se establece y la contraseña no se pone en la memoria caché. En Gestionar conexiones en programas Java encontrará información acerca de cómo se gestionan las conexiones.

Propiedades JDBC de IBM Toolbox para Java

Pueden especificarse muchas propiedades al conectar con una base de datos de servidor utilizando JDBC. Todas las propiedades son opcionales y pueden especificarse como parte del URL o en un objeto java.util.Properties. Si se establece una propiedad tanto en el URL como en un objeto Properties, se empleará el valor del URL.

Nota: la lista siguiente no incluye las propiedades de origen de datos.

Las tablas siguientes muestran las distintas propiedades de conexión que este controlador reconoce. Algunas de estas propiedades afectan al rendimiento y otras son atributos de trabajo servidor. Las tablas organizan las propiedades en las categorías siguientes:

· Propiedades generales

· Propiedades de servidor

· Propiedades de formato

· Propiedades de rendimiento

· Propiedades de ordenación

· Otras propiedades

Propiedades generales

Las propiedades generales son atributos del sistema que especifican el usuario, la contraseña y si se necesita una solicitud para conectarse al servidor.

Propiedad	Descripción	Obligatoria	Opciones	Valor predet
"password"	Especifica la contraseña para conectarse al servidor. Si no se especifica ninguna, se le solicitará al usuario, salvo que se haya establecido la propiedad "prompt" en "false", en cuyo caso el intento de conexión fallará.	no	contraseña del sistema	(se solicitará al usuario)
"prompt"	Especifica si debe presentarse al usuario una solicitud en el caso de que sea necesario un nombre de usuario o una contraseña para conectarse al servidor. Si no puede establecerse una conexión sin solicitar al usuario y esta propiedad se establece en "false", el intento de conexión fallará.	no	· "true" · "false"	"true"
"user"	Especifica el nombre de usuario para conectarse al servidor. Si no se especifica ninguno, se le solicitará al usuario, salvo que se haya establecido la propiedad "prompt" en "false", en cuyo caso el intento de conexión fallará.	no	usuario del servidor	(se solicitará al usuario)

Propiedades de servidor

Las propiedades de servidor especifican atributos que rigen las transacciones, las bibliotecas y las bases de datos.

Propiedad	Descripción	Obligatoria	Opciones	Valor predet
"auto commit"	Especifica si la modalidad de compromiso automático es la modalidad de conexión predeterminada para las nuevas conexiones. Si invoca AS400JDBCConnection.setAutoCommit(), alterará temporalmente esta propiedad para cada conexión. Nota: para poder utilizar niveles de aislamiento de transacción distintos a *NONE cuando se utiliza la modalidad de compromiso automático, la propiedad "true autocommit" debe establecerse en true.	no	· "true" · "false"	"true"
"concurrent access resolution"	Especifica si se utiliza el acceso "currently committed" en la conexión. Un valor 1 indica que se utilizará "currently committed". Un valor 2 indica que se utilizará "wait for outcome". Un valor 3 indica que se utilizará "skip locks".	no	· "1" · "2" · "3"	(valor predeterminado del sistema)
"cursor hold"	Especifica si se debe retener el cursor entre transacciones. Si esta propiedad se establece en "true", los cursores no se cierran cuando se compromete o retrotrae una transacción. Todos los recursos obtenidos durante la unidad de trabajo se retienen, pero los bloqueos sobre filas y objetos específicos obtenidos implícitamente durante la unidad de trabajo se liberan.	no	· "true" · "false"	"true"
"cursor sensitivity"	Especifica la sensibilidad de cursor que se solicita desde la base de datos. El comportamiento depende del resultSetType: · ResultSet.TYPE_FORWARD_ONLY o ResultSet.TYPE_SCROLL_SENSITIVE indican que el valor de esta propiedad controla la sensibilidad de cursor que el programa Java™ solicita desde la base de datos. · ResultSet.TYPE_SCROLL_INSENSITIVE hace que se ignore esta propiedad.	no	· "asensitive" · "sensitive" · "insensitive"	"asensitive"
"database name"	Especifica la base de datos que debe utilizarse para la conexión con una agrupación de almacenamiento auxiliar (ASP) independiente. Esta propiedad solo es válida cuando se conecta con un servidor IBM® i. Cuando especifique un nombre de base de datos, el nombre debe existir en el directorio de bases de datos relacionales del servidor y debe corresponder a una ASP independiente o a la base de datos predeterminada del sistema. Los criterios siguientes determinan a qué base de datos se accede: · Cuando se utiliza esta propiedad para especificar una base de datos correspondiente a una ASP independiente, la conexión se realiza con la ASP independiente. Si la base de datos no existe, la conexión falla. · Cuando se utiliza esta propiedad para especificar *SYSBAS como nombre de base de datos, se utiliza la base de datos predeterminada del sistema. · Cuando se omite esta propiedad, se utiliza el grupo de ASP inicial especificado en la descripción de trabajo del perfil de usuario. Cuando la descripción de trabajo no especifica un grupo de ASP inicial, se utiliza la base de datos predeterminada del sistema.	no	Nombre de base de datos "*SYSBAS"	Se utiliza el nombre de base de datos especificado en la descripción de trabajo del perfil de usuario. Cuando la descripción de trabajo no especifica ningún nombre de base de datos, se utiliza la base de datos predeterminada del sistema.
"decfloat rounding mode"	Especifica la modalidad de redondeo que debe utilizarse al trabajar con el tipo de datos decfloat. Esta propiedad se ignora en las conexiones con sistemas que ejecutan IBM i 5.4 y anteriores.	no	· "half even" · "half up" · "down" · "ceiling" · "floor" · "half down" · "up"	"half even"
"libraries"	Especifica una o varias bibliotecas que desea añadir o sustituir por la lista de bibliotecas del trabajo servidor, y puede establecer el esquema SQL predet. (biblioteca predet.). Tenga en cuenta que las bibliotecas no pueden tener más de 10 caracteres. Debe utilizar la sentencia SET PATH SQL si tiene bibliotecas con más de 10 caracteres. Lista de bibliotecas El servidor utiliza las bibliotecas especificadas para resolver los nombres de procedimientos almacenados no calificados y los procedimientos almacenados las utilizan para resolver nombres no calificados. Para especificar varias bibliotecas, utilice comas o espacios para separar las distintas entradas. Puede utilizar LIBL para indicar la lista de bibliotecas actual del trabajo del servidor. · Cuando la primera entrada es LIBL, las bibliotecas especificadas se añaden a la lista de bib. actual del trabajo servidor. · Si no indica LIBL, las bibliotecas especificadas sustituyen a la lista de bibliotecas actual del trabajo del servidor. Para obtener más información sobre las propiedades de lista de bibliotecas, consulte la propiedad LibraryList de JDBC. Esquema SQL predeterminado* El servidor utiliza el esquema SQL predet. para resolver los nombres no calificados en sentencias SQL. Por ejemplo, en la sentencia "SELECT * FROM MITABLA", el servidor solo buscará MITABLA en el esquema SQL predet. Puede especificar el esquema SQL predet. En el URL de conexión. Si no especifica el esquema SQL predet. en el URL de conexión, son aplicables las siguientes condiciones, dependiendo del convenio de denominación SQL que se utilice. · Al utilizar Denominaciones SQL: · La primera entrada (si no es LIBL) pasa a ser esquema SQL predeterminado · Si la primera entrada es LIBL, la segunda pasa a esquema SQL predet. · Si no establece esta propiedad o si solo contiene LIBL, el perfil usuario pasa a esquema SQL predet. · Al utilizar Denominaciones del sistema: · No se establece ningún esquema SQL predet. y el servidor utiliza las bibliotecas especificadas para la búsqueda de los nombres no calificados · Si no establece esta propiedad o si solamente contiene LIBL, el servidor utiliza la lista de bibliotecas actual del trabajo del servidor para buscar en ellas los nombres no calificados	no	Lista de bibliotecas del servidor, separadas por comas o espacios	"*LIBL"
"maximum precision"	Especifica la precisión decimal máxima que puede emplear la base de datos.	no	· "31" · "63"	"31"
"maximum scale"	Especifica la escala máxima que puede emplear la base de datos.	no	"0"-"63"	"31"
"minimum divide scale"	Especifica el valor de escala mínimo para el resultado de la división decimal.	no	· "0" · "1" · "2" · "3" · "4" · "5" · "6" · "7" · "8" · "9"	"0"
"package ccsid"	Especifica la codificación de caracteres que se utilizará para el paquete SQL y las sentencias que se envíen al servidor.	no	· "1200" (UCS-2) · "13488" (UTF-16)	"13488"
"transaction isolation"	Especifica el aislamiento de transacción predeterminado.	no	"none" "read uncommitted" "read committed" "repeatable read" "serializable"	"read uncommitted"
"translate hex"	Especifica cómo se interpretan los literales hexadecimales.	no	· "character" (Interpretar literales hexadecimales como datos de tipo carácter) · "binary" (Interpretar literales hexadecimal decimales como datos binarios)	"character"
"true autocommit"	Especifica si la conexión debe utilizar el soporte de compromiso automático verdadero. El compromiso automático verdadero significa que el compromiso automático está activo y ejecutándose en un nivel de aislamiento distinto de NONE. De forma predeterminada, el controlador maneja el compromiso automático ejecutando en el nivel de aislamiento NONE.	no	· "true" (Utilizar compromiso automático verdadero.) · "false" (No utilizar compromiso automático verdadero.)	"false"
"xa loosely coupled support"	Especifica si está permitido el compartimiento de bloqueo para ramas de transacción no muy emparejadas. Nota: este valor se ignora al ejecutarse en IBM i 5.3 o anteriores.	no	· "0" = No pueden compartirse bloqueos · "1" = Pueden compartirse bloqueos	"0"

Propiedades de formato

Las propiedades de formato especifican los formatos de fecha y hora, los separadores de fecha y decimales y los convenios de denominación de tablas empleados en las sentencias SQL.

Propiedad	Descripción	Obligatoria	Opciones	Valor predet
"date format"	Especifica el formato de fecha utilizado en los literales de fecha dentro de las sentencias SQL.	no	· "mdy" · "dmy" · "ymd" · "usa" · "iso" · "eur" · "jis" · "julian"	(trabajo servidor)
"date separator"	Especifica el separador de fecha utilizado en los literales de fecha dentro de las sentencias SQL. Esta propiedad no surte ningún efecto salvo que la propiedad "date format" se haya establecido en "julian", "mdy", "dmy" o "ymd".	no	· "/" (barra inclinada) · "-" (guión) · "." (punto) · "," (coma) · "b" (espacio)	(trabajo servidor)
"decimal separator"	Especifica el separador decimal utilizado en los literales numéricos dentro de las sentencias SQL.	no	· "." (punto) · "," (coma)	(trabajo servidor)
"naming"	Especifica el convenio de denominación utilizado al hacer referencia a las tablas.	no	"sql" (como en esquema`.`tabla) "system" (como enesquema`/`tabla)	"sql"
"time format"	Especifica el formato de hora utilizado en los literales de hora dentro de las sentencias SQL.	no	· "hms" · "usa" · "iso" · "eur" · "jis"	(trabajo servidor)
"time separator"	Especifica el separador de hora utilizado en los literales de hora dentro de las sentencias SQL. Esta propiedad no surte ningún efecto salvo que la propiedad "time format" se haya establecido en "hms".	no	· ":" (dos puntos) · "." (punto) · "," (coma) · "b" (espacio)	(trabajo servidor)

Propiedades de rendimiento

Las propiedades de rendimiento son atributos que incluyen el almacenamiento en memoria caché, la conversión de datos, la compresión de datos y la prebúsqueda que afectan al rendimiento.

Propiedad	Descripción	Obligatoria	Opciones	Valor predet
"big decimal"	Especifica si se utiliza un objeto java.math.BigDecimal intermedio para conversiones de decimal empaquetado y con zona. Si esta propiedad se establece en "true", se utiliza un objeto java.math.BigDecimal intermedio para conversiones de decimal empaquetado y con zona tal como describe la especificación de JDBC. Si esta propiedad se establece en "false", no se utiliza ningún objeto intermedio para conversiones de decimal empaquetado y con zona. En su lugar, estos valores se convierten directamente desde y a valores dobles Java. Estas conversiones serán más rápidas pero puede que no sigan todas las reglas de conversión y truncamiento de datos documentadas en la especificación de JDBC.	no	· "true" · "false"	"true"
"block criteria"	Especifica los criterios para recuperar datos del servidor en bloques de registros. Si se especifica un valor distinto de cero para esta propiedad se reducirá la frecuencia de comunicación con el servidor, lo que mejorará el rendimiento. Compruebe que la función de bloques de registros esté desactivada si se va a utilizar el cursor para posteriores operaciones de actualización (UPDATE); de lo contrario, la fila que se actualice no será necesariamente la fila actual.	no	· "0" (sin bloques de registros) · "1" (con bloques si se especifica FOR FETCH ONLY) · "2" (con bloques salvo que se especifique FOR UPDATE)	"2"
"block size"	Especifica el tamaño de bloque (en kilobytes) que debe recuperarse del servidor y colocarse en la memoria caché del cliente. Esta propiedad no surte ningún efecto salvo que la propiedad "block criteria" se haya establecido en un valor distinto de cero. Si se especifican grandes tamaños de bloque se reducirá la frecuencia de comunicación con el servidor, lo que mejorará el rendimiento.	no	· "0" · "8" · "16" · "32" · "64" · "128" · "256" · "512"	"32"
"data compression"	Especifica si los datos del conjunto de resultados se comprimen. Si esta propiedad se establece en "true", los datos del conjunto de resultados se comprimen. Si esta propiedad se establece en "false", los datos del conjunto de resultados no se comprimen. La compresión de datos puede mejorar el rendimiento al recuperar conjuntos de resultados de gran tamaño.	no	· "true" · "false"	"true"
"extended dynamic"	Especifica si debe utilizarse soporte dinámico ampliado. El soporte dinámico ampliado proporciona un mecanismo para poner en memoria caché en el servidor las sentencias SQL dinámicas. La primera vez que se prepara una sentencia SQL concreta, se almacena en un paquete SQL en el servidor. Si el paquete no existe, se crea automáticamente. En posteriores preparaciones de la misma sentencia SQL, el servidor puede saltarse una parte notable del proceso utilizando la información almacenada en el paquete SQL. Si esta propiedad se establece en "true", debe establecerse un nombre de paquete con la propiedad "package".	no	· "true" · "false"	"false"
"lazy close"	Especifica si hay que diferir el cierre de los cursores hasta las peticiones ulteriores. Esto mejorará el rendimiento global al reducir el número total de peticiones.	no	· "true" · "false"	"false"
"lob threshold"	Especifica el tamaño máximo de LOB (objeto de gran tamaño) en bytes que puede recuperarse como parte de un conjunto de resultados. Los LOB cuyo tamaño sobrepase este umbral se recuperarán en fragmentos, utilizando una comunicación adicional con el servidor. Los umbrales de LOB de mayor tamaño reducirán la frecuencia de la comunicación con el servidor, pero bajarán más datos de LOB, aunque dichos datos no se utilicen. Los umbrales de LOB de menor tamaño pueden incrementar la frecuencia de la comunicación con el servidor, pero únicamente bajarán los datos de LOB según se necesiten.	no	"0" - "16777216"	"32768"
"package"	Especifica el nombre base del paquete SQL. Observe que solo se utilizan los seis primeros caracteres para generar el nombre del paquete SQL en el servidor. Esta propiedad no surte ningún efecto salvo que la propiedad "extended dynamic" se haya establecido en "true".Además, esta propiedad debe establecerse si se ha establecido la propiedad "extended dynamic" en "true".	no	Paquete SQL	""
"package add"	Especifica si deben añadirse las nuevas sentencias preparadas al paquete SQL especificado en la propiedad "package". Esta propiedad no surte ningún efecto salvo que la propiedad "extended dynamic" se haya establecido en "true".	no	· "true" · "false"	"true"
"package cache"	Específica si debe almacenarse en memoria caché un subconjunto de la información del paquete SQL en la memoria del cliente. Al almacenar paquetes SQL en la memoria caché local, se reduce la cantidad de comunicación con el servidor para las preparaciones y descripciones. Esta propiedad no surte ningún efecto salvo que la propiedad "extended dynamic" se haya establecido en "true".	no	· "true" · "false"	"false"
"package criteria"	Especifica el tipo de sentencias SQL que deben almacenarse en el paquete SQL. Esto puede resultar de utilidad para mejorar el rendimiento de las condiciones de unión complejas. Esta propiedad no surte ningún efecto salvo que la propiedad "extended dynamic" se haya establecido en "true".	no	· "default" (almacenar únicamente las sentencias SQL con marcadores de parámetros en el paquete) · "select" (almacenar todas las sentencias SQL SELECT en el paquete)	"default"
"package error"	Especifica la acción que debe efectuarse cuando se producen errores de paquete SQL. Cuando se produce un error de paquete SQL, el controlador puede lanzar una SQLException o enviar un aviso al objeto Connection, según el valor de esta propiedad. Esta propiedad no surte ningún efecto salvo que la propiedad "extended dynamic" se haya establecido en "true".	no	· "exception" · "warning" · "none"	"warning"
"package library"	Especifica la biblioteca para el paquete SQL. Esta propiedad no surte ningún efecto salvo que la propiedad "extended dynamic" se haya establecido en "true".	no	Biblioteca para el paquete SQL	"QGPL"
"prefetch"	Especifica si deben prebuscarse datos al ejecutar una sentencia SELECT. Esto mejorará el rendimiento al acceder a las filas iniciales del conjunto de resultados (ResultSet).	no	· "true" · "false"	"true"
"qaqqinilib"	Especifica un nombre de biblioteca QAQQINI. Permite especificar la biblioteca que contiene el archivo qaqqini que se utilizará. Un archivo qaqqini contiene todos los atributos que pueden afectar al rendimiento del motor de base de datos DB2 para i.	no	Nombre de biblioteca QAQQINI	(valor predeterminado del servidor)
"query optimize goal"	Especifica el objetivo que el servidor deberá utilizar con la optimización de consultas. Este valor corresponde a la opción QAQQINI del servidor denominada OPTIMIZATION_GOAL. Nota: esta propiedad se ignora en las conexiones con sistemas que se ejecutan en IBM i 5.3 y anteriores.	no	· "0" = Optimizar la consulta para el primer bloque de datos (FIRSTIO) cuando se utilizan paquetes dinámicos ampliados; Optimizar la consulta para todo el conjunto de resultados (ALLIO) cuando no se utilizan paquetes · "1" = Optimizar la consulta para el primer bloque de datos (FIRSTIO) · "2" = Optimizar la consulta para todo el conjunto de resultados (ALLIO)	"0"
"query storage limit"	Limita el almacenamiento utilizado por una consulta. Esta propiedad compara el límite de almacenamiento especificado con la estimación de utilización de almacenamiento de la consulta. Si la estimación de utilización de almacenamiento sobrepasa el límite de almacenamiento especificado, la consulta no puede ejecutarse.	no	-1 (*NOMAX) hasta 2 147 352 578	-1, que indica el valor especial *NOMAX
"query timeout mechanism"	Especifica el mecanismo para implementar la característica queryTimeout.	no	· "qqrytimlmt" = La característica queryTimeout utiliza la característica "QQRYTIMLMT" del motor de base de datos. · "cancel" = La característica queryTimeout utiliza una solicitud CANCEL para cancelar una sentencia SQL en ejecución una vez sobrepasado el tiempo de espera.	"qqrytimlmt"
"receive buffer size"	Especifica el tamaño del almacenamiento intermedio utilizado para recibir datos a través de la conexión de socket entre el controlador frontal y el sistema. Nota: no especifica el tamaño real del almacenamiento intermedio de recepción. Sólo se utiliza como orientación para el código de socket subyacente.	no	"1" - tamaño máximo	(dependiente de la plataforma)
"send buffer size"	Especifica el tamaño del almacenamiento intermedio utilizado para enviar datos a través de la conexión de socket entre el controlador frontal y el sistema. Nota: no especifica el tamaño real del almacenamiento intermedio de envío. Sólo se utiliza como orientación para el código de socket subyacente.	no	"1" - tamaño máximo	(dependiente de la plataforma)
"variable field compression"	Especifica si los campos de longitud variable deben comprimirse.	no	· "true" · "false"	"true"

Propiedades de ordenación

Las propiedades de ordenación especifican cómo lleva a cabo el servidor las operaciones de almacenar y ordenar.

Propiedad de ordenación	Descripción	Obligatoria	Opciones	Valor predet
"sort"	Especifica cómo ordena el servidor los registros antes de enviarlos al cliente.	no	· "hex" (basar el orden en valores hexadeci-males) · "language" (basar el orden en el idioma establecido en la propiedad "sort language") · "table" (basar el orden en la tabla de secuencia de ordenación establecida en la propiedad "sort table")	"hex"
"sort language"	Especifica un ID de idioma de tres caracteres que debe utilizarse para la selección de una secuencia de ordenación. Esta propiedad no surte ningún efecto salvo que la propiedad "sort" se haya establecido en "language".	no	ID de idioma	ENU
"sort table"	Especifica la biblioteca y el nombre de archivo de una tabla de secuencia de ordenación almacenada en el servidor. Esta propiedad no surte ningún efecto salvo que la propiedad "sort" se haya establecido en "table".	no	Nombre calificado de tabla de ordenación	""
"sort weight"	Especifica cómo trata el servidor las mayúsculas/minúsculas al ordenar registros. Esta propiedad no surte ningún efecto salvo que la propiedad "sort" se haya establecido en "language".	no	· "shared" (los caracteres en mayúsculas y en minúsculas se ordenan como el mismo carácter) · "unique" (los caracteres en mayúsculas y en minúsculas se ordenan como caracteres distintos)	"shared"

Otras propiedades

Otras propiedades son las que no pueden incluirse fácilmente en categorías. Estas propiedades determinan qué controlador JDBC se utiliza y especifican opciones relacionadas con el nivel de acceso a la base de datos, el tipo de serie bidireccional, el truncamiento de datos, etc.

Otra propiedad	Descripción	Obligatoria	Opciones	Valor predet
"access"	Especifica el nivel de acceso a base de datos para la conexión.	no	· "all" (permitidas todas las sentencias SQL) · "read call" (permitidas sentencias SELECT y CALL) · "read only" (sólo sentencias SELECT)	"all"
"autocommit exception"	Especifica si debe lanzarse una excepción de tipo SQLException cuando se llama a Connection.commit() o Connection.rollback(), si el compromiso automático está habilitado.	no	· "true" · "false"	"false"
"bidi string type"	Especifica el tipo de serie de salida de los datos bidireccionales. En BidiStringTypeencontrará más información.	no	· "" (utilizar el CCSID para determinar el tipo de serie bidireccional) · "0" (el tipo de serie predeterminado para datos no bidireccionales (LTR)) · "4" · "5" · "6" · "7" · "8" · "9" · "10" · "11"	""
"bidi implicit reordering"	Especifica si debe utilizarse la reordenación LTR-RTL bidi implícita.	no	· "true" · "false"	"true"
"bidi numeric ordering"	Especifica si debe utilizarse la característica circular de ordenación numérica.	no	· "true" · "false"	"false"
"data truncation"	Especifica si el truncamiento de datos de tipo carácter genera avisos y excepciones. Cuando esta propiedad es "true", se aplican las reglas siguientes: · Al escribir datos de tipo carácter truncados en la base de datos se lanza una excepción. · Al utilizar datos de tipo carácter truncados en una consulta se envía un aviso. Cuando esta propiedad es "false", al escribir datos truncados en la base de datos o utilizar esos datos en una consulta no se generan ni excepciones ni avisos. El valor predeterminado es "true". Esta propiedad no afecta a los datos numéricos. Al escribir datos numéricos truncados en la base de datos siempre se lanza un error y al utilizar datos numéricos truncados en una consulta siempre se envía un aviso.	no	· "true" · "false"	"true"
"driver"	Especifica la implementación del controlador JDBC. El controlador JDBC de IBM Toolbox para Java puede utilizar distintas implementaciones del controlador JDBC en función del entorno. Si el entorno es una JVM de IBM i situada en el mismo servidor que la base de datos a la que se conecta el programa, puede utilizarse el controlador JDBC de IBM Developer Kit para Java nativo. En cualquier otro entorno, se utiliza el controlador JDBC de IBM Toolbox para Java. Esta propiedad no surte ningún efecto si se ha establecido la propiedad "secondary URL".	no	· "toolbox" (utilizar sólo el controlador JDBC de IBM Toolbox para Java) · "native" (se utilizará el controlador JDBC de IBM Developer Kit para Java si se ejecuta en el servidor; de lo contrario, se utilizará el controlador JDBC de IBM Toolbox para Java).	"toolbox"
"errors"	Especifica la cantidad de detalle que debe devolverse en el mensaje para los errores que se producen en el servidor.	no	· "basic" · "full"	"basic"
"extended metadata"	Especifica si el controlador solicita metadatos ampliados procedentes del servidor. Al establecer esta propiedad en true se aumenta la precisión de la información devuelta por los siguientes métodos de ResultSetMetaData: · getColumnLabel(int) · isReadOnly(int) · isSearchable(int) · isWriteable(int) Asimismo, al establecer esta propiedad en true se habilita el soporte para los métodos ResultSetMetaData.getSchemaName(int) y ResultSetMetaData.isAutoIncrement(int). Nota: al establecer esta propiedad en true el rendimiento puede empeorar ya que es preciso recuperar más información del servidor. Deje la propiedad establecida en el valor predeterminado (false) salvo que necesite información más específica de los métodos listados. Por ejemplo, cuando esta propiedad está inactiva (false), ResultSetMetaData.isSearchable(int) siempre devuelve "true" ya que el controlador no tiene suficiente información procedente del servidor para hacer un juicio. Al activar esta propiedad (true), se fuerza al controlador a obtener los datos correctos del servidor.	no	· "true" · "false"	"false"
"full open"	Especifica si el servidor abre por completo un archivo para cada consulta. De forma predeterminada, el servidor optimiza las peticiones abiertas. Esta optimización mejora el rendimiento pero puede fallar si hay un supervisor de base de datos activo cuando se ejecuta una consulta más de una vez. Establezca la propiedad en true únicamente si se emiten consultas idénticas cuando hay supervisores activos.	no	· "true" · "false"	"false"
"hold input locators"	Especifica si los ubicadores de entrada deben asignarse como ubicadores de tipo hold o no hold. Si los ubicadores son de tipo hold, no se liberarán cuando se realice un compromiso.	no	· "true" (type hold) · "false"	"true"
"hold statements"	Especifica si las sentencias deben permanecer abiertas hasta un límite de transacción cuando cuando el compromiso automático esté desactivado y estén asociadas a un ubicador LOB. De forma predeterminada, todos los recursos asociados a una sentencia se liberan cuando se cierra la sentencia. Establezca esta propiedad en true solo cuando sea necesario acceder a un ubicador LOB después de cerrar una sentencia.	no	· "true" · "false"	"false"
"ignore warnings"	Especifica una lista de estados SQL para los que el controlador no debe crear objetos de aviso. De forma predeterminada, el controlador JDBC de IBM Toolbox para Java creará internamente un objeto java.sql.SQLWarning para cada aviso devuelto por la base de datos. Por ejemplo, se crea un aviso con SQLSTATE 0100C cada vez que se devuelve un conjunto de resultados de un procedimiento almacenado. Este aviso puede ignorarse de forma segura para mejorar el rendimiento de las aplicaciones que llaman a procedimientos almacenados.	no	Una lista separada por comas de los estados SQL que deben omitirse.	""
"keep alive"	Especifica si debe comprobarse periódicamente el estado operativo de la conexión de socket.	no	· "true" · "false"	(dependiente de la plataforma)
"key ring name"	Especifica el nombre de la clase de archivo de claves utilizada para las conexiones SSL con el servidor. Esta propiedad no surte ningún efecto salvo que "secure" se haya establecido en "true" y que se haya establecido una contraseña de archivo de claves mediante la propiedad "key ring password".	no	"key ring name"	""
"key ring password"	Especifica la contraseña para la clase de archivo de claves utilizada para las comunicaciones SSL con el servidor. Esta propiedad no surte ningún efecto salvo que "secure" se haya establecido en "true" y que se haya establecido un nombre de archivo de claves mediante la propiedad "key ring name".	no	"key ring password"	""
"metadata source"	Especifica cómo se recupera DatabaseMetaData. Si se establece en "0," los metadatos de base de datos se recuperarán mediante el flujo de datos de ROI (Recuperar información de objeto). Si se establece en "1," los metadatos de base de datos se recuperarán llamando a procedimientos almacenados del sistema.	no	· "0" (acceso ROI) · "1" (procedimientos almacenados SQL)	"0" para IBM i 6.1 y releases anteriores, "1" para los demás releases
"proxy server"	Especifica el nombre de host y el número de puerto de la máquina de número medio de niveles en la que se está ejecutando el servidor proxy. El formato esnombre_sistema_principal[:puerto], siendo el puerto opcional. Si no se establece esta propiedad, el nombre de host y el número de puerto se recuperan de la propiedad com.ibm.as400.access.AS400.proxyServer. El puerto predeterminado es3470 (si la conexión utiliza SSL, el puerto predeterminado es 3471). El servidor proxy debe estar en ejecución en la máquina de número medio de niveles. El nombre de la máquina de número medio de niveles se omite en un entorno de dos niveles.	no	Nombre de host y número de puerto de servidor proxy	(el valor de la propiedad proxyServer, o none si no está establecida)
"remarks"	Especifica el origen del texto para las columnas REMARKS de los objetos ResultSet devueltos por los métodos de DatabaseMetaData. Esta propiedad solo se utiliza si la propiedad "metadata source" se establece en "0".	no	· "sql" (comentario de objeto SQL) · "system" (descripción de objeto IBM i)	"system"
"secondary URL"	Especifica el URL que se utilizará para una conexión en el objeto DriverManager de número medio de niveles en un entorno de varios niveles, si es distinto del que ya se ha especificado. Esta propiedad permite utilizar este controlador para conectarse con otras bases de datos. Emplee una barra inclinada invertida como carácter de escape antes de los caracteres de barra inclinada invertida y punto y coma en el URL.	no	URL JDBC	(URL JDBC actual)
"secure"	Especifica si para comunicarse con el servidor se utiliza una conexión SSL (capa de sockets segura).	no	· "true" (cifrar todas las comunicaciones cliente/servidor) · "false" (cifrar solamente la contraseña)	"false"
"server trace"	Especifica el nivel de rastreo del trabajo servidor JDBC. Cuando el rastreo está habilitado, el rastreo empieza al conectarse el cliente al servidor y finaliza al desconectarse la conexión. Debe iniciar el rastreo antes de conectarse al servidor, ya que el cliente habilita el rastreo del servidor únicamente en el momento de la conexión.	no	· "0" (el rastreo no está activo) · "2" (iniciar el supervisor de base de datos en el trabajo de servidor JDBC) · "4" (iniciar depuración en el trabajo de servidor JDBC) · "8" (guardar las anotaciones de trabajo cuando finalice el trabajo del servidor JDBC) · "16" (iniciar rastreo de trabajo en el trabajo de servidor JDBC) · "32" (guardar información de SQL) · "64" (soporta la activación del rastreo de servidor de host de base de datos) Pueden iniciarse varios rastreos agrupando estos valores. Por ejemplo, "6" inicia el supervisor de base de datos e inicia la depuración.	"0"
"thread used"	Especifica si se usan hebras en una comunicación con los servidores de host.	no	· "true" · "false"	"true"
"toolbox trace"	Especifica qué categoría de un rastreo de IBM Toolbox para Java debe anotarse. Los mensajes de rastreo son útiles para depurar programas que efectúan llamadas a JDBC. Sin embargo, la anotación de mensajes de rastreo trae aparejado un deterioro del rendimiento, por lo que esta propiedad únicamente se establece para llevar a cabo la depuración. Los mensajes de rastreo se anotan en System.out.	no	· "" · "none" · "datastream" (se anota el flujo de datos entre el host local y el sistema remoto) · "diagnostic" (se anota la información de estado de los objetos) · "error" (se anotan los errores que generan una excepción) · "information" (se utiliza para hacer un seguimiento del flujo de control a través del código) · "warning" (se anotan los errores recuperables) · "conversion" (se anotan las conversiones de juego de caracteres entre las páginas de códigos nativas y Unicode) · "proxy" (se anota el flujo de datos entre el cliente y el servidor proxy) · "pcml" (se utiliza para determinar cómo interpreta PCML los datos que se envían al servidor y que se reciben del mismo) · "jdbc" (se anota la información de JDBC) · "all" (se anotan todas las categorías) · "thread" (se anota la información de hebra)	""
"trace"	Especifica si se anotan los mensajes de rastreo. Los mensajes de rastreo son útiles para depurar programas que efectúan llamadas a JDBC. Sin embargo, la anotación de mensajes de rastreo trae aparejado un deterioro del rendimiento, por lo que esta propiedad únicamente se debe establecer en "true" para llevar a cabo la depuración. Los mensajes de rastreo se anotan en System.out.	no	· "true" · "false"	"false"
"translate binary"	Especifica si se convierten los datos binarios. Si esta propiedad se establece en "true", los campos BINARY y VARBINARY se tratan como campos CHAR y VARCHAR.	no	· "true" · "false"	"false"
"translate boolean"	Especifica cómo se interpretan los objetos booleanos (Boolean) al establecer el valor de un campo/parámetro de tipo carácter mediante los métodos PreparedStatement.setObject(), CallableStatement.setObject() o ResultSet.updateObject(). Si la propiedad se establece en "true", el objeto booleano se almacenará en el campo de tipo carácter como "true" o "false." Si la propiedad se establece en "false", el objeto booleano se almacenará en el campo de tipo carácter como "1" o "0."	no	· "true" · "false"	"true"

Propiedades de conexión del controlador JDBC

En esta tabla figuran las propiedades válidas de conexión para el controlador JDBC, los valores que tienen y sus descripciones.

Propiedad	Valores	Significado
access (acceso)	all, read call, read only	Este valor permite restringir el tipo de operaciones que se pueden realizar con una determinada conexión. El valor predeterminado es "all", que básicamente significa que la conexión tiene pleno acceso a la API de JDBC. El valor "read call" (llamada de lectura) solo permite que la conexión haga consultas y llame a procedimientos almacenados. Se impide todo intento de actualizar la base de datos con una sentencia SQL. El valor solo de lectura "read only" permite restringir una conexión para que solo pueda hacer consultas. Se impiden las llamadas a procedimientos almacenados y las sentencias de actualización.
auto commit (compromiso automático)	true, false	Este valor se utiliza para establecer el compromiso automático de la conexión. El valor predeterminado es true a menos que se haya establecido la propiedad de aislamiento de transacción con un valor distino a ninguno. En ese caso, el valor predeterminado es false.
batch style (estilo de lotes)	2.0, 2.1	La especificación JDBC 2.1 define un segundo método para manejar las excepciones de una actualización por lotes. El controlador puede ajustarse a cualquiera de ellos. El valor predeterminado es trabajar según lo definido en la especificación JDBC 2.0.
block size (tamaño de bloque)	0, 8, 16, 32, 64, 128, 256, 512	Este es el número de filas que se extraen de una sola vez para un conjunto de resultados. En un proceso habitual solo hacia adelante de un conjunto de resultados, se obtiene un bloque de este tamaño. Entonces no es necesario acceder a la base de datos ya que la aplicación procesa cada fila. La base de datos solo solicitará otro bloque de datos cuando se haya llegado al final del bloque. Este valor solo se utiliza si la propiedad de habilitado para bloques (blocking enabled) se establece como true. Establecer la propiedad de tamaño de bloque en 0 tiene el mismo efecto que establecer la propiedad de habilitado para bloques como false. El valor predeterminado es utilizar la agrupación en bloques con un tamaño de bloque de 32. Esta decisión es completamente arbitraria, por lo que el valor predeterminado podría cambiar en el futuros. La agrupación en bloques no se utiliza en los conjuntos de resultados desplazables.
blocking enabled (habilitado para bloques)	true, false	Este valor sirve para determinar si la conexión utiliza bloques en la recuperación de filas de conjunto de resultados. La agrupación en bloques puede aumentar notablemente el rendimiento al procesar conjuntos de resultados. Por omisión, esta propiedad está establecida en true.
commit hold (retención de compromiso)	false, true	Este valor especifica si se emplea "commit hold" al llamar al método connection.commit(). Cuando se utiliza "commit hold", los cursores y otros recursos de base de datos no se cierran ni se liberan al llamar a commit. El valor predeterminado es false.
resolución de acceso concurrente	1, 2, 3	Esta propiedad especifica si el acceso "currently committed" (actualmente comprometido) se utiliza en la conexión. Los valores posibles son: 1 Se utilizará "currently committed" (actualmente comprometido) 2 Se utilizará "wait for outcome" (esperar resultado) 3 Se utilizará "skip locks" (omitir bloqueos) El valor predeterminado es 2.
cursor hold (retención de cursor)	true, false	Este valor especifica si los conjuntos de resultados permanecen abiertos cuando se compromete una transacción. El valor true indica que una aplicación puede acceder a sus conjuntos de resultados abiertos una vez llamado el compromiso. El valor false indica que el compromiso cierra los cursores abiertos en la conexión. Por omisión, esta propiedad está establecida en true. Este valor de propiedad funciona como valor predeterminado para todos los conjuntos de resultados establecidos para la conexión. Con el soporte de retención de cursor añadido en JDBC 3.0, este valor predeterminado se sustituye simplemente si una aplicación especifica posteriormente una capacidad de retención diferente. Si se emigra de una versión anterior a la JDBC 3.0, hay que tener en cuenta que el soporte de retención del cursor se añade por primera vez en JDBC 3.0. En versiones anteriores, el valor predeterminado "true" se envia durante el tiempo de conexión pero la Máquina virtual Java todavía no lo reconoce. Por tanto, la propiedad de retención del cursor no impactará en la funcionalidad de la base de datos hasta JDBC 3.0.
cursor sensitivity (sensibilidad de cursor)	asensitive, sensitive	Especifica la sensibilidad empleada por los cursores de ResultSet.TYPE_SCROLL_SENSITIVE. Por defecto, el controlador JDBC nativo crea cursores no sensibles en el caso de los cursores ResultSet.TYPE_SCROLL_SENSITIVE.
data truncation (truncamiento de datos)	true, false	Este valor especifica si el truncamiento de datos de tipo carácter provoca avisos y excepciones (true) o si los datos deben truncarse de forma silenciosa (false). Si el valor predeterminado es true, debe aceptarse el truncamiento de datos en los campos de caracteres.
date format (formato de fecha)	juliano, mdy, dmy, ymd, usa, iso, eur, jis	Esta propiedad permite cambiar el formato de las fechas.
date separator (separador de fecha)	/(barra inclinada), -(guión), .(punto), ,(coma), blanco	Esta propiedad permite cambiar el separador de fecha. Solo es válida en combinación con algunos de los valores de dateFormat (según las normas del sistema).
decfloat rounding mode (modalidad de redondeo de flotante decimal)	round half even, round half up, round down, round ceiling, round floor, round half down, round up, round half even	Esta propiedad especifica la modalidad de redondeo que hay que utilizar en las operaciones de número decimales flotantes. El valor predeterminado es round half even.
decimal separator (separador de decimales)	.(punto), ,(coma)	Esta propiedad permite cambiar el separador de decimales.
direct map (correlación directa)	true, false	Esta propiedad especifica si se emplearán optimizaciones de correlación directa de base de datos al recuperar conjuntos de resultados de la base de datos. El valor predeterminado es true.
do escape processing (hacer proceso de escape)	true, false	Esta propiedad establece un distintivo que indica si las sentencias bajo la conexión deben hacer un proceso de escape. La utilización del proceso de escape es una manera de codificar las sentencias SQL para que sean genéricas y similares para todas las plataformas, pero luego la base de datos lee las cláusulas de escape y sustituye la debida versión específica del sistema para el usuario. Es una propiedad valiosa, salvo que implica hacer un trabajo adicional en el sistema. Si se sabe que solo se van a utilizar sentencias SQL que ya contienen sintaxis SQL válida de IBM® i, conviene establecer que este valor sea "false" para aumentar el rendimiento. El valor predeterminado de esta propiedad es "true", ya que debe estar en conformidad con la especificación JDBC (es decir, el proceso de escape está activo por omisión). Este valor se ha añadido debido a una deficiencia de la especificación JDBC. Solo se puede establecer que el proceso de escape está desactivado en la clase Statement. Eso funciona correctamente si se trata de sentencias simples. Basta con crear la sentencia, desactivar el proceso de escape y empezar a ejecutar las sentencias. Sin embargo, en el caso de las sentencias preparadas y de las sentencias invocables, este esquema no funciona. Se suministra la sentencia SQL en el momento de construir la sentencia preparada o la sentencia invocable y esta no cambia después de ello. Así que la sentencia queda preparada en primer lugar y el hecho de cambiar el proceso de escape más adelante no tiene ningún significado. Gracias a esta propiedad de conexión, existe un modo de soslayar la actividad general adicional.
errors (errores)	basic, full	Esta propiedad permite devolver el texto de errores de segundo nivel de todo el sistema en mensajes de objeto SQLException. El valor predeterminado es basic, que devuelve solo el texto de mensaje estándar.
extended metadata (metadatos ampliados)	true, false	Esta propiedad especifica si el controlador debe solicitar metadatos ampliados de la base de datos. Si esta propiedad es igual a true, aumenta la exactitud de la información que devuelven los siguientes métodos de ResultSetMetaData: · getColumnLabel(int) · getSchemaName(int) · getTableName(int) · isReadOnly(int) · isSearchable(int) · isWriteable(int) Cuando esta propiedad es true, el rendimiento puede disminuir, porque hay que recuperar más información de la base de datos.
ignore warnings (ignorar avisos)	Lista de estados SQL, separada por mandatos, que se deben ignorar.	Por defecto, el controlador JDBC nativo creará internamente un objeto java.sql.SQLWarning para cada aviso devuelto por la base de datos. Esta propiedad especifica una lista de los estados SQL para los que el controlador JDBC nativo no debe crear objetos de tipo aviso. Por ejemplo, se crea un aviso con el estado SQLSTATE 0100C cada vez que se devuelve un conjunto de resultados desde un procedimiento almacenado. Este aviso se puede ignorar sin problemas para mejorar el rendimiento de las aplicaciones que llaman a procedimientos almacenados.
libraries (bibliotecas)	Una lista de bibliotecas separadas mediante espacios. (Una lista de bibliotecas también puede separarse mediante signos de dos puntos o comas).	Esta propiedad permite colocar una lista de bibliotecas en la lista de bibliotecas del trabajo servidor o establecer una lista de bibliotecas específica. La propiedad de denominación, "naming", afecta al funcionamiento de esta propiedad. En el caso por omisión, en que "naming" está establecida en sql, JDBC funciona como ODBC. La lista de bibliotecas no tiene ningún efecto sobre el proceso que efectúa la conexión. Existe una biblioteca por omisión para todas las tablas no calificadas. Por omisión, la biblioteca tiene el mismo nombre que el perfil de usuario al que está conectado. Si se especifica la propiedad "libraries", la primera biblioteca de la lista pasa a ser la biblioteca por omisión. Si se especifica una biblioteca por omisión en el URL de conexión (como en jdbc:db2:*local/mibilioteca), se altera temporalmente cualquier valor de esta propiedad. Si "naming" se establece en "system", cada una de las bibliotecas especificadas para esta propiedad se añade a la parte del usuario de la lista de bibliotecas y se busca en la lista de bibliotecas para resolver las referencias de tabla no calificadas.
lob threshold (umbral de lob)	Cualquier valor por debajo de 500000	Esta propiedad indica al controlador que coloque los valores reales en el almacenamiento de conjunto de resultados en lugar de localizadores de columnas lob si la columna lob es inferior al tamaño del umbral. Esta propiedad actúa sobre el tamaño de columna, no sobre el tamaño de los datos lob propiamente. Por ejemplo, si la columna lob está definida para contener hasta 1 MB para cada lob, pero todos los valores de columna están por debajo de 500 MB, se siguen utilizando localizadores. Tenga en cuenta que el límite de tamaño se establece de forma que permita extraer los bloques de datos sin el riesgo de que los bloques de datos crezcan más allá de los 16 MB de máximo de tamaño de asignación. En conjuntos de resultados mayores, sigue siendo fácil sobrepasar este límite, lo cual provoca anomalías en las extracciones. Debe tener cuidado en la forma en que la propiedad block size y esta propiedad interactúan con el tamaño de un bloque de datos. El valor predeterminado es 0. Siempre se utilizan localizadores para datos lob.
maximum precision (precisión máxima)	31, 63	Este valor especifica la precisión máximo empleada para los datos de tipo decimal y numérico. El valor predeterminado es 31.
maximum scale (escala máxima)	0-63	Este valor especifica la escala máxima (número de posiciones decimales a la derecha de la coma decimal) que se devuelve para los datos de tipo decimal y numérico. El valor puede ir de 0 a la precisión máxima. El valor predeterminado es 31.
minimum divide scale (escala de división mínima)	0-9	Este valor especifica la escala de división mínima (número de posiciones decimales a la derecha de la coma decimal) que se devuelve para los tipos de datos intermedios y de resultados. El valor puede ir de 0 a 9, sin sobrepasar la escala máxima. Si se especifica 0, no se utiliza la escala de división mínima. El valor predeterminado es 0.
naming (denominación)	sql, system	Esta propiedad le permite utilizar la sintaxis de denominación tradicional de IBM i o la sintaxis de denominación estándar de SQL. La denominación del sistema significa que utilizará un carácter /(barra inclinada) para separar los valores de colección y de tabla, y la denominación SQL significa que utilizará un carácter .(punto) para separar los valores. El establecimiento de este valor tiene ramificaciones que afectan también a cuál es la biblioteca por omisión. Hallará más información al respecto en la propiedad libraries, más arriba. El valor predeterminado es utilizar la denominación SQL.
password (contraseña)	cualquier valor	Esta propiedad prevé la especificación de una contraseña para la conexión. Esta propiedad no funciona correctamente si no se especifica también la propiedad de usuario, "user". Estas propiedades permiten establecer conexiones con la base de datos en los casos en que el usuario no coincida con el que está ejecutando el trabajo de IBM i. Especificar las propiedades de usuario y contraseña tiene el mismo efecto que utilizar el método de conexión con la firma getConnection(String url, String userId, String password).
prefetch (captación previa)	true, false	Esta propiedad especifica si el controlador capta los primeros datos de un conjunto de resultados inmediatamente después del proceso o si espera hasta que se soliciten los datos. Si el valor predeterminado es true, hay que precaptar los datos. En las aplicaciones que utilizan el controlador JDBC nativo, esto rara vez representa un problema. La propiedad existe principalmente para uso interno con procedimientos almacenados Java™ y funciones definidas por usuario en las que es importante que el motor de bases de datos no extraiga ningún dato de los conjuntos de resultados en nombre del usuario antes de que este lo solicite.
qaqqinilib	library name (nombre de biblioteca)	Esta propiedad especifica la biblioteca que contiene el archivo qaqqini que hay que utilizar. En el archivo qaqqini están todos los atributos que pueden afectar potencialmente al rendimiento del motor de la base de datos DB2 para i.
query optimize goal (objetivo de optimización de consulta)	1, 2	Esta propiedad especifica el objetivo que debe tener el servidor con respecto a la optimización de las consultas. Este valor se corresponde con la opción, llamada OPTIMIZATION_GOAL, de QAQQINI del servidor. Los valores posibles son: 1 Optimizar la consulta para el primer bloque de datos (FIRSTIO) 2 Optimizar la consulta para todo el conjunto de resultados (ALLIO) El valor predeterminado es 2.
reuse objects (reutilizar objetos)	true, false	Esta propiedad especifica si el controlador intenta reutilizar algunos tipos de objetos después de que usted los haya cerrado. Esto representa una mejora en el rendimiento. El valor predeterminado es true.
subsistema modo de servidor	*SAME, nombre de subsistema	Esta propiedad especifica el subsistema donde se ejecutarán los trabajos QSQSRVR asociados. El comportamiento predeterminado es tener los trabajos ejecutándose en el subsistema QSYSWRK. Si se utiliza el valor SAME, los trabajos QSQSRVR se ejecutarán en el mismo subsistema que el trabajo que utiliza el controlador JDBC nativo. Para que un trabajo QSQSRVR se ejecute en otro subsistema, debe existir una entrada de trabajo de preinicio QSQSRVR. Pueden utilizarse los mandatos siguientes para crear una entrada de trabajo de preinicio QSQSRVR. ENDSBS sbs* ADDPJE SBSD(biblioteca/sbsd) PGM(QSYS/QSQSRVR) STRJOBS(YES) INLJOBS(x) THRESHOLD(y) ADLJOBS(z) MAXUSE(NOMAX) STRSBS sbs Donde sbs es el subsistema, biblioteca es la biblioteca donde se encuentra la descripción sbsd del subsistema, y x, y y z son valores numéricos para los parámetros correspondientes del mandato ADDPJE (Añadir entrada de trabajo de preinicio). Si no existe una entrada de trabajo de preinicio para QSQSRVR en el subsistema, el trabajo QSQSRVR utilizará un trabajo BCI (Lote inmediato) en lugar de un trabajo PJ (trabajo de preinicio). Este trabajo Lote inmediato suele ejecutarse en el mismo subsistema que el trabajo que utiliza el controlador JDBC nativo.
time format (formato de hora)	hms, usa, iso, eur, jis	Esta propiedad permite cambiar el formato de los valores de hora.
time separator (separador de hora)	:(dos puntos), .(punto), ,(coma), blanco	Esta propiedad permite cambiar el separador de hora. Solo es válida en combinación con algunos de los valores de timeFormat (según las normas del sistema).
trace (rastreo)	true, false	Esta propiedad prevé la activación del rastreo de la conexión. Se puede utilizar como una simple ayuda para la depuración. El valor predeterminado es "false", que corresponde a no utilizar el rastreo.
transaction isolation (aislamiento de transacciones)	none, read committed, read uncommitted, repeatable read, serializable	Esta propiedad permite al usuario establecer el nivel de aislamiento de transacción para la conexión. No hay ninguna diferencia entre establecer esta propiedad en un nivel concreto y especificar un nivel en el método setTransactionIsolation() de la interfaz Connection. El valor predeterminado de esta propiedad es "none", El valor predeterminado de esta propiedad es "none", ya que JDBC toma por omisión la modalidad de compromiso automático.
translate binary (convertir binario)	true, false	Esta propiedad puede utilizarse para obligar al controlador JDBC a que trate los valores de datos de tipo binary y varbinary como si fuesen valores de datos de tipo char y varchar. Cuando los datos binarios se tratan igual que los datos de caracteres, se utilizará el CCSID del trabajo como CCSID de los datos. El valor predeterminado de esta propiedad es "false", es decir, no tratar los datos de tipo binario como si fuesen datos de tipo carácter.
translate hex (convertir hexadecimal)	binario, carácter	Este valor se utiliza para seleccionar el tipo de datos utilizado por las constantes hex en expresiones SQL. El valor binario indica que las constantes hex utilizarán el tipo de datos BINARY. El valor carácter indica que las constantes hex utilizarán el tipo de datos CHARACTER FOR BIT DATA. El valor predeterminado es carácter.
use block insert (utilizar inserción en bloque)	true, false	Esta propiedad permite al controlador JDBC nativo colocarse en modalidad de inserción en bloque para insertar bloques de datos en la base de datos. Esta es una versión optimizada de la actualización por lotes. Esta modalidad optimizada solo puede utilizarse en aplicaciones que garanticen no transgredir determinadas restricciones del sistema ni producir anomalías de inserción de datos, pudiendo dañar los datos. Las aplicaciones que activen esta propiedad solo deben conectarse al sistema local al intentar realizar actualizaciones por lotes. No deben utilizar DRDA para establecer conexiones remotas, ya que la inserción en bloque no puede gestionarse a través de DRDA. Las aplicaciones también deben asegurarse de que PreparedStatements con una sentencia SQL insert y una cláusula values indican todos los parámetros de valores de inserción. No se permiten contantes en la lista de valores. Este es un requisito del motor de inserción por bloques del sistema. El valor predeterminado es false.
user (usuario)	cualquier valor	Esta propiedad permite especificar un ID de usuario para la conexión. Esta propiedad no funciona correctamente si no se especifica también la propiedad de contraseña, "password". Estas propiedades permiten establecer conexiones con la base de datos en los casos en que el usuario no coincida con el que está ejecutando el trabajo de IBM i. Especificar las propiedades de usuario y contraseña tiene el mismo efecto que utilizar el método de conexión con la firma getConnection(String url, String userId, String password).

Utilización del controlador JDBC para conectarse a una base de datos del servidor

El método DriverManager.getConnection() le permite conectarse a la base de datos del servidor. DriverManager.getConnection() toma como argumento una serie de URL (localizador uniforme de recursos). El gestor de controladores JDBC intenta localizar un controlador que pueda conectarse a la base de datos representada por el URL. Cuando utilice el controlador de IBM Toolbox para Java, utilice la siguiente sintaxis para el URL:

      "jdbc:as400://systemName/defaultSchema;listOfProperties"

Nota: en el URL se puede omitir systemName o defaultSchema.

Para utilizar los tickets de kerberos, establezca únicamente el nombre de sistema (y no la contraseña) en el objeto URL JDBC. La identidad del usuario se recupera mediante la infraestructura JGSS (Java Generic Security Services), por lo que tampoco necesita especificar un usuario en el URL JDBC. Solo puede establecer un método de autenticación en un objeto AS400JDBCConnection a la vez. Al establecer la contraseña se borran los tickets de kerberos o los símbolos de perfil. Para obtener más información, consulte Clase AS400.

Ejemplos: utilización del controlador JDBC para conectarse a un servidor

Ejemplo: utilizar un URL en el que no se especifica un nombre de sistema

Este ejemplo hace que se solicite al usuario que escriba el nombre del sistema al que desea conectarse.

    // Conéctese al sistema sin nombre.

    // Se solicita al usuario que escriba el nombre del sistema.

    Connection c = DriverManager.getConnection("jdbc:as400:");

Ejemplo: conectarse a la base de datos del servidor; no se especifica ningún esquema SQL predeterminado ni ninguna propiedad

    // Conéctese al sistema 'mySystem'. No

    // se especifica ningún esquema SQL predeterminado ni ninguna propiedad.

    Connection c  = DriverManager.getConnection("jdbc:as400://mySystem");

Ejemplo: conectarse a la base de datos del servidor; se especifica un esquema SQL predeterminado

    // Conéctese al sistema 'mySys2'. Se

    // Especifica el esquema SQL predeterminado 'myschema'.

    Connection c2 = DriverManager.getConnection("jdbc:as400://mySys2/mySchema");

Ejemplo: conectarse a la base de datos del servidor y utilizar java.util.Properties para especificar las propiedades

El programa Java puede especificar un conjunto de propiedades de JDBC ya sea utilizando la interfaz java.util.Properties o especificando dichas propiedades como parte del URL. En Propiedades JDBC de IBM Toolbox para Java encontrará una lista de las propiedades soportadas.

Por ejemplo, para especificar las propiedades mediante la interfaz Properties, podría utilizar el siguiente código:

     // Cree un objeto propiedades.

     Properties p = new Properties();

     // Establezca las propiedades para la conexión.

     p.put("naming", "sql");

     p.put("errors", "full");

     // Conéctese utilizando el objeto de propiedades.

     Connection c = DriverManager.getConnection("jdbc:as400://mySystem",p);

Ejemplo: conectarse a la base de datos del servidor y utilizar un URL (localizador uniforme de recursos) para especificar las propiedades

     // Conéctese utilizando las propiedades. Se

     // propiedades se establecen en el URL,

     // en lugar de mediante un objeto propiedades.

     Connection c = DriverManager.getConnection(

                        "jdbc:as400://mySystem;naming=sql;errors=full");

Ejemplo: conectarse a la base de datos del servidor y especificar el ID de usuario y la contraseña

     // Conéctese utilizando las propiedades

     // indicadas en el URL y especificando un ID de usuario y una contraseña

     Connection c = DriverManager.getConnection(

                        "jdbc:as400://mySystem;naming=sql;errors=full",

                        "auser",

                        "apassword");

RESUMEN

CONEXIÓN

java.sql.Connection Representa la conexión con la Base de Datos.

El encargado de abrir una conexión es el Driver Manager mediante el método estático: public static Connection get Connection trows java.sql.SQLException Donde: url: Identificador de la Base de Datos usr: Usuario con el que se abre la conexión pwr: Contraseña del Usuario Donde: String Sitio Base: el directorio donde se encuentra la Base de Datos A través de la conexion nos comunicamos con la Base de Datos, enviándole sentencias SQL. public void close() trows java.sql.SQLException;

VISTA PRELIMINAR

Una única aplicación puede tener una o más conexiones con una única base de datos, o puede tener varias conexiones con varias bases de datos diferentes.

La forma estándar de establecer una conexión a la base de datos es mediante la llamada al método Driver Manager.get Connection.

La clase Driver Manager, referida como la capa de gestión JDBC, intenta localizar un driver que pueda conectar con la base de datos representada por la URL. La clase Driver Manager mantiene una lista de clases Driver registradas y cuando se llama al método get Connection, se chequea con cada driver de la lista hasta que encuentra uno que pueda conectar con la base de datos especificada en la URL.

JDBC y URL

Una URL JDBC suministra una forma de identificar una base de datos para que el driver apropiado pueda reconocerla y establecer la conexión con ella.

Los Como se forma una URL JDBC; ellos simplemente usan la URL suministrada con el driver que usan.

Segundo, las URLs JDBC permiten a los desarrolladores de drivers codificar toda la información de la conexión dentro de ella.

Esto hace posible, por ejemplo, para un applet que quiera hablar con una base de datos dada el abrir la conexión sin necesitar que el usuario realice ninguna tarea de administración de sistemas.

Esto quiere decir que la URL JDBC puede referirse a una base de datos lógica o un host lógico que se traduce dinámicamente al nombre actual por el sistema de nombramiento de la red.

1 jdbc el protocolo.

El protocolo en una URL JDBC es siempre jdbc

Envío de Sentencias SQL

JDBC no pone ninguna restricción sobre los tipos de sentencias que pueden enviarse: esto da un alto grado de flexibilidad, permitiendo el uso de sentencias específicas de la base de datos o incluso sentencias no SQL. Prepared Statement tiene un grupo de métodos que fijan los valores de los parámetros IN, los cuales son enviados a la base de datos cuando se procesa la sentencia SQL. Un objeto Callable Statement hereda métodos para el manejo de los parámetros IN de Prepared Statement, y añade métodos para el manejo de los parámetros OUT e INOUT. Si ambas actualizaciones tienen éxito se llama al método commit haciendo estos cambios permanentes, si uno o los dos fallan, se llama al método rollback, restaurando los valores existentes l inicio de la transacción.

La interface Connection define cinco niveles de aislamiento con el nivel más bajo que especifica que no soporte transacciones hasta el más alto que especifica que mientras una transacción esté abierta ninguna otra transacción puede realizar cambios en los datos leídos por esa transacción.

Clase Java DriverManager

Pasando un URL de un controlador JDBC especifico a Driver Manager, la aplicación informa a Driver Manager acerca del tipo de conexion JDBC que debe devolverse a la aplicación.

Los controladores JDBC están diseñados para informar a Driver Manager acerca de si mismos automáticamente cuando se carga su clase de implementación de controlador.

Para asegurarse de que el controlador JDBC nativo puede manejar el URL, las aplicaciones deben utilizar el URL jdbc:db2i Series:xxxx en lugar del URL jdbc:db2:xxxx.

Si la aplicacion no desea que el controlador nativo acepte URLS con el subprotocolo db2, la aplicación deberá cargar la clase com.ibm.db2.jdbc.app.DB2i Series Driver, en lugar de com.ibm.db2.jdbc.app.DB2Driver.

El método Driver Manager.get Connection toma un URL de una sola serie indicado anteriormente, y solo es uno de los métodos de Driver Manager destinado a obtener un objeto Connection.

Registro del controlador JDBC

Antes de utilizar JDBC para acceder a los datos de un archivo de base de datos del servidor, es necesario registrar el controlador JDBC de IBM Toolbox para Java con Driver Manager.

Para cargar el controlador JDBC de IBM Toolbox para Java, antes de la primera llamada a JDBC, añada al programa Java la línea siguiente: El controlador JDBC de IBM Toolbox para Java se registra cuando se carga, siendo este es el método preferido de registrar el controlador.

El controlador JDBC de IBM Toolbox para Java no requiere un objeto AS400 como parámetro de entrada, como lo requieren las demás clases de IBM Toolbox para Java que obtienen datos de un servidor.

Al igual que en las demás funciones de IBM Toolbox para Java, si es el programa Java el que proporciona el ID de usuario y la contraseña, el usuario predeterminado no se establece y la contraseña no se pone en la memoria cache.

Propiedades JDBC de IBM Toolbox para Java

Nota: la lista siguiente no incluye las propiedades de origen de datos.

· Propiedades generales

· Propiedades de servidor

· Propiedades de formato

· Propiedades de rendimiento

· Propiedades de ordenación

Otras propiedades

SUMMARY

CONNECTION

java.sql.Connection represents the connection to the database.

Responsible for opening a connection is the Driver Manager using the static method: public static Connection Connection trows get java.sql.SQLException Where: url: ID usr Database: User with which the connection opens pwr: Password user where: String Site Base: the directory where the database through the connection communicate with the database, sending SQL statements. public void close () trows java.sql.SQLException;

PREVIEW

A single application can have one or more connections with a single database, or you can have multiple connections to several different databases.

The standard way to establish a connection to the database is through the method call Manager.get Driver Connection.

The Driver Manager, referred to as the JDBC management layer, attempts to locate a driver class that can connect to the database represented by the URL. The Driver Manager class maintains a list of registered Driver classes and when you call the get method Connection, is checked with each driver in the list until it finds one that can connect to the database specified in the URL.

JDBC and URL

A JDBC URL provides a way of identifying a database so that the appropriate driver can recognize and establish the connection with it.

The As forms a JDBC URL; they simply use the URL supplied with the drivers they use.

Second, JDBC URLs allow driver developers encrypt all connection information within it.

This makes it possible, for example, for an applet that wants to talk with a given database to open the connection without requiring the user to perform any system administration.

This means that the JDBC URL may refer to a logical database or a logical host that dynamically translates the current name by naming system network.

1 jdbc protocol.

The protocol in a JDBC URL is always jdbc

Sending SQL Statements

JDBC does not put any restriction on the types of sentences that can be sent: this gives a high degree of flexibility, allowing the use of specific judgments of the database or even non-SQL statements. Prepared Statement has a set of methods that set the values of the IN parameters, which are sent to the database when the SQL statement is processed. An object inherits methods Callable Statement for handling the IN parameters Prepared Statement, and adds methods for handling OUT and INOUT parameters. If both updates are successful you call the commit method making these changes permanent, if one or both fail, rollback method is called, restoring the existing values l start of the transaction.

The Connection interface defines five levels of insulation with the lowest level that specifies that does not support transactions up to the highest specifying that while a transaction is open any other transaction can make changes to the data read by the transaction.

Java class DriverManager

Passing a URL of a specific JDBC driver to Driver Manager The Driver Manager application informs about JDBC connection type that must be returned to the application.

JDBC drivers are designed to inform Driver Manager about themselves automatically when you load your driver implementation class.

To ensure that the native JDBC driver can handle the URL, applications must use the URL jdbc: DB2I Series: xxxx instead of the URL jdbc: db2: xxxx.

If the application does not want the native driver accepts URLS with db2 subprotocol, the application must load the com.ibm.db2.jdbc.app.DB2i Series Driver class, instead of com.ibm.db2.jdbc.app.DB2Driver .

The method Manager.get Driver Connection URL takes one number above, and is only one of the methods Driver Manager designed to obtain a Connection object.

Registration JDBC

Before using JDBC to access data from a database file server, you must register the JDBC driver IBM Toolbox for Java Driver Manager.

To load the JDBC driver IBM Toolbox for Java, before the first call to JDBC, add the Java the following line program: The JDBC IBM Toolbox for Java driver when loaded is recorded, and this is the preferred recording method the controller.

The JDBC driver IBM Toolbox for Java does not require an AS400 object as input, as required by other classes of IBM Toolbox for Java to obtain data from a server.

As in the other functions of IBM Toolbox for Java, if Java program that provides the user ID and password, the default user is not set and the password is not put into the cache.

Properties JDBC IBM Toolbox for Java

You can specify many properties to connect to a database server using JDBC. All properties are optional and can be specified as part of the URL or in a java.util.Properties object. If a property is set in both the URL and a Properties object, the value of the URL will be used.

Note: the following list does not include data source properties.

The following tables show the different connection properties that the driver recognizes. Some of these properties affect performance and others are working server attributes. Tables organize the properties in the following categories:

• General Properties

• Server Properties

• Format properties

• Performance Properties

• Property management

other properties

RECOMENDACIONES DE USO

A continuación se proporcionan una serie de recomendaciones para configurar las propiedades de agrupación de conexiones con el fin de optimizar la puesta en común de comportamiento. Tras su creación, los conjuntos de conexiones JDBC son preconfigurados con la configuración por defecto. La configuración por defecto proporciona un aspecto general al pool de conexión.

Sin embargo, las diferentes aplicaciones pueden tener requisitos de conexión de bases de datos diferentes y puede que desee modificar el comportamiento predeterminado de la agrupación de conexiones. Comportamientos, como el tamaño del pool y tiempos de espera de conexión se pueden configurar y puede mejorar el desempeño general del grupo de conexión, así como la disponibilidad de conexión. En muchos casos, la mejor forma de afinar un pool de conexiones para una aplicación específica es intentar diferentes combinaciones de las propiedades utilizando diferentes valores hasta conseguir un rendimiento óptimo

CONCLUSIONES

Este módulo le dio las habilidades y conocimientos para que pueda conectarse a un BD utilizando JDBC.

Específicamente, usted ha aprendido a:

Describir las diferentes piezas de la especificación JDBC

Escribe URL JDBC

Definir las tres funciones que realizan los controladores JDBC en el proceso de solicitud de datos

Definir el propósito de cuatro controladores básicos JDBC

Utilice el DriverManager de JDBC para conectarse al BD

Escribir un programa simple pero completo JDBC

APRESIACION DEL EQUIPO

Bueno hemos comprendido según este trabajo que con la ayuda de JDBC, la habilidad de java para integrarse con Base de Datos es mucho mas fácil y Comprensible para aquellos interesados en el desarrollo de Software y que utilicen una Base de Datos, es posible crear un ambiente ideal tipo cliente-servidor.

GLOSARIO DE TERMINOS

Java Database Connectivity (JDBC)

Estándar de la industria para conectividad independiente de la base de datos entre la plataforma Java y un amplio rango de bases de datos. La interfaz JDBC proporciona una API a nivel de llamada para acceso de base de datos basado en SQL y en XQuery. Vea también Open Database Connectivity.

SQL (Structured Query Language)

Lenguaje estándar de programación utilizado para definir y manipular datos en una base de datos relacional. ESQL, el lenguaje utilizado por WebSphere Message Broker, está basado en SQL y tiene muchas construcciones similares.

Localizador universal de recursos (URL)

La dirección exclusiva de un recurso de información que es accesible en una red como, por ejemplo, Internet. El URL incluye el nombre abreviado del protocolo utilizado para acceder al recurso de información, y la información que utiliza el protocolo para localizar al mismo.

DriverManager. Gestiona el conjunto de controladores Java Database Connectivity (JDBC) que están disponibles para que los utilice una aplicación.

Registro del controlador JDBC

Debe registrar el conductor en su programa antes de usarla. Registro del conductor es el proceso por el cual el archivo de clase de controlador de Oracle se carga en la memoria, por lo que se puede utilizar como una implementación de las interfaces JDBC.

Paquetes de importación JDBC: Añadir las declaraciones de importación para el programa Java para importar las clases requeridas en el código Java.

Formulación base de datos URL: Se trata de crear una dirección con el formato adecuado que apunte a la base de datos a la que se desea conectar.

Crear objeto de conexión: Por último, el código de una llamada al método del objeto DriverManager getConnection () para establecer la conexión de base de datos real.

LINCOGRAFIA

https://www.tutorialspoint.com/jdbc/jdbc-db-connections.htm

http://www.cec.uchile.cl/~luvasque/edo/java/manuales/MsAccess_y_Java.pdf

https://www.tutorialspoint.com/jdbc/jdbc-db-connections.htm

http://javax-peru.blogspot.pe/2009/10/conectando-sql-server-y-netbeans-con_25.html

http://acodigo.blogspot.pe/2013/06/conectar-sql-server-con-java.html

https://azure.microsoft.com/es-es/documentation/articles/sql-database-develop-java-simple/

1 comentario:

Unknown1 de noviembre de 2016, 21:32
Por favor plantear su FORO sobre el tema. Replantear las CONCLUSIONES y RECOMENDACIONES . Además defina con sus propias palabras el APRECIACION DE EQUIPO. Gracias por su investigación. Saludos . Gracias
ResponderEliminar
Respuestas

Añadir comentario

Desarrollo de Software l

domingo, 23 de octubre de 2016

CONNECTION (CONEXION)-JAVA

Clase Java DriverManager

Propiedades

Propiedades de URL

Registro del controlador JDBC

Propiedades JDBC de IBM Toolbox para Java

Propiedades generales

Propiedades de servidor

Propiedades de formato

Propiedades de rendimiento

Propiedades de ordenación

Otras propiedades

Utilización del controlador JDBC para conectarse a una base de datos del servidor

Ejemplos: utilización del controlador JDBC para conectarse a un servidor

Propiedades JDBC de IBM Toolbox para Java

1 comentario:

Bloger