Método consistente en la inserción de TEXTO de la columna a la base de datos de Informix utilizando JDBC y ODBC

Question

Tengo un problema cuando trato de insertar algunos datos Informix columna de TEXTO a través de JDBC.En ODBC me puede simplemente ejecutar SQL como este:

INSERT INTO test_table (text_column) VALUES ('insert')

pero este no trabajo en JDBC y tengo el error:

617: A blob data type must be supplied within this context.

He buscado por tal problema y encontrar mensajes de 2003:

http://groups.google.com/group/comp.databases.informix/browse_thread/thread/4dab38472e521269?ie=UTF-8&oe=utf-8&q=Informix+jdbc+%22A+blob+data+type+must+be+supplied+within+this%22

He cambiado mi código para utilizar PreparedStatement.Ahora funciona con JDBC, pero en ODBC cuando trato de usar PreparedStatement tengo de error:

Error: [Informix][Informix ODBC Driver][Informix]
Illegal attempt to convert Text/Byte blob type.
[SQLCode: -608], [SQLState: S1000]

Tabla de prueba fue creado con:

CREATE TABLE _text_test (id serial PRIMARY KEY, txt TEXT)

Jython código para probar ambos conductores:

# for Jython 2.5 invoke with --verify
# beacuse of bug: http://bugs.jython.org/issue1127

import traceback
import sys
from com.ziclix.python.sql import zxJDBC

def test_text(driver, db_url, usr, passwd):
    arr = db_url.split(':', 2)
    dbname = arr[1]
    if dbname == 'odbc':
        dbname = db_url
    print "\n\n%s\n--------------" % (dbname)
    try:
        connection = zxJDBC.connect(db_url, usr, passwd, driver)
    except:
        ex = sys.exc_info()
        s = 'Exception: %s: %s\n%s' % (ex[0], ex[1], db_url)
        print s
        return
    Errors = []
    try:
        cursor = connection.cursor()
        cursor.execute("DELETE FROM _text_test")
        try:
            cursor.execute("INSERT INTO _text_test (txt) VALUES (?)", ['prepared', ])
            print "prepared insert ok"
        except:
            ex = sys.exc_info()
            s = 'Exception in prepared insert: %s: %s\n%s\n' % (ex[0], ex[1], traceback.format_exc())
            Errors.append(s)
        try:
            cursor.execute("INSERT INTO _text_test (txt) VALUES ('normal')")
            print "insert ok"
        except:
            ex = sys.exc_info()
            s = 'Exception in insert: %s: %s\n%s' % (ex[0], ex[1], traceback.format_exc())
            Errors.append(s)
        cursor.execute("SELECT id, txt FROM _text_test")
        print "\nData:"
        for row in cursor.fetchall():
            print '[%s]\t[%s]' % (row[0], row[1])
        if Errors:
            print "\nErrors:"
            print "\n".join(Errors)
    finally:
        cursor.close()
        connection.commit()
        connection.close()


#test_varchar(driver, db_url, usr, passwd)
test_text("sun.jdbc.odbc.JdbcOdbcDriver", 'jdbc:odbc:test_db', 'usr', 'passwd')
test_text("com.informix.jdbc.IfxDriver", 'jdbc:informix-sqli://169.0.1.225:9088/test_db:informixserver=ol_225;DB_LOCALE=pl_PL.CP1250;CLIENT_LOCALE=pl_PL.CP1250;charSet=CP1250', 'usr', 'passwd')

Hay alguna configuración en JDBC o ODBC para disponer de una versión de código para los conductores?

Información de la versión:

• Servidor:IBM Informix Dynamic Server Versión 11.50.TC2DE
• Cliente:
  • El controlador ODBC de 3.50.TC3DE
  • IBM Informix JDBC Driver para IBM Informix Dynamic Server 3.50.JC3DE

Answer 1

En primer lugar, ¿estás realmente seguro de que desee utilizar un Informix tipo de TEXTO?El tipo es una molestia para su uso, en parte debido a los problemas que está enfrentando.Pre-fechas de cualquier cosa en cualquier SQL estándar con respecto a los grandes objetos (TEXTO aún no está en SQL-2003 - a pesar de que aproximadamente el equivalente estructuras, CLOB y BLOB, son).Y la funcionalidad de BYTE y de TEXTO blobs no ha sido cambiado desde - oh, digamos 1996, aunque sospecho que no es un caso para la elección de una fecha anterior, como el de 1991.

En particular, la cantidad de datos que vas a almacenar en las columnas de TEXTO?Su ejemplo muestra la cadena "insertar";que es, supongo, mucho, mucho, mucho más pequeña de lo que realmente uso.Usted debe ser consciente de que un BYTE o columnas de TEXTO utiliza un 56 bytes descriptor en la tabla de más de una página aparte (o un conjunto de páginas) para almacenar los datos reales.Así, por pequeñas cadenas como eso, es un desperdicio de espacio y ancho de banda (ya que los datos para el BYTE u objetos de TEXTO serán enviados entre el cliente y el servidor por separado del resto de la fila).Si su tamaño no llegar a cerca de 32 KB, entonces usted debe buscar en el uso de LVARCHAR en lugar de TEXTO.Si usted va a utilizar los datos de tamaños superiores que, a continuación, un BYTE o un TEXT o BLOB o CLOB son alternativas razonables, pero usted debe mirar en la configuración de cualquiera de los espacios de blob (de un BYTE o de TEXTO) o smart blob espacios (por BLOB o CLOB).Usted puede, y son, el uso de TEXTO EN TABLA, en lugar de en una burbuja de espacio;debe saber que si lo que incide en los registros lógicos mientras que el uso de un blob espacio no afecta nada, como mucho.

Una de las características que he estado haciendo campaña a favor de una década, es la capacidad para pasar los literales de cadena en las sentencias SQL como literales de TEXTO (o BYTE literales).Que es, en parte, debido a la experiencia de gente como tú.Todavía no he tenido éxito en conseguir que se priorizadas por delante de los otros cambios que necesitan ser hechas.Por supuesto, usted necesita estar consciente de que el tamaño máximo de una instrucción SQL es de 64 KB de texto, por lo que podría crear demasiado grande de una instrucción SQL si usted no tiene cuidado;los marcadores de posición (signo de interrogación) en el SQL normalmente impedir que ser un problema - y el aumento del tamaño de una instrucción SQL es otra característica de la solicitud que he estado haciendo campaña para que, pero un poco menos ardientemente.

OK, suponiendo que haya fundadas razones para el uso de TEXTO...lo siguiente.No me queda claro lo de Java (JDBC driver) está haciendo detrás de las escenas - aparte de demasiado -, pero es una apuesta justa que es darse cuenta de que un TEXTO 'localizador' estructura es necesaria y es el envío de los parámetros en el formato correcto.Parece que el controlador ODBC no es caer con similar travesuras.

En ESQL/C, donde yo normalmente trabajo, a continuación, el código tiene que lidiar con BYTES y el TEXTO de manera diferente de todo lo demás (y BLOB y CLOB han de ser tratadas de manera diferente de nuevo).Pero usted puede crear y rellenar un localizador de estructura (loc_t o ifx_loc_t de localizador.h - que no pueden estar en el directorio ODBC;es en $INFORMIXDIR/incl/esql por defecto) y que pase a la ESQL/C código de la variable de acogida para el marcador de posición en la instrucción SQL.En principio, probablemente se trata de un método paralelo disponible para ODBC.Usted puede mirar en el controlador ODBC de Informix manual para encontrarlo, aunque.