Progress - Error: tabla already exists with "" donde el indice único es un rowid

Que tal a todos:

Estoy trabajando con MFG corriendo en Linux release 4, con Progress version 9.1D modo caracter.

A ver si alguno de ustedes se ha encontrado con este problema previamente y sabe como resolverlo: tengo un programa donde genero una tabla temporal con varios campos y particularmente con un campo de tipo rowid que es a la vez el unico elemento del indice único de la misma tabla, de la siguiente manera:

DEF TEMP-TABLE tt-detasg
[...] /* Mas campos */
FIELD tda-rowid AS ROWID
INDEX tda-idx01 AS PRIMARY UNIQUE
tda-rowid.

La tabla temporal la lleno a partir de dos tablas diferentes pero pongo el rowid de cada tabla en el campo tda-rowid. Si este programa lo ejecuto desde el editor de progres, ya sea bien dandole F1 al codigo o ejecutandolo directamente con la sentencia run programa.p no tengo problemas, el problema se presenta cuando lo ejecuto directamente desde el menu en el que lo tengo instalado, y me aparecen los siguientes mensajes y finaliza el programa

** tt-detasg already exists with "". (132)
** tt-detasg already exists with "šš ͬ** %s re". (132)


Espero alguno de ustedes haya tenido esta misma experiencia y la haya resuelto.

Pensaba que era problema entre las versiones que habia entre los ambientes de desarrollo y produccion, pero aun en el mismo servidor de desarroll se me presenta el problema.

NOTA: Tengo pensado cambiar el indice, aunque aun no pienso como puedo hacerlo, pero resulta interesante el problema como un reto a resolver.

De antemano gracias.
Saludos,
Kike.

Por lo que comentas, no veo que borres el contenido de la tabla temporal antes de creala, si bien es cierto que no comentas si el error te da sismpre o solo despues de la primera ejecucion.
Por si no lo hace yo te recomendaria borrar los datos de la tabla temporal antes de llenarla, para ello sabras que basta un sencillo.
/** **/
FOR EACH tt-detasg.
DELETE tt-detasg.
END.

hazlo sjuto detras de la definicion de la tabla temporal, antes de llenarla.
en caso de no ser el borrado, mira que el cicli de lectira y llenado sea correcto y que no intente llenar dos veces la table temporal con el mismo registro origen.

me gustaria saber si esto soluciona el problema.
Suerte.

Gracias por la atencion DparteD.

Que tal, te comento, efectivamente borro la tabla antes de usarla, al principio del bloque principal, lo obvie, pero tienes razon debi comentarlo.

Resulta que la situacion es la siguiente, tengo el procedimiento lanzado desde un trigger, capturo una variable donde a partir de la misma lleno la tabla temporal, en el mismo update tengo mas variables, de tal forma que en la siguiente linea valido si la tabla tiene informacion y de no ser así, pues ejecuto de nuevo el procedimiento que la llena, lo curioso aqui es que no me esta funcionando el can-find para validar si la tabla tiene al menos un registro, pongo como está mas o menos el codigo para que te des una idea:

/* Aqui lleno la tabla cuando sale de la variable */
on leave or l-part do.
end.

/* bloque principal */
main:
repeat:
end.

/* Procedimeinto */
procedure pr-llena-tabla.
end.


NOTA: Escribo sin acentos para facilitar la lectura.

Sigo intentando, hice una modificacion: en lugar de un can-find cambie la instruccion por una busqueda directamente del primer registro de la tabla, peor de igual forma el programa compilado no encuentra el registro, y el programa que corro desde el editor si lo encuentra, al parecer al salir del campo cuando se ejecuta en el ambiente de MFG lanza mas de una vez el trigger del leave, pero aun no encuentro como es que causa esto...

Por lo pronto voy a dejar el tema, lo resuelvo integrando en el procedimiento el borrado de las tabla temporales e invocando el procedimiento de llenado de la tabla base ahi mismo, implica modificar un poco la logica del programa, pero me resuelve el problema, que ya le meti un dia mas del presupuesto y tengo que entregar ya.

Si encuentro la causa, la publico...

Gracias por el apoyo.

Saludos,
Kike Mtz.

Buenas.

Te comento que el evento LEAVE yo le considero un tanto "Traicionero" y te recomendaria que uses el evento "RETURN" como disparador para casos como este.

Un saludo.