[ Solucionado ] Error Specify Retrieval Argument

Buenas noches.

En una instancia que he creado del Guaraní (hecho ya hace tiempo), me empezó a aparecer ahora, al querer crear una comisión (cur00002) luego de seleccionar la opción del menú, la ventana de solicitud de argumentos cuyo título de la misma es Specify Retrieval Arguments y en la misma solicita que se ingrese el valor de la UA!. A modo de prueba, le coloco el 1 y avanza, pero no graba nada finalmente…
Que puede estar pasando?? algún error de la base de datos??
La versión es la 2.6.4
Se puede correr algún proceso para chequear la integridad o repararla?
Muchas gracias.

José Luis

José Luis:

Es un ejecutable recién compilado, por alguna modificación? O es un ejecutable viejo que ahora te empieza a dar ese error?

Es muy raro que de repente empiece a dar un error de ese tipo si todo funcionaba bien … salvo que haya alguna corrupción de datos que haga que empiece a dar un error no previsto …

Por otra parte, deberían cambiar de versión, es muy muy vieja esa …

Abrazo

Gustavo

Hola Jose Luis, ademas de recomendarte que por favor vean la posibilidad de actualizar de version (se quedaron muy atras!!!) lo que puede suceder es que no tengan bien configurado los datos en la tabla sga_valor_inicial.

Podes mostrar lo que devuelve las siguientes consultas?

SELECT unidad_academica FROM sga_unidades_acad;
SELECT unidad_academica, campo, valor_inicial FROM sga_valor_inicial;

Hola, muchas gracias por las respuestas…

Gustavo, es imposible que sea un error del aplicativo pues nosotros no tenemos los fuentes y usamos los ejecutables que nos han pasado oportunamente. Además es el mismo ejecutable que uso en distintas instancias y en una funciona bien y en la otra no. Por lo que entiendo que es un error de datos o de corrupción de la base.

Alejandro, con respecto a los select que me pedías, en ambos casos arroja información. En el primero me muestra el nombre de la
Unidad_academica IFTS1

en el otro:

Unidad_academica IFTS1
campo: unidad_academica
valor_inicial: IFTS1

Como puedo verificar que no sea alguna corrupción en alguna tabla en particular?

Finalmente con respecto a la versión, es verdad que es vieja, pero tengo varios problemas para actualizarla… a) Con la última versión, tengo que armar un nuevo servidor remoto, pues no corre con windows, b) en la última que corre con windows, pierdo las estadísticas y me obliga a instalar un nuevo módulo… c) estoy solo para el mantenimiento del sistema, del sitio web y de varios otros temas, por lo que no tengo tanto tiempo para dedicarle a la migración y por último, por los proxy y demás bloqueos en la red del GCBA, necesitamos pagar internet aparte y el servidor remoto aparte… si quiero hacer el update, necesitaría armar otro servidor remoto nuevo y pagar el uso por el tiempo que me demande esta tarea!!!.. es todo un lío trabajar sin recursos!!!

Decis que en una base funciona bien el ejecutable pero en la otra no.
La base que no funciona es una copia de la base donde funciona el exe? ¿Misma version del sistema?

Este error lo da tambien en otras operaciones del sistema? (Proba cualquier operacion como ser ABM de Materias, ABM de Carreras , ABM de Motivos de ausencias a clase, reportes, etc…)

No es una base generada de cero.

