jTDS controlador JDBC: getNString() lanza error

Question

estoy usando el controlador jTDS JDBC y cuando llamo ResultSet.getNString(index); Me da la siguiente excepción:

run: 
Exception in thread "main" java.lang.AbstractMethodError: net.sourceforge.jtds.jdbc.JtdsResultSet.getNString(I)Ljava/lang/String; 
    at javasql.ProductsController.PrePopulate(ProductsController.java:51) 
    at javasql.ProductsController.<init>(ProductsController.java:37) 
    at javasql.Program.main(Program.java:25) 
Java Result: 1 
BUILD SUCCESSFUL (total time: 6 seconds) 

cuando uso getString(index) funciona bien .. es sólo con getNString() que tengo un problema y la columna en mi tabla MSSQL se define como NVarChar. Entonces, ¿qué da? ¿JtDS no es compatible con getNString()? Tal vez se obtiene VarChar y NVarChar a través de la misma función getString()?

EDIT:

problema Unicode relacionada .. Veo que tratando de utilizar Unicode no funciona para insertar tampoco. Mi columna se define como nvarchar(255) y sin embargo la siguiente INSERT declaración no funciona:

private final String INSERT_FORMAT = "INSERT INTO Products (Name, Price, QuantityInStock) VALUES (N'%s', %s, %s)"; 

    public void Insert(Product p) { 
      products.add(p); 
      try { 
       statement.addBatch(String.format(INSERT_FORMAT, p.getName(), p.getPrice(), p.getQuantityInStock())); 
      } catch (SQLException ex) { 
       System.out.println(ex.getMessage()); 
      } 
     } 

public void SaveChanges() { 
     try { 
      statement.executeBatch(); 
     } catch (SQLException ex) { 
      System.out.println(ex.getMessage()); 
     } 
     RefreshData(); 
    } 

los caracteres Unicode que muestran que de entrada como signos de interrogación en la base de datos. Esto normalmente ocurre cuando se olvida de anteponer N a dicho parámetro en la instrucción de inserción ... pero aquí puede ver que lo he especificado claramente. La lista de características de JtDS dice que soporta NVARCHAR, NTEXT, etc. pero actualmente solo veo problemas. ¿Qué estoy haciendo mal?

EDIT 2

Número 1 se resuelve .. Me insertan algunos caracteres chinos directamente en la base de datos a través de SSMS y cuando utilicé getString(index), que funcionaba bien. Entonces parece que jTDS usa getString para todos los tipos de texto, supongo. Extraño, entonces no arroja algún tipo de excepción no admitida para la función getNString(index).

Entonces, ahora nos queda el problema de cómo insertar datos Unicode en una columna 0ARCHIVO NVARCHAR. Seguramente alguien aquí ha tenido experiencia con esto?

EDITAR 3

he cambiado de código para utilizar una declaración preparada en cada método en lugar de tratar de utilizar un lote y se utiliza la setInt, setString, etc métodos. Sin embargo, sigo teniendo los mismos problemas ... si uso setString() para unicode, se inserta ??? en mi db. Si uso setNString() entonces obtengo el mismo error que recibí en la parte superior de esta publicación cuando estaba haciendo getNString ... Esto es una locura ... ¿cómo podría este controlador llegar a ser tan popular si no es compatible con unicode ?? ¿Que me estoy perdiendo aqui? El sitio dice que es compatible con NVARCHAR, etc. entonces, ¿qué cosa tan poco intuitiva es que tengo que hacer para que esto funcione?

Answer 1

getNString se agregó con Java 1.6/JDBC 4.0. Parece que tu controlador es demasiado viejo.

Answer 2

¿Qué tipo es su clave principal? que tenían exactamente el mismo problema que usted está descrito, es decir: que podía recuperar los datos almacenados como NVARCHAR utilizando el método clásico getString(), pero los cambios no funcionaba, incluso después de haber establecido la opción sendStringParametersAsUnicode a verdadera ... hasta que cambie la clave primaria de NVARCHAR a VARCHAR. Ahora funciona para mí Las actualizaciones no produjeron ningún error, simplemente parece que no se pudo encontrar la clave principal y, por lo tanto, no pasó nada ... Aún así, esperaba poder utilizar el almacenamiento unicode para algunos campos sin establecer la opción sendStringParametersAsUnicode para cierto, pero tengo la impresión de que no es posible, a menos que tal vez escribiendo las columnas correspondientes de la forma byte [] en lugar de NVARCHAR y el establecimiento utilizando los setBytes() método (como se sugiere here/)