Contar la cantidad de registros de un dbgrid

[Casimiro Noteví]

O sea, tú ejecutas un query, por ejemplo:

Código Delphi [-]
q.close;
q.sql.text = 'select codigo, nombre from tbClientes where provincia=28';
q.execquery;
showmessage(q.recordcount,"");

¿Eso muestra los registros que ha traido el query?

[edgargh]

Casimiro, por el uso de la propiedad execquery de tu ejemplo entiendo que utilizas un TIBSQL que se enfoca especificamente a Interbase, no es la manera estandar de trabajar con datasets en delphi, creo que ese es tu problema. Un TDataset no esta limitado a trabajar con un solo manejador de base de datos como interbase. por ejemplo si trabajas con Tdatasets de ADO o DBExpress, que segun yo son los mas comunes y en los cuales puedes hacer la conexion con una infinidad de manejadores de bases de datos (incluyendo interbase), no tendrias el problema que mencionas

[Casimiro Noteví]

Empezado por edgargh

Casimiro, por el uso de la propiedad execquery de tu ejemplo entiendo que utilizas un TIBSQL que se enfoca especificamente a Interbase, no es la manera estandar de trabajar con datasets en delphi, creo que ese es tu problema. Un TDataset no esta limitado a trabajar con un solo manejador de base de datos como interbase. por ejemplo si trabajas con Tdatasets de ADO o DBExpress, que segun yo son los mas comunes y en los cuales puedes hacer la conexion con una infinidad de manejadores de bases de datos (incluyendo interbase), no tendrias el problema que mencionas

Bueno, mejor dicho que no es tu forma de trabajar
Y en cuanto a lo estandar, lo mismo digo
Y además, yo no tengo ningún problema

[edgargh]

jaja, donde estas Neftali?, ayuda a este pobre hombre.

[Casimiro Noteví]

A ver, edgargh, un select a una base de datos devuelve una serie de registros, ¿cuántos?, no se puede saber. ¿Por qué el componente que tú estás usando, y otros también, pueden saberlo?, pues porque han añadido un contador. Pues la única manera de saber cuántos registros hay en una consulta es contarlos, para eso la única forma es hacer un fetch, o sea, ir al último.
Algunos añadidos en algunas bases de datos y componentes, han incorporado código para que cuando se están pasando los registros que ha devuelto la consulta, los vaya contando. Hay diversas maneras, tampoco voy a escribir un tratado de cómo se hace, pero no es lo normal.

[orodriguezca]

Casimiro tiene razón. Independiente del tipo de dataset con el que se haga la consulta, a menos que haga Fetch a todos los registros no hay forma de saber cuantos registros retornará la consulta.

Ahora, muchas veces los grids y algunos dataset, para mejorar el rendimiento, suelen recuperar la mayor cantidad posible de filas (en el caso del CXGrid todas las filas) para tenerlas disponibles tan pronto se ejecuta el Open de la consulta. En la mayoría de las ocasiones esto trae como consecuencia que "accidentalmente" todas las filas de la consulta son leídas por el cliente y el dato que obtenemos con Query1.RecordCount es correcto, pero la única forma de saber cuantas filas regresó nuestra consulta es leyéndolas todas, ya sea realizando un Query1.FetchAll o un Query1.Last.

[Casimiro Noteví]

Empezado por orodriguezca

..

Exactamente
Aunque no se hace por mejorar el rendimiento, ya que es justo lo contrario, esa forma es lo menos eficiente que existe para traerse datos de una consulta.
Se hace para "facilitar" el uso al usuario, como dices, los componentes que mencionas se trae todos, por defecto, para poder luego hacer filtros y cosas con ellos.
Evidentemente no es la forma correcta de trabajar, y mucho menos para trabajar por internet, ya que se trae todos los registros... ¿y si tienes millones de registros?, o sea, es un despropósito en cuanto a rendimiento.

[edgargh]

Empezado por orodriguezca

Casimiro tiene razón. Independiente del tipo de dataset con el que se haga la consulta, a menos que haga Fetch a todos los registros no hay forma de saber cuantos registros retornará la consulta.

Ahora, muchas veces los grids y algunos dataset, para mejorar el rendimiento, suelen recuperar la mayor cantidad posible de filas (en el caso del CXGrid todas las filas) para tenerlas disponibles tan pronto se ejecuta el Open de la consulta. En la mayoría de las ocasiones esto trae como consecuencia que "accidentalmente" todas las filas de la consulta son leídas por el cliente y el dato que obtenemos con Query1.RecordCount es correcto, pero la única forma de saber cuantas filas regresó nuestra consulta es leyéndolas todas, ya sea realizando un Query1.FetchAll o un Query1.Last.

Te consta lo que dices?, lo haz hecho con un adoquery por ejemplo?, no te ha funcionado el recordcount?

[edgargh]

Empezado por Casimiro Notevi

A ver, edgargh, un select a una base de datos devuelve una serie de registros, ¿cuántos?, no se puede saber. ¿Por qué el componente que tú estás usando, y otros también, pueden saberlo?, pues porque han añadido un contador. Pues la única manera de saber cuántos registros hay en una consulta es contarlos, para eso la única forma es hacer un fetch, o sea, ir al último.
Algunos añadidos en algunas bases de datos y componentes, han incorporado código para que cuando se están pasando los registros que ha devuelto la consulta, los vaya contando. Hay diversas maneras, tampoco voy a escribir un tratado de cómo se hace, pero no es lo normal.

Lo único que te puedo decir porque lo he hecho infinidad de veces y puedo demostrarlo con un ejemplo sencillo si gustas, es que si yo tengo un adoquery por ejemplo, puedo obtener el total de registros a través de la propiedad recordcount. No es algo que este inventando yo (No tengo tanta capacidad) esa es la función de esa propiedad. Desde mi punto de vista la propiedad last se utiliza para ir al ultimo registro no para obtener el total de registros, para eso es la propiedad recordcount de un tdataset y no tiene nada que ver con el manejador de base de datos.

Entiendo la parte de que cada quien puede hacerlo a su manera, pero no estoy de acuerdo que se diga que no funciona algo que me consta que si. Saludos

[orodriguezca]

edgargh tienes y no tienes razón. Te explico porque:

Cuando se crea un objeto de la clase TADOQuery por defecto la propiedad CursorLocation se establece a clUseClient. En esta modalidad ADO se comporta en forma "desconectada" y transfiere todas (absolutamente todas) las filas de la consulta al lado del cliente aunque no se haya hecho un FetchAll o un Last. Es por esto que funciona el RecordCount, porque ADO transfiere todas las filas al cliente y las va contando a medida que las va transfiriendo. Si la propiedad CursorLocation se establece a clUseServer las filas solo se transferirán al cliente bajo demanda, ya sea navegando en un Grid o haciendo uso de los métodos Next, Last o FetchAll.

Espero quede aclarado.

[Casimiro Noteví]

Desconozco cómo trabajan los componentes ADO que estás usando.
E insisto en que un query de consulta a una tabla no devuelve el número de registros que cumplen la condición, salvo que vayas al último.