En las operaciones más comunes no me da error… ABM Materias: OK, ABM Carreras: OK; ABM Dìas no laborales: OK; ABM Motivos de Inasistencia: OK
Cuando intento ver un reporte que incluye comisiones, aparece otro error… en este caso, al acceder a “Cursada - Reportes - Comisiones de un período lectivo”, me aparece, luego de seleccionar el año y período + “Procesar”, una error … Tìtulo de la ventana de error: Error Base de datos (-243) y dentro de la ventana: Could not position within a table ( within a table (dba.sga_comisiones). … el desbalanceo de paréntesis es el que muestra y no un error de tipeo mio.
Evidententemente hay un error en la tabla o ínidces, pero si selecciono la tabla con access, me muestra toda la info bien… si le hago un select desde el SQL Editor, me muestra toda la data sin problemas…

Fijate estos mensajes del foro con el mismo error:
http://foro.comunidad.siu.edu.ar/index.php?topic=3088.msg10916
http://foro.comunidad.siu.edu.ar/index.php?topic=8368.msg35709

Hola Alejandro, buenas noches y gracias por responder a mis preguntas…

Probé con lo que mencionás en ambos artículos y no me solucionó el error… si bien en varios íncides me indica que debo lockear la base para verificarlos…

Te adjunto el resultado del oncheck y de los onstat que mencionás en uno de los artículos para ver si me podés orientar un poco más en cual es el problema…
Desde ya, muchas gracias.

José Luis


onstatgall.txt (726 KB)

onstatall.txt (835 KB)

José Luis:

El error ese que mencionas es un error típico que la aplicación quiere acceder a una tabla que está tomada por otro usuario dentro de una transacción y no la libera. Por ejemplo, cuando yo hago algún arreglo de tablas por SQL dentro de una transacción sin hacer el commit, si yo o un usuario quieren accceder a esas tablas , les da ese error -243 y el mensaje que no se puede posicionar dentro de la tabla.

Por otra parte, viendo rápidamente los archivos que enviaste, veo que hay problemas con los logical logs, que sería bueno hacer un backup de los logical logs con un ontape -a.

Además, habría varias pequeñas cosas para hacer para mejorar la configuración del motor. Por ejemplo el Rootdbspace es muy chico (tiene el valor default de instalación), las variables SHMVIRTSIZE y SHMADD tienen también los valores default y seguramente conviene aumentarlas.

Finalmente, cuando decís en otro mensaje:

“a) Con la última versión, tengo que armar un nuevo servidor remoto, pues no corre con windows” ==> no es así, ya que Alejandro sugirió que pasaras a la última versión del Guarani 2.9.x , NO a l nuevo Guaraní (3.0). Todas las versiones del 2.x.x corren sobre Windows obviamente la parte de Gestión

“b) en la última que corre con windows, pierdo las estadísticas y me obliga a instalar un nuevo módulo…” ==> No entiendo lo de las estadisticas, ningún cambio de versión en las versiones 2.x perdés ningún tipo de estadisticas, de ninguna manera. Y tampoco entiendo a que otro módulo te referís que te obligan a instalar, que yo sepa no hay ningún módulo nuevo del sistema en esas versiones que dificulte el cambio de versión

"c) estoy solo para el mantenimiento del sistema, del sitio web y de varios otros temas, por lo que no tengo tanto tiempo para dedicarle a la migración " ==> esto es lo único que es cierto, de lo cual yo doy fe. Pero las autoridades deberían buscar la manera de hacerlo, aunque sea contratando el trabajo puntual del cambio de versión, que después de todo no debería ser tan terrible.

Desde ya, sabes que podes contar conmigo, cualquier cosa me llamás.

Abrazo

Gustavo

Pareciera que el problema esta en los indices o espacio de datos de la tabla sga_comisiones.
¿Podras enviar lo que informa este oncheck?
oncheck -ciIdDt nombre_base:sga_comisiones

Alejandro, buenas noches…
Parece que habrìa un problema en estos índices…

Te adjunto el resultado del comando que me pasaste…
Decime si hace falta reindexar y si conviene borrar todos los índices y volverlos a generar… en este caso como se puede hacer?

Muchas gracias.

José Luis


ch_comisiones.txt (12.9 KB)

El problema esta en estos indices que deben ser indices que corresponden a Foreign Keys de la tabla sga_comisiones:

Please Drop and ReCreate Index 1358_8481 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8686 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8706 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8707 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8708 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8709 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8710 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8711 for ifts1:dba.sga_comisiones.
Please Drop and ReCreate Index 1358_8712 for ifts1:dba.sga_comisiones.

Fijate si son estosindices:
SELECT * FROM sysindexes WHERE tabid = (SELECT tabid FROM systables WHERE tabname = ‘sga_comisiones’);

Para ver que constraints que corresponden a esos indices con problemas debes borrar y volver a crear:
SELECT * FROM syscontraints
WHERE tabid = (SELECT tabid FROM systables WHERE tabname = ‘sga_comisiones’)
AND idxname IN (SELECT idxname FROM sysindexes WHERE tabid = (SELECT tabid FROM systables WHERE tabname = ‘sga_comisiones’));

El codigo para borrar y crear estas FK, estan en el catalogo de la version, en \base_de_datos\Sql\Fk. Alli encontras un archivo con cada foreign key. Busca las que se correspondan con estos indices que estan corruptos.

Hola Jose Luis,
Fijate si estos pasos te resuelven

  1. borra los siguientes indices :
    drop index 1358_8481 ;
    drop index 1358_8686 ;
    drop index 1358_8706 ;
    drop index 1358_8707 ;
    drop index 1358_8708 ;
    drop index 1358_8709 ;
    drop index 1358_8710 ;
    drop index 1358_8711 ;
    drop index 1358_8712 ;

  2. obtener los SQLs de creacion de Foreign Keys de la tabla sga_comisiones y ejecutarlos

  3. verifica ejecutando el oncheck si sigue dando error de indices

comentanos como te va

Alejandro,
Efectivamente son esos los índices que están corruptos y corroboré que son todos los pertenecientes a comisiones.
Lamentablemente no tengo la info que mencionás para buscar las FK (recordá que no tengo los fuentes y tampoco accedo a toda la documentación del portal)… voy a tratar de buscar en los scripts de creación de la base cuales son los fk que le corresponden a comisiones.

Muchas gracias.

Saludos a todos.
José Luis

José Luis:

Si no lo solucionás fácil, no te ahogues en un vaso de agua. Llamáme y lo solucionamos rápido.

Saludos

Gustavo

Si no tenes el catálogo de la base, para obtener el código de creacion de cada uno de esos indices/fk con el comando dbschema:
dbschema -d nombre_base -t sga_comisiones

José:

Como te dice Alejandro, corriendo el dbschema de la tabla te da todo lo necesario para recrear la tabla y sus indices.

Te conviene correr:
dbschema -d nombre_base -t sga_comisiones > archivo_de_texto.txt para poder obtener luego las sentencias para creación de los indices.

No recuerdo si para borrar los indices se ejecuta un DROP INDEX o un ALTER TABLE sga_comisiones DROP CONSTRAINT nombre_de_la_FK

Saludos

Gustavo

Buenas noches…

Les cuento, para finalizar el tema que luego de luchar con los índices que estaban dañados, intentando borrarlos y volverlos a generar, la situación se ponía cada vez peor, pues corrí nuevamente el chequeo y me arrojaba errores en otros índices más, así como en los que recién había creado… luego de otro intento, ya al querer correr el chequeo, el mismo ya no finalizaba y debía cancelarlo… Opté por recurrir a un backup anterior al problema y restaurarlo… tampoco me dejaba… pensé que sería un problema ya de espacio e intenté borrar esa y otra base que tenía de capacitación… La de capacitación pude borrarla, pero la que estaba con problemas no la pude borrar… el error persistía, hasta que un alma caritativa me dió una mano y finalmente era una tontería (que supuestamente ya estaba reportada en el foro) y es el error del literal “var’s” que cancela el proceso…
El alma caritativa, la veo en muchas ocasiones contestando a aquellos que tenemos problemas y no es más que Gustavo Palau a quien le quiero agradecer el tiempo y la inmensa paciencia que me ha tenido.
Con estos cometarios a modo de conclusión, podrían dar por solucionado el tema… Muchas gracias a todos los que han sumado ideas y me han dado una mano.

Muchas gracias y buen fin de semana.

José Luis

Si, ese era un problema a corregir el el sql del dbexport (saca rla comilla simple de “-- var’s”).
Otro caso que podia generar problemas al importar una base es este.