el culpable de la lentitud en los browse es la funcion ordkeycount, la cual para obtener su valor de retorno tiene que recorrer todo el cursor.
y para remate el bloque de codigo bkeyCount en xbrowse que es el responsable de obtener el valor de cuantos registros tiene el browse, se ejecuta cada tanto.
haciendo la presentacion de un browse extremadamente lenta.
es por ello que en los grid de delphi, de forma estandar el scrollbar vertical no es funcional completamente, solo funciona el movimiento hacia el inicio y hacia el final.
(TOP y BOTTOM) y el thumbnail esta siempre al centro, no funciona desplazar el thumbnal hacia arriba o abajo. (SKIP 1 o SKIP -1) esto para no estar calculando la posicion relativa del cursor y posicionar el thumbnail en la posicion correcta, ya que para hacer esto necesitaria estar costantemente calculando cuantos registros hay (llamando a adskeycount por supuesto) y cualcular la pos relativa, esto es por lo cual los grid en delphi dan la apariencia de ser rapidos con ads, la verdad es que para ambientes cliente servidor la funcion adskeycount se debe evitar como a la peste bubonica.
lo que habria que hacer es modificar los browse de fwh para que tengan el comportamiento similar al de delphi.
esto lo he deducido viendo arc, y un poco con el poco ingles que entiendo leyendo el help de ads.
asi que no es una ley que aparecio en la biblia.
, puedo estar muy equivocado.
salu2
carlos vargas