Saludos...

Adjunto el error al ejecutar archivo....

General Protection Fault.
- Llamado desde DBSKIP(0T)
- Llamado desde TBASE_MICROSIGA:LLENAR_VOUCHER(342T)
- Llamado desde TBASE_MICROSIGA:RESCATAR_DATOS(225T)
- Llamado desde TBASE_MICROSIGA:CARGAR_VOUCHER(157T)
- Llamado desde TF_PRINCIPAL:RESCATAR_DATOS(141T)
- Llamado desde (b)CREATE(118T)
- Llamado desde TAPPLICATION:RUN(0T)
- Llamado desde MAIN(22T)

Este tipo de mensaje resulta bastante útil para encontrar donde se produce el error.... pero este caso es diferente a otros.... si observan junto con indicar la linea del error aparece una letra "T"... por ejemplo 342T....

El asunto es el siguiente... un programa "X" emite unos reportes en PDF, estos reportes luego los transformo a archivos TXT... luego hago un append from desde aquel archivo...

Todo perfecto para archivos relativamente pequeños.... pero uno de los archivos que es de un tamaño mayor... en determinada linea arroja este error.... lo extraño es que este proceso funciona perfecto en los primeros 2000 y tantos registros y el registro donde se produce el error no tiene nada de diferente de los registros anteriores o posteriores.....


Alguna idea de la razon....

Saludos...

Saludos...

la verdad es que hace tiempo que no me dedico a esto de la programacion... cuando necesito resolver uno que otro problema... tomo C3 y por lo general me ha resuelto varios dilemas... sobre todo cuando se trata de analizar informacion de gran volumen... en fin.... luego de darle vueltas al asunto me he topado con esto....

Me he puesto a ver el contenido del indice....
Primera muestra:
-------------------------------------------------------------
Tag: PORVOUCHER
Key: 1 Reg: 2708 Clave: [0000000000002708]
Key: 2 Reg: 2709 Clave: [0000000000002709]
Key: 3 Reg: 2710 Clave: [0000000000002710]
etc....


El indice fue construido de la siguiente forma...

Index On ( Right( "000000000" + Alltrim(Str(Micro_Siga->Num_Vou, 8, 0)), 8 ) +;
Right( "000000000" + AllTrim(Str( Micro_Siga->(Recno() ), 8, 0)), 8 ) ) ;
Tag PorVoucher To ( cIndice ) For !Deleted()





Segunda Muestra
-------------------------------------------------------------
Tag: PORVOUCHER
Key: 1 Reg: 1 Clave: [00027764000001]
Key: 2 Reg: 2 Clave: [00027764000002]
Key: 3 Reg: 3 Clave: [00027764000003]

El indice fue construido de la siguiente forma...

Index On ( Right( "000000000" + Alltrim(Str(Micro_Siga->Num_Vou, 8, 0)), 8 ) +;
Right( "000000000" + AllTrim(Str( Micro_Siga->(Recno() ), 8, 0)), 6 ) ) ;
Tag PorVoucher To ( cIndice ) For !Deleted()


Observar que la diferencia entre ambas formas de crear el indice es minima, en el primer caso el largo total del dato a indexar es 16 y el largo del segundo caso a indexar es 14... y sin embargo... los resultados en el indice son diferentes....

Por lo pronto he acortado a 14 el largo del dato indexado y hasta el momento todo funciona perfecto....


Algun comentario.....

Saludos
RHernandezS
Santiago - Chile

Hola, Rodrigo.

Mi experiencia me dice que esos mensajes en los que el número contiene caracteres 'raros' so en 99% producidos por NUESTRO codigo, y la solucion SOLO esta en nuestras manos....

Con respecto al tema del índice, ¿no sería más facil que guardases directamente en un campo de la tabla la codificación que utilizas en la creacion del indice?, ya que la creación de dicho índice se transformaria en ordenar solo por el campo que interesa sin incluir todo ese código que incorporas en la definicion del INDEX ON.

_________________
Un saludo.
Jesús P. Melgar Velasco

Saludos....

El error, luego de probar y probar, estaba en el indice... y mas que la "cantidad" de instrucciones, era el largo del dato indexado... se acorta el largo... desaparece el error... aumenta el largo... aparece el error...

En cuanto a tener un campo con el contenido del dato a indexar, es una opción del todo valida.... pero imagina que tengo "n" formas diferentes de construir un indice "compuesto", luego crear tantos campos como indices compuestos se requieran... haría que el asunto se volviese redundante... aun mas, se deberá prestar mucho atención a que obligatoriamente se deben implementar rutinas que alimenten esos campos "compuestos".. es decir, ya no bastaría con alimentar los campos "normales" sino que ademas se deberá prestar atención en alimentar a los campos "compuestos"... un solo olvido en alimentar el campo compuesto... arruinaría el indice....

La construcción del indice "compuesto", al ser una tarea absorbida por el propia operatoria de creación de ese indice, supone un ahorro de instrucciones y de espacio considerable...

Pero bueno... si existe un solo indice compuesto, es bueno ser practico y crear un campo con contenido compuesto, lo que implica que se debe crear al menos un linea de instrucción para alimentar ese campo compuesto....


En fin... he acortado el largo del dato a indexar y el asunto hasta el momento va bien...

Saludos
RHernandezS