Hola a todos.
Les escribo porque estoy teniendo un problema con la operación exa00014 “Generar acta de examen”. Al momento de generar el acta, los alumnos deberían ser listados alfabéticamente por apellido / nombre (seteado en el parámetro del sistema), en cambio, desde hace unos días esto no sucede correctamente en “producción”
Hasta hace unos meses nunca habíamos tenido ningún tipo de problema con la operación. Es más, en preproducción la operación funciona correctamente.
Ejecutando la operación con la misma versión de la aplicación, con un backup del mismo día de la base de datos de producción, pero en el servidor de preproducción, el listado sale de manera correcta sin ningún tipo de problemas. En cambio, al ejecutarla en producción, para la misma mesa que antes, en vez de listar los alumnos como un todo pareciera como que separa la lista en dos (sin tener ningún parámetro claro en cuenta), ordena ambas partes de la lista y luego las une, quedando por ejemplo:
ALVEZ, xxxx
FERNANDEZ, xxxx
MENDOZA, xxxxx (hasta aca la primer parte )
BENITEZ, xxxx
DOMINGUEZ, xxxx
MARTINEZ, xxxxx
Puede que el problema de la operación tenga algo que ver con la configuración del motor de Informix?? nos surge esta cuestión dado que en enero de este año hicimos un cambio de servidor en “producción”, y hasta diciembre del año pasado la operación funcionaba sin problemas.
Cómo andás Emilio? gracias por responder.
Instalamos la version 9.21 de Informix (la misma que teníamos en el servidor anterior)
Con respecto a los dbspaces temporales, tenemos dos. Cada uno con un chunk correspondiente de 1887436 kb de tamaño (también así lo teníamos en el anterior)
El problema y la solución es lo que dice Emilio, la combinación de los 2 dbspaces temporales y la instrucción indicada, a nosotros nos pasó hace varios años.
En que versión están? Yo creía que esto estaba solucionado definitivamente por el SIU para todas las versiones posteriores a cuando se detectó el problema.
Gustavo los procesos fueron cambiados luego de que habias detectado es eproblema cuando había mas de un dbspace temporal en combinación con la cláusula WITH NO LOG en las tablas temporales
Procesos: sp_crear_acta y sp_crear_acta_curs.
Gracias a todos por opinar y perdón por la demora. Como el problema se presenta en producción únicamente podemos testear cuando el usuario utiliza la operación
Emilio, saque el “WITH NO LOG” a la creación de la tabla temporal dentro del sp_crea_acta, pero sigue ordenando incorrectamente.
Se lo sacaste en todo el SP? (Si no me equivoco está como 5 veces en el SP) Lo hiciste en producción? El problema se presenta en actas creadas después que catalogaste el SP modificado?
Me parece raro que continue si sacaste el “WITH NO LOG” …
una alternativa de cambio de configuración es que antes hayas tenido la variable de ambiente DBSPACETEMP apuntanto a un dbspace y aunque tuvieses dos siempre tomaba uno.
Temporary tables in the server can be automatically routed to a dbspace. The DBSPACETEMP environment variable can be set to one or more dbspaces. If the DBSPACETEMP environment variable is not set, the server uses the value of the DBSPACETEMP configuration parameter. Temporary tables are fragmented across the dbspaces listed in either the environment variable or the configuration parameter. This occurs regardless of whether the query is a PDQ query or not.
Hola a todos.
Hoy me comunicaron que las actas se están generando de manera correcta. Así que el cambio en el sp funciona bien.
El único problema que noté fue con la prueba de ayer (hicimos una sola, porque le quedaba esa sola para generar). Era un acta a generar con cuatro alumnos. No recuerdo bien los apellidos, pero el caso fue algo asi:
Me llamó la atención que el único desordenado era el que tenía la Ñ (en el ejemplo, Beñez debería salir antes de Bernal). Puede ser un problema de configuración en el motor, que no esté tomando la Ñ como una letra?
Gustavo, estamos (todavía) en la versión 2.0.2. En breve vamos a estar con la 2.6.2, y la respuesta a las tres preguntas es “si”.
Respecto de tu prueba seguramente pasa eso porque toma la Ñ como un caracter especial, no una letra.
Respecto del cambio de versión, cuando lo hagan pasen directamente a la última 2.6.4, no tiene sentido quedarse en la 2.06.2. Es el mismo esfuerzo practicamente, apenas correr unos scripts más, y ya estarán en la última.
Gustavo, recién estuve probando en preproducción si ocurría lo mismo con lo de las Ñ, y efectivamente la toma como caracter especial.
Con respecto al cambio de versión, seguramente vamos a ejecutar los scripts para estar con la 2.6.4 y no volver a quedar atrasados.
Gracias a todos por la ayuda.
Saludos
El ordenamiento es por código ascii así que la Ñ va al fondo. Este problema lo tuvimos cuando implementamos en UBA-Odontología, y claro, nos llegaron las quejas. Patricia habló con la gente del SIU pero no recuerdo en que estado quedó. Lo que si me acuerdo es que el arreglo no era nada fácil y lo dejamos así.