Driver JDBC iNET para SQL Server
Para algunas aplicaciones desarrolladas con GeneXus 9.0 y java, estamos utilizando el driver JDBC iNET - UNA. Es muy rápido, funciona bien y en general no nos ha dado dolores de cabeza. Si se lo usa con cursores firehose, es de lo más rápido que hemos encontrado.
Este es uno de los drivers que GeneXus tiene en la lista de "pre-configurados" con lo que se puede armar la url de conexión sin mayores dificultades.
Al elegirlo GeneXus utiliza una URL como ésta:
jdbc:inetdae:servidor:puerto?database=base
El problema que ocasiona esto, es que si se tienen campos de mas de 255 caracteres, los mismo se ven truncados a este tamaño. Esto es porque trabaja en compatibilidad SQLServer 6.5.
En un cliente (donde había surgido el problema de los datos truncados) habíamos cambiado a :
jdbc:inetdae7:servidor:puerto?database=base
lo cual nos solucionó dicho problema, pero nos ocasionó otros. La performance de la aplicación pasó a ser bastante mala, y algunos bloqueos de registro ESCALABAN a bloqueos de tablas.
Viendo con el Profiler las sentencias problemáticas, vimos que a la base de datos estaba llegando los parámetros de las consultas en UNICODE.
SELECT campos
FROM [TABLA] WITH (UPDLOCK)
WHERE [Tipo] = N'CDP' AND [Id] = N'12154'
Después de leer un poco la documentación de los subprotocolos del driver, donde dice
Con lo que decidimos cambiar a:
jdbc:inetdae7a:servidor:puerto?database=base
Por ahora no hemos tenido problemas. Es mas rápido que trabajar con inetdae7 , y disminuyeron los bloqueos. También lee campos char de más de 255 caracteres sin truncarlos.
Si alguien más está usando este driver, creo que sería bueno que revisen la URL jdbc de conexión, pues un par de letras, pueden hacer la diferencia.
Lo paradojal de este caso, es que hemos pasado mucho tiempo, entre un cambio y el siguiente. La aplicación funcionó varios meses con inetdae, despues paso a inetdae7 y funcionó mas de un año de esa forma, y recién ahora hacemos este otro cambio. Esperemos que sea el último
Este es uno de los drivers que GeneXus tiene en la lista de "pre-configurados" con lo que se puede armar la url de conexión sin mayores dificultades.
Al elegirlo GeneXus utiliza una URL como ésta:
jdbc:inetdae:servidor:puerto?database=base
El problema que ocasiona esto, es que si se tienen campos de mas de 255 caracteres, los mismo se ven truncados a este tamaño. Esto es porque trabaja en compatibilidad SQLServer 6.5.
En un cliente (donde había surgido el problema de los datos truncados) habíamos cambiado a :
jdbc:inetdae7:servidor:puerto?database=base
lo cual nos solucionó dicho problema, pero nos ocasionó otros. La performance de la aplicación pasó a ser bastante mala, y algunos bloqueos de registro ESCALABAN a bloqueos de tablas.
Viendo con el Profiler las sentencias problemáticas, vimos que a la base de datos estaba llegando los parámetros de las consultas en UNICODE.
SELECT campos
FROM [TABLA] WITH (UPDLOCK)
WHERE [Tipo] = N'CDP' AND [Id] = N'12154'
Después de leer un poco la documentación de los subprotocolos del driver, donde dice
2.6 JDBC URL Subprotocols
jdbc:inetdae7: .... support of the SQL Server 7.0 (or higher) feature with unicode data types nText, nVarchar and nChar (the same as ...&sql7=true) jdbc:inetdae7a: .... support of the SQL Server 7.0 (or higher) feature with ASCII data types Text, Varchar and Char. Use this protocol if using i-net MERLIA and JDBC 4.0 API compliance is required. see character converting JDBC 4.0 API jdbc:inetdae6: .... SQL Server 6.5 compatible mode (passwords are transfered plainly) jdbc:inetdae: .... only for compatibility with older versions jdbc:inetpool: .... pooled driver (only OPTA and MERLIA)
Con lo que decidimos cambiar a:
Por ahora no hemos tenido problemas. Es mas rápido que trabajar con inetdae7 , y disminuyeron los bloqueos. También lee campos char de más de 255 caracteres sin truncarlos.
Si alguien más está usando este driver, creo que sería bueno que revisen la URL jdbc de conexión, pues un par de letras, pueden hacer la diferencia.
Lo paradojal de este caso, es que hemos pasado mucho tiempo, entre un cambio y el siguiente. La aplicación funcionó varios meses con inetdae, despues paso a inetdae7 y funcionó mas de un año de esa forma, y recién ahora hacemos este otro cambio. Esperemos que sea el último
Vamos a probar con el 7a a ver como anda porque necesitamos guardar textos grandes.
ResponderBorrarGracias por el tip.
Andres (si el del golero de cacho)
Y que tal les anda??? Pregunto porque me acabo de chocar con el mismo problema.
ResponderBorrarSaludos.
Funciona bien.
ResponderBorrarIgual, hemos dejado de usar ese driver y pasamos a usar uno de codigo abierto, llamado jTDS, que tambien funciona muy bien.
Gracias por responder. Lo voy investigar un poco más (esta bastante duro no vengo encontrando experiencias en el tema).
ResponderBorrarNosotros tenemos una aplicación estable hace varios años con jdbc:inetdae y como que "nos da cosa" cambiarlo y generar nuevos inconvenientes.
Para que te des una idea de lo complicado que se nos esta haciendo, hasta leer este post estaba considerando llevarlo a inetdae7, por lo menos ahora este ya lo descarte.
Una ultima pregunta y no molesto más ¿El cambio de driver a jTDS, es solo por que es código abierto, o por alguna otra razón?
Gracias de nuevo.
El cambio fue solo para evitar problemas de licenciamiento.
ResponderBorrarTengo una consulta....como configuras el jTDS en la version 7.5?, pues en la 9.0 no he tenido problemas, pero debo configurar un modelo en esta version y no he podido encontrar informacion de como configurarlo( con jTDS)
ResponderBorrarLes agradeceria muchisimo enviar informacion a carlosyanezc@gmail.com
Carlos:
ResponderBorrarDeberias ver en el client.cfg de la 9.0, la URL que arma para ese driver, y ponerselo al de la 7.5, poniendolo en las proipiedades del driver (creo que se llamaban Custom Url).
No deberia ser ocmplicado.