Cita:
|
Empezado por roman
¿por qué no sustituyes select * por select count(*) en tu consulta?
|
Aun mejor si utilizas para el Count el campo de clave primaria, es decir
Select Count(CampoPK)... (el resto de la consulta igual que estaba)
Cita:
|
Empezado por Jose Manuel
la consulta que pueda hacer un cliente no sea tan grande que colapse la red, por ejemplo que ¿pasaría si la consulta devuelve 50000 registros?
|
Has pensado en utilizar Filtros previos o TOP;
Personalmente considero que hacer (o que el usuario haga) una consulta que devuelve 50000 registros
es inútil; y lo subrayo porque además de inútil lo considero un
"error" de programación; Resulta que el usuario hace una consulta (en un Grid por ejemplo) que devueve 50000 registros y el registro que le interesa está en la posición 14356, ¿realmente lo va a encontrar? ¿Realmente lo va a buscar? porque no me imagino un usuario dándole al cursor o a la barra de desplazamiento hasta esa posición.
Creo que en éstos casos se debería sacar un
filtro previo para que el usuario seleccione determinados valores y utilizar
un TOP (yo utilizao ambas cosas, al igual que SAP, por ejemplo); El top por defecto son 500 (aunque el usuario puede modificarlo);
NOTA: Normalmente en un tabla grande suele ser más rápido un TOP 200 que un Count (ya que el count, aunque sólo sea para contar debe recorrer toda la tabla...)
Cita:
|
Empezado por Jose Manuel
¿que pasaría si la consulta devuelve 50000 registros?
|
(si al final y después de todo llegas a esa situación...)
Para esos casos debes configurar la conexión como Cliente-Servidor; ADO, IBExpress,... poseen alguna propiedad en la conexión que te permite configurar ésta modalidad de forma que en una consulta de 50000 registros se "traen" por bloques, primero se traen 250 y a medida que el usuario pide más (baja en el Grid, por ejemplo) se van trayendo el resto.
De todas formas mi consejo es que evites a todas costa llegar a esa situación (ejecutar ésta un select con un resultado de 50000 registros).