Velocidad en ADO con Access

[mazinger]

Utilizo ADO sobre una base de datos en Access 2000, concretamente utilizado el BetterADODataset derivado del ADODataset original. Mi problema consiste en que el simple hecho de abrir una tabla supone una demora de tiempo proporcional a la cantidad de registros que incluye.
Me explico. si la table tiene 15-20 registros la apertura es inmediata, si la tabla se acerca a unos 150 registros la demora puede ser de 15 segundos (según el ordenador). No modifico ninguna de las propiedades originales, y probando a modificar algunas para buscar más velocidad no noto diferencias significativas.

¿Que propiedades ADO tendría que modificar para conseguir esa velocidad que sería aceptable?

Gracias por anticiapado

[Neftali [Germán.Estévez]]

Yo probaría a utilizar el componente estandard, aunqe sólo sea para descartar que sea el BetterADODataset.

Empezado por mazinger

...si la table tiene 15-20 registros la apertura es inmediata, si la tabla se acerca a unos 150 registros la demora puede ser de 15 segundos (según el ordenador).

En principio y aun sin saber más datos, te puedo decir que éstos datos no son ni mucho menos normales. Está claro que hay algun problema; Y no debería ser así aunque sea con las propiedades por defecto del componente.

¿La tabla Access está en local o en Red?
¿La anchura de la tabla de cuantos campos es?

[mazinger]

Trabajo con varias tablas, y a todas les ocurre lo mismo. Unas tienen más campos otras menos. He probado con ADODataset y el resultado es el mismo. Si trabajo en red, el tiempo es casi el mismo, la conexión de red funciona unas décimas de segundo al trasferir datos, pero luego todavia tarda un rato en mostrar la ventana de datos. El procesador en ese tiempo trabaja al 100% (es un AMD 2000 MHz)

[Neftali [Germán.Estévez]]

Revisa actualizaciones de Delphi que puedas tener pendientes.
Actualiza la versión de las MDAC que tengas en tu sistema.

Yo probaría a crear un ejecutable que sólo te haga eso (abrir la tabla) y lo provaría en otros ordenadores a los que puedas tener acceso (aunque sólo sea para descartar que sea problema de la máquina).

[hgiacobone]

Varios colegas me comentaron que le ha pasado lo mismo. Dicen que en desarrollos con grandes cantidades de vulumen (una table de 1000 registros y una docena de campos) tarda cerca de 30 Min. hacer un Post.

¿Pudiste solucionarlo, Como?

[marcoszorrilla]

Yako supongo que te has equivocado, grandes cantidades de registros 1000 registros, con 80.000 a 100.000 el mismísimo Paradox se mueve sin ningún problema y eso que no es cliente/Servidor.

Yo últimamente no trabajo mucho con Access, me refiero desde programación, pero he movido 50 a 60 mil registros sin ningún problema, así que me extraña mucho lo que está pasando, yo cambiaría de componente.

Un Saludo.

[hgiacobone]

Empezado por marcoszorrilla

Yako supongo que te has equivocado, grandes cantidades de registros 1000 registros, con 80.000 a 100.000 el mismísimo Paradox se mueve sin ningún problema y eso que no es cliente/Servidor.

Lamentablemento no me he equivocado.
Una miseria de 1000 registrios se ha vuelto un problema. Nadie sabe el por qué, pero las consultas empiezan a demorar exponencialmente a medida que crecen las tablas.
Supongo que mucho se debe a falta de dicación al diseño.
Un consejo que les dí, es que a modo de "Store Procedures" almacenen las consultas SQL "dentro" del archivo MDB (por ejemplo el listado de Clientes) y que la ejecuten con un llamado. Tambien había que analizar la cadena utilizada en los SELECT... los Gurus prohiben cosas como "SELECT * FROM..."

Yo últimamente no trabajo mucho con Access, me refiero desde programación, pero he movido 50 a 60 mil registros sin ningún problema, así que me extraña mucho lo que está pasando, yo cambiaría de componente.
Un Saludo.

En verdad es así.
Pienso que con los componentes nativos ADO, mas el plus de la libreria ADOX, es suficiente para dignarse a trabajar con MS-Access, ya que no merce más esfuerzo.
O sea, se me ocurtre que si la solución que uno espera te lleva a utilizar componentes mas complejos o con mas prestaciones, es que estás necesitando otro tipo de motor y no otro tipo de componentes.

Yo ahora estoy peléandome con Delphi+ADO+MS-Access pero mas por diversión que por necesidad, pero es otro tema que después se los comentaré en un futuro Post.
Saludos amigos,

[marcoszorrilla]

Pues nada nos volvemos a Clipper.

Un Saludo.

[Neftali [Germán.Estévez]]

Empezado por hgiacobone

Una miseria de 1000 registrios se ha vuelto un problema. Nadie sabe el por qué, pero las consultas empiezan a demorar exponencialmente a medida que crecen las tablas.

¡¡¡No puede ser!!! 1000 registros = 30 minutos, ¡¡Pero si voy yo más rápido escribiendo con el boli!!!!

Está claro que eso no es un error del componente, ni un error de ADO, ni un error de Delphi, ni siquiera un error de diseño. Aun diseñando mal a conciencia, no se me ocurre como hacer para que un Post tarde ese tiempo.
Yo comenzaría a mirar otros problemas (Hard). Personalmente he trabajado con Access+ADO+D5/D6 y hombre, no es que sea un cohete, pero funciona bien, incluso a través de red.
Esos tiempos denotan un problema mas allá de éstos componentes.

* Si estás trabajando en Red, yo descartaría problemas entre ordenadores o con la red probando en un único ordenador.
* Si estás con un sólo ordenador, yo haría pruebas en otro, para descartar problemas con los discos, virus, memoria,....
* Probaría eliminando todos los programas en ejecución (pensando en antivirus y demás...)
* Probaría a crear una nueva Base de Datos en Access e importar los datos de la existente, para descartar problemas con una Base de Datos corrupta (entra dentro de lo problable, aunque no es habitual).
* probaría a realizar un INSERT utilizando un ADOQuery, con SQL, para descartar que sea el ADOTable.

[Ryu]

Digamos que mi tabla tiene 1000 o 30000 registro
si yo lo que deseo es actualizar un campo no es necesario abrirla con todos los
registros sino con aquellos registros que me interesan.

por ejemplo no es lo mismo abrir adodataset con la siguiente consulta

select * from tabla

que abrirlo con

select * from tabla where campo = parametro

Por lo al momento de actualizar solo actualiza o guada los cambios hechos en esa consulta.

Ademas cual es la necesidad de abrir la tabla con todos los registros?
realmente no entiendo por que traerlo todos si puedes
consultar y traer lo que realmente te interesa .

[marcoszorrilla]

Las afirmaciones que haces son válidas para bases de datos Cliente/Servidor pero las bases de escritorio hagas lo que hagas te cargas con todos los registros y además la mayoría no utilizan ni siquiera los índices en las consultas.

Un Saludo.

[Delfino]

Sospecho q el problema tiene q ver con la configuracion material de la red, si tu red tiene un switch asegurate de lo siguiente :

- q la configuracion en cuanto a dos parametros sea la misma en el switch y en los PCs, estos parametros son el duplex mode, si es half en el switch tiene q serlo en las tarjetas de TODOS los PCs, si no es half ponla a half tu mismo o pon AutoDetect en el switch y TODOS los PCs, el segundo parametro es la velocidad de la red Si es 10MB/s tiene q ser en TODOS, si es 100MB/s tambien, o pon AutoDetect.

Espero te sirva..