error con encodedate en delphi 7
 

buenas tardes compañeros estoy utilizando esta funcion para formar fechas que extraigo de mi bd, todo funciona bien hasta que en ocasiones llega el mes numero 11 y al parecer la comparacion truena.

el valor de las variables son:

a m d tipo word
2012 1 1


ano mes d tipo ano, mes vienen de la base de datos son varchar; d word
2011 09 1
2011 10 1
2011 11 1

Código Delphi [-]
   i3:=0;
   seleccion3:=0;
   seleccion3:=Qry_cuotas.RecordCount;  
   Qry_cuotas.First;
   while i3 < seleccion3 do
   begin
      if encodedate(StrToInt(Qry_cuotas.fieldbyname('ano').Value), StrToInt(Qry_cuotas.fieldbyname('mes').Value), dia)<=encodedate(a, m, dia) then  <---
      begin

este es el error que me marca

---------------------------
Proposunidpr
---------------------------
Access violation at address 40002540 in module 'rtl70.bpl'. Write of address 000000E3.
---------------------------
Aceptar
---------------------------

alguna idea de que esl o que pueda estar pasando??, gracias pr cualquier comentario

Hola richy08.

Como parecía a primera vista, reproduje tu código y funciona correctamente en Delphi 7.

Te paso estos enlaces con la esperanza que alguno te de la solución...

• rtl70.bpl
• Access Violation at address 40006B33 in module 'rtl70.bpl'
• Delphi IDE - Access violation in module 'rtl70.bpl'
• Access violation in module 'rtl70.bpl'

Lo que pude apreciar que muchos atribuían la excepción a bugs de componentes de terceros.

Hay más enlaces pero están más orientados a errores que reciben los usuarios de aplicaciónes ya en funcionamiento.

Un saludo.

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.

¡¡¡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.

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.

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.

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

gracias eficsa le voy a echar un ojo a estos enlaces, pregunta sera posible que por alguna razon se halla dañado el proyecto en si y por eso marque el error??

pues como siempre tenian toda la razon :D, el error venia de otro lado para ser exacto del Qry_recargos, este es el codigo que tenia dentro este query

Código Delphi [-]
select idint,  tmesope, interes, mes, cpp, ano, cierremes, cierreano,
cerrado, pagado, cadena from interescpp 
where  acode= :acode 
and pagado='N'  
order by ano,  mes

lo cambie por y ya funciono

Código Delphi [-]

select idint,  tmesope, interes, mes, cpp, ano, cierremes, cierreano,
cerrado, pagado, cadena from interescpp 
where  acode= :acode 
and pagado='N'  
order by cast(ano as int), cast(mes as int)

una ultima pregunta, la mejor manera de borrar el contenido de un arreglo dinamico es esta??

Código Delphi [-]

var
cambios : array of integer;
.
.
.
if length(cambios)>0 then
            cambios := nil;

muchas gracias a los tres

Por favor, preguntas distintas en hilos distintos, debes crear un nuevo tema, tal y como indica nuestra guía de estilo, gracias por tu colaboración.

Y por cierto, que el problema estuviese en otro sitio, eso no quita todo lo que te hemos comentado sobre esa parte del código ;)

gracias casimiro, si ya los tome en cuenta y y anexe algunas partes mas a ese codigo, es que todavia lo tengo en face de pruebas y la pregunta la puse en el mismo lugar por que las uso en el mismo proceso, pero abrire otro hilo


mil gracias por todo