Problema con TQuery.RecordCount

[[kuan-yiu]]

Hola a todos y gracias de antemano por vuestro tiempo.

Me acaba de aparecer un problema fantasma. Lo llamo así porque ayer no estaba y hoy me está volviendo loca.
Ejecuto una consulta, me aseguro que tiene datos y siempre que llego a la línea en la que está "RecordCount" me da -1.

Código Delphi [-]
  qinforme.Close;
  qinforme.Open;
//...
  if qinforme.IsEmpty then
    begin
      ShowMessage('No hay datos');
      exit;
    end;
//...
      ProgressBar1.Position:= 0;
      ProgressBar1.Min:= 0;
      ProgressBar1.Max:= qinforme.RecordCount;

He cambiado la consulta, para añadirle un nuevo campo, es todo lo que he hecho... salvo tecleos o borrados accidentales de los que no soy consciente (que me lo estoy planteando).

[[Lepe]]

RecordCount solo funciona con Paradox, el resto de BBDD no implementan dicha propiedad, ya que es un consumo elevado de recursos.

Si necesitas saber el número de registros, utiliza una consulta:

Código SQL [-]
select  Count(ClavePrimaria) from PioPio

Saludos

[[kuan-yiu]]

Empezado por Lepe

RecordCount solo funciona con Paradox, el resto de BBDD no implementan dicha propiedad, ya que es un consumo elevado de recursos.

Si necesitas saber el número de registros, utiliza una consulta:

Código SQL [-]
select  Count(ClavePrimaria) from PioPio

Saludos

Ya, eso he leído en la ayuda, pero lo gracioso es que esa función lo usa desde hace casi un año (con una BD Oracle9i) y no había fallado hasta hoy

Además después de volver a una versión anterior del formulario he descubierto que el error aparece cuando le añado el nuevo campo a la antigua consulta. Pero un cambio similar ya lo había hecho hace unas semanas y no me había dado estos problemas.
Si hubiese fallado siempre lo entendería, pero es que estoy haciendo pruebas y si le añado el nuevo campo que necesito a la consulta (un varchar de 1000) entonces RecordCount deja de funcionar y si se lo quito vuelve a funcionar

¿Tendrá algo que ver el inusual tamaño del campo con que falle de este modo?

[[Lepe]]

Podría ser.

Al menos lo veo lógico, Oracle es por algo el mejor SGBBDD, puede que estime los tiempos/recursos necesarios para calcular esa propiedad... si es demasiado, pues no lo hace (que conste que solo lo intuyo).

PD: Yo pensaba que no habías testeado esa parte, o bien no lo habías tenido en cuenta, ya veo gratamente que me equivocaba .

Saludos

[[kuan-yiu]]

He decidido cambiar esa línea de código, después de este misterioso fallo no me ofrece ninguna seguridad, así que la cambiaré por una consulta como la que sugieres.



PD:

Empezado por Lepe

[...]
PD: Yo pensaba que no habías testeado esa parte, o bien no lo habías tenido en cuenta, ya veo gratamente que me equivocaba .