Para manejar tablas grandes  he creado éste control al que he llamado pageGrid. Yo lo he probado con 600.000 registros contra una tabla MySQL y es prácticamente instantáneo con mi conexión lenta de internet (4mb).
En realidad es una derivación (que no una herencia) de el dbGridFilter que tenéis en los dbControles. Lo que he hecho ha sido paginar las consultas utilizando la clausula de SQL "Limit". Con eso da igual los miles de registros que tenga una tabla porque sólo se retona el número de filas especificadas en el valor de limit. Una vez hecha la consulta, se pasan los valores a un Variant[] que contiene un String[] por cada registro, y es sobre ese Variant[] que se rellena el Grid.

Le he puesto una pequeña base de datos sqlite para que funcione el ejemplo.

El aspecto es éste:
 
Como véis podéis moveros la cantidad de registros que establezcáis hacia delante, atrás, al final, al principio o a la página seleccionada.
Por supuesto se mantienen las capacidades de hacer filtros, búsquedas y ordenaciones, alto automático de fila, etc. que ya tenía dbGridfilter.
Lo he subido a la Granja con el nombre pageGrid
Espero que os sea útil.

===================
No podemos regresar

Me lo descargue, le voy a echar un vistazo.
Saludos.

shordi no sirve para odbc, porque en el evento data no puedes hacer MoveTo.. ya que el cursor es foward only en FReeTDS y muchos otros...

ya descarge y revise el codigo.. interesante lo que intentqaste hacer pero ahora explota con freetds... posteare que puedo encontrar

EXCEKENTE EL CONTROL! ah y conteste el correo con respuestas muy cortas

Citar:

shordi no sirve para odbc, porque en el evento data no puedes hacer MoveTo.. ya que el cursor es foward only en FReeTDS y muchos otros...

Cambiálo a MoveNext, entonces, usando la clase wgridfilter, que trabaja en ram.

===================
No podemos regresar

Citar:

Cambiálo a MoveNext, entonces, usando la clase wgridfilter, que trabaja en ram.

de esa el codigo es mas dificil de seguirte, ya lo voy probar, umm tengo mis dudas, ok apenas termine con algo de hardinfo pruebo..

sin embargo lo probe con sqlite, y parece ahora el problema es que aunque en una pc mas moderna del trabajo (me hiciste ir al trabajo hostias) tengo gabmas 3.9 explota igual.. estoy en estos momentos corriendo por pasitos... a ver donde

creo pude dar con el bug.. pero parece que nunca lo probaste realmente con odbc o siquiera mysql..

la busqueda saca el nombre de la tabla, del nombre de las columnas, y ya habia dicho que esto solo se cumple con sqlite.. para el resto de las DBMS cuando gambas coloca el nombre de las columnas lo hace como debe ser que es solo "<columna>" en vez de "<tabla>.<columna>".. por eso explota con otra cosa que no sea sqlite..


esto no se puede asumir muchisimo menos en odbc.. buena el truco para disernir entre varias tablas pero no funciona en odbc, mejor es remover desde $source el punto y tratar todas las columnas como que vienen correctamtne desde odbc

dspues de detectar la columna, y realizar la construccion al reves del query, intenta "re"-paginar.. aqui no pude seguir el codigo puesto ya llevaba un Error en el previa llamada de paginacion que no se porque no lo muestra.. pero en la segunda vez ocurre un aserction failed con este error:


its quite rare but only happened with lasted gambas, with gambas 3.5.1 does not happened, i search something for that and fgot unresolved things: https://groups.google.com/forum/#!topic/jenkinsci-users/R6ikq12KNDM

sin embargo cuando trate ver en "populate" veo el backtrace imprime :

Citar:

Error: Query failed: no such column: Countries.Capital: odbGrid.populate.186

y atrapa una excepcion, puesto asume las columnas y el query siempre es calificado, cuando no es asi, simplemente sqlite devuelve el nombre de la tabla como si fuera qualificado.. lo cual es un bug de sqlite que ya habia dicho..

esto hace que en grid_data no exista un result y explote

por mi mismo no puedo resolverlo, es una simple conjetura que realizo dado la documentacion obviamente esta en la cabeza de shordi ..

como solucion de lopoco que deduge es realizar la adaptacion a eliminar el bug que hereda de sqlite.. aunque me fue facil en wGrid & wGridfilter aqui no me es sencillo realizarlo..

adiciono me falto, esto no causa problemas pero es interesante que no encuente su propio nombre de columna si lo repite:

 

esto es mas extraño: si puedes revisarlo por favor y corregir que parte de mi anterior analisis estaba malo: porque no entiendo porque no encuentra una palabra que si existe segun el sql que construye a menos que mi analisis sea cierto

 

Citar:

creo pude dar con el bug.. pero parece que nunca lo probaste realmente con odbc o siquiera mysql..
la busqueda saca el nombre de la tabla, del nombre de las columnas, y ya habia dicho que esto solo se cumple con sqlite.. para el resto de las DBMS cuando gambas coloca el nombre de las columnas lo hace como debe ser que es solo "<columna>" en vez de "<tabla>.<columna>".. por eso explota con otra cosa que no sea sqlite..

Estas en un error, bueno en dos:

El primero es que el componente está probado con sqlite y con MySQL. En sqlite con varias bases de datos y en MySQL, con una conexión remota a un servidor y una línea de 4mb de ancho de banda contra una tabla con 25 campos y 600.000 registros. El resultado es casi instantáneo y sin problemas.

El segundo es que la busca no saca el nombre del nombre de las columnas. Estás obsesionado con eso que tú llamas un bug de sqlite. No es ningún bug de sqllite, pero no voy a entrar en ese tema ahora.

La busca saca el nombre del nombre de los campos...  como habrás podido ver en la llamada a la función donde esa línea reside (dbcomillas)


y la función se limita a poner las comillas inversas (o como se llamen) en los nombre de los campos: si el nombre del campo es direccion, esa función lo convierte en `direccion`. Si el nombre del campo es mitabla.direccion esta función lo convierte en `mitabla`.`direccion`
No hay ningún error por ese lado... salvo que tu base no admita el caracter ` como separador de nombres. Eso yo no lo puedo probar porque no tengo información sobre esa base de datos. Si no es así, pues sustitúyelo por el carácter que use.

El segundo bug que dices de la columna Capital no he podido reproducirlo. A mí me funciona perfectamente. A ver si puedes aislar la secuencia de acciones que te llevan a él y entonces podremos corregirlo.

Por otra parte he modificado el control para que sólo recorra el result una vez en modo forward only. Eso te permite (en teoría) trabajar directamente con él con la conexión odbc sin tu man in the middle. Pruébalo que yo no tengo acceso a ninguna base odbc y ahí toco de oído.

Está actualizado en la granja y en éste mismo hilo.

Saludos.

===================
No podemos regresar

ok entonces si lo probaste con mysql, yo lo probe con sybase y con db2, disculpame, me base en los resultados mios unicamente...


en la consulta esta no devuelve el nombre de la tabla en el nombre de los campos.. pero con sqlite ve te invito realices esta prueba:
a) si depuras el objeto Result de una consulta sqlite "select * from tabla" los campos se devuelven asi: "col1.tabla, col2.tabla"
b) si depuras el objeto Result de una consulta db2/sybase "select * from tabla" los campos se devuleven asi: "col1, col2"
c) inclusive si realizo "select tabla1.col1, tabla2.col2 from tabla1, tabla2" los campos en Result se devuelven asi: "col1, col2" incluso aunque las columnas sean iguales

shordi escribió: [Ver mensaje]

El segundo bug que dices de la columna Capital no he podido reproducirlo. A mí me funciona perfectamente. A ver si puedes aislar la secuencia de acciones que te llevan a él y entonces podremos corregirlo.

Por otra parte he modificado el control para que sólo recorra el result una vez en modo forward only. Eso te permite (en teoría) trabajar directamente con él con la conexión odbc sin tu man in the middle. Pruébalo que yo no tengo acceso a ninguna base odbc y ahí toco de oído.

Está actualizado en la granja y en éste mismo hilo.

Saludos.

El bug lo reproduzco solo en linux embebidos.. con glibc 2.25 sin embargo la misma combinacion pero sin usar gambas 3.9 sino usando 3.5 logro ejecutarlo.. es lo extraño

voy a probar con tu modificacion a ver que pasa.. espero me ayude..

Citar:

) si depuras el objeto Result de una consulta sqlite "select * from tabla" los campos se devuelven asi: "col1.tabla, col2.tabla"

Efectivamente es así. Pero no es un bug, es el comportamiento de sqlite. Si quieres que un campo se llame como tú quieres en una consulta, debes ponerle un alias (cláusula AS)
Lo tienes en la documentación de sqlite.

Citar:

If the columns of your result set are named by AS clauses, then SQLite is guaranteed to use the identifier to the right of the AS keyword as the column name. If the result set does not use an AS clause, then SQLite is free to name the column anything it wants. See the sqlite3_column_name() documentation for further information.

Y en el sqlite3_column_name() dice:

Citar:

The name of a result column is the value of the "AS" clause for that column, if there is an AS clause. If there is no AS clause then the name of the column is unspecified and may change from one release of SQLite to the next.

Es decir, si no quieres la referencia de las tablas tienes que usar: "select col1 as 'col1', col2 as 'col2' from tabla"
Así es como se comporta Sqlite. Sqlite tiene unas magníficas ayudas on-line y eso es lo primero que uno debe leer cuando decide utilizar una base de datos. Lanzarse a gritar "BUG" cada vez que algo no se comporta según lo que uno espera, a menudo nos deja en evidencia.

Saludos.

===================
No podemos regresar