Cesar Ricardo Guerra Arnaiz
--
Has recibido este mensaje porque estás suscrito al grupo "Spring User Group Peru" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a spring-user...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a spring-user-group...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/spring-user-group-peru?hl=es.
Que tal Roger
interesante tu ejemplo ... es casi idéntico a como lo tengo manejado yo, a excepción
del PROCEDURE en si que lo tenia con FETCH. Me interesa ver el tu clase:
SerieBolRowMapper... ya que ahí es donde realizas el parseo respectivo, si
pudieras enviármela para ojearla.
No se porque ese limitante en si de no usar FETCH en el desarrollo de CURSORES
en ORACLE Procedure, para ser obtenido dentro en una lógica JAVA, ya que si por
ejemplo sale un requerimiento de consumir Procedure de tipo Regresión (desarrollos
antiguos), para obtener algunos datos "y estos tiene internamente una Lógica
con Fetch por N motivos", por el simple hecho de que JAVA tiene este
problema en la obtención, no se va a mandar modificar dicho Procedure. Que
opinan.
Cesar Ricardo Guerra Arnaiz
Ok Gracias por los aportes compañeros, al final el problema estaba en si en el ORACLE PROCEDURE, debido al problema con el FETCH del CURSOR, debido a eso modifique en base a las recomendaciones dadas, el diseño del PROCEDURE y con eso ya no pasa el vendito error y muestra los datos de forma correcta. Esto podría tomarse en cuenta como un Workaround, ya que si hubiera tocado no crear el PROCEDURE sino consultar uno que maneja el CURSOR de la otra manera, existirían problemas de nuevo y para modificar un PROCEDURE de Regresión es más bravo debido a las posibles consecuencias.
Aquí les comparto trozos de código, de las partes más resaltantes del aplicativo que estaba realizando. Saludos y gracias a todos.
Cesar Ricardo Guerra Arnaiz