error con encodedate en delphi 7

[[Lepe]]

No me gusta para nada ese código, no hay control de errores de ningún tipo.

Fieldbyname podría petar si no encuentra el campo; el valor que llega puede no ser un entero o incluso un cero por no tener valor; el año no se sabe si está en 2 o 4 dígitos (encodedate acepta desde 1 a 9999, pero yo le daría el valor correcto). Cuidado con espacios en los varchar que pueden hacer fallar el StrToInt, usa un Trim para quitar dichos espacios antes de pasarlos al StrToInt.


Estoy seguro que has verificado los datos que le llegan, pero es que... la función encodedate está muy probada, es imposible que tenga un bug o fallo, por eso debe ser algo de tu aplicación Sí o Sí.

Lo de buscar el fallo por rtl70 creo es el último paso, primero me centraría en los fallos tontos que he comentado.

[Casimiro Noteví]

¡¡¡Uuufff!!!, totalmente de acuerdo con Lepe, además veo otras cosas, por ejemplo el RecordCount, normalmente no te devuelve los registros de la tabla, salvo que hayas hecho antes un .Last. También deberías comprobar qué valores vienen en esos campos para asegurarte de que son correctos, lo mismo viene algún null. En fin, que no es la forma.
En fin, que tienes que comprobar muchas cosas, además de esas variables que no tenemos ni idea de qué son ni para qué sirven, también habría que preguntarse el motivo de guardar en varchar los años, meses y días, etc.

[ecfisa]

Hola.

Cien por ciento de acuerdo con ustedes sobre falta de controles de errores, pero no visualizaba un Access violation en ese código. Por las dudas probé EncodeDate con las conversiones mas variadas que me permitió el compilador como StrToInt(VarToStr(FieldByName('DD').Value)) por ejemplo. También puse campos a NULL, a '0' y '', pero lo único que logré fueron errores de conversión.

Coincido con Lepe que ese error se esta provocando en otra parte y no en EncodeDate. Los enlaces que puse refieren que el error se manifiesta en rtl70.bpl pero lo atribuyen a la inclusión de componentes no nativos. La verdad es que jamás se me presentó ese error ni había escuchado de él...

Un saludo.

[richy08]

Empezado por Casimiro Notevi

¡¡¡Uuufff!!!, totalmente de acuerdo con Lepe, además veo otras cosas, por ejemplo el RecordCount, normalmente no te devuelve los registros de la tabla, salvo que hayas hecho antes un .Last. También deberías comprobar qué valores vienen en esos campos para asegurarte de que son correctos, lo mismo viene algún null. En fin, que no es la forma.
En fin, que tienes que comprobar muchas cosas, además de esas variables que no tenemos ni idea de qué son ni para qué sirven, también habría que preguntarse el motivo de guardar en varchar los años, meses y días, etc.

valla habia usado el recordcount de esa manera y recorriendo los campos con un while y nunca me habia dado problemas, en el debuger he visto que los campos llegan correctamente en el formato que los espero, y lo mas extraño es que ya habia testeado sin ningun problema

[richy08]

Empezado por Lepe

No me gusta para nada ese código, no hay control de errores de ningún tipo.

Fieldbyname podría petar si no encuentra el campo; el valor que llega puede no ser un entero o incluso un cero por no tener valor; el año no se sabe si está en 2 o 4 dígitos (encodedate acepta desde 1 a 9999, pero yo le daría el valor correcto). Cuidado con espacios en los varchar que pueden hacer fallar el StrToInt, usa un Trim para quitar dichos espacios antes de pasarlos al StrToInt.


Estoy seguro que has verificado los datos que le llegan, pero es que... la función encodedate está muy probada, es imposible que tenga un bug o fallo, por eso debe ser algo de tu aplicación Sí o Sí.

Lo de buscar el fallo por rtl70 creo es el último paso, primero me centraría en los fallos tontos que he comentado.

hola lepe gracias por tus comentarios, efectivamente los campos que extrae el query son varchar y para los meses del 1..9 se les antepone un 0, y estos yo mismo los relleno asi(no creo que tengan espacios en blanco, per por si las dudas les pondre un trim), esos campos son varchar por que tambien son leidos por un procedimiento almacenado donde utilizo esta funcion Datediff(month,convert(char, @a+@mescppcompa+'01', 112), convert(char, @anocpp+convert(char(2), @mescpp)+'01', 112), y dicha funcion me pide los meses de esa manera, creo que acomode los datos para el procedimiento almacenado (mssql) y no me fije en los errores que podria causar en delphi, pero lo mas extraño de esto es que habia testeado la aplicacion y no me habia dado problemas hasta ayer.