Problema DBExpress muy lento

[guillotmarc]

Hola.

La verdad es que no me extraña. Tienes que pensar en la forma de trabajar del ClientDataset.

Se mantiene en memória una copia local de todos los datos del Dataset. En tu caso, con unos registros que ocuparan unos 4080 bytes (es un cálculo aproximado), estamos hablando de más de 600 Mb. de memória RAM (para 170.000 registros). Así que es natural que se pueda quedar colgado.

Tienes que cambiar de enfoque. Por ejplo. puedes vaciar el ClientDataset cada 1000 registros, cerrandolo y volviendolo a abrir vacío (para ello debe tener una cláusula where del tipo codigo = -1).

Aunque personalmente, en este tipo de importaciones masivas, prefiero utilizar directamente el SQLQuery con sentencias INSERT INTO. Nota: Igualmente puedes definir una transacción, para que solo cada 1000 registros se realize un Commit.

Saludos.

[argami]

Gracias por contestar tan rapido varias cosas que me haz dicho:

Empezado por guillotmarc

Tienes que cambiar de enfoque.

Tienes toda la razón pero con lo que me dices hay cosas que no tengo tan claras ejemplo:

Empezado por guillotmarc

Por ejplo. puedes vaciar el ClientDataset cada 1000 registros, cerrandolo y volviendolo a abrir vacío (para ello debe tener una cláusula where del tipo codigo = -1).

He echo esta prueba y me resulta en lo mismo no me ayuda en nada.

Empezado por guillotmarc

Aunque personalmente, en este tipo de importaciones masivas, prefiero utilizar directamente el SQLQuery con sentencias INSERT INTO.

Tienes razon y van muy rapido pero el planteamiento de programa es en 3 capas
1- Datos (DBExpress)
2- Accesso (TClientDataSet, TDataSetProvider)
3- Pantallas

Por lo cual el acceso desde las pantallas es solo a travez de los client dataset y los providers. por lo que me surge la duda de como hacer cuando no sea una modificacion masiva si no mas bien un acceso solo para pasar por ejemplo un movimiento a un histrorico de 500000 registros

Empezado por guillotmarc

Nota: Igualmente puedes definir una transacción, para que solo cada 1000 registros se realize un Commit.

Esto me gustaria que me lo explicaras porque trabajando con dbexpress no veo como hacer lo de la transaccion (si estuviera con IBComponents no diria nada)

En todo caso te estoy agradecido por ttu ayuda y si pudieras tu o alguien mas ayudarme tambien lo agradeceria.


Saludos.

[guillotmarc]

Hola.

Empezado por argami

He echo esta prueba y me resulta en lo mismo no me ayuda en nada.

El SQLQuery debe tener : select * from tabla where codigo = -1

Entonces cuando aplicas los cambios (cada 1000 registros), debes abrir un clientdataset vacío :

Código Delphi [-]
    if J = 1000 then begin
     CDSMenor.ApplyUpdates(-1);
     J:=0;
     CDSMenor.Close;
     CDSMenor.Open; // El ClientDataset no tendrá ningún registro

NOTA: Si miras el consumo de memória de tu aplicación, deberias observar como ahora se mantiene constante.

Empezado por argami

Tienes razon y van muy rapido pero el planteamiento de programa es en 3 capas
1- Datos (DBExpress)
2- Accesso (TClientDataSet, TDataSetProvider)
3- Pantallas

Por lo cual el acceso desde las pantallas es solo a travez de los client dataset y los providers. por lo que me surge la duda de como hacer cuando no sea una modificacion masiva si no mas bien un acceso solo para pasar por ejemplo un movimiento a un histrorico de 500000 registros

Aunque nunca he utilizado el ClientDataset de esta forma, creo que puedes poner una sentencia INSERT INTO en el CommandText del ClientDataset, y ejecutarla mediante el Execute (y no el ApplyUpdates).

Empezado por argami

Esto me gustaria que me lo explicaras porque trabajando con dbexpress no veo como hacer lo de la transaccion (si estuviera con IBComponents no diria nada)

Puedes manejar transacciones en los componentes dbExpress. Es decir el SQLConnection tiene los métodos BeginTrans y CommitTrans. Dado que puedes tener más de una transacción abierta para la misma conexión, deberias consultar su sintaxis en la ayuda de Delphi. Esta transacción, mientras esté abierta, afectará a todos los componentes dbExpress que se ejecuten (SQLQuerys, SQLStoredProcs, ...).

NOTA: En la capa de cliente (los ClientDatasets) no sé que se puedan manejar transacciones.

Saludos.

[ruina]

En realidad en 3 capas nuca te deberias encontrar en el caso de tener que programar un movimiento de 500k registros en el cliente, ya que el cliente simplemente deberia hacer una petición a la capa intermedia de "mueveme 500k registros" y ahi donde puedes usar accesos "directos".

A la aplicación servidora se le carga bien bien de procedimientos remotos y está hecho, que quieres "abrir caja" -> procedimiento remoto, que quieres "mover a historico" -> procedimiento remoto, que quieres consultar la hora -> procedimiento remoto (bueno, en realidad nunca sabes si el ordenador cliente tiene la fecha bien puesta)

El uso del clientdataset es completamente distinto a las tradicionales Tables del BDE, un cliente solo deberia tener los records que necesita para trabajar y nunca, o casi nunca, todos los registros de la tabla subyacente.

por ejemplo, en una aplicación tradicional tu plantarias un grid con todos los artículos y esperarias a que el usuario pinche en alguno para modificar/ver o le dé a las opciones que hacen el locate.
En una aplicación 3 capas deberias preguntar antes al usuario que artículos quiere, y filtrar los que coincidan. Si elije "todos" ya sabe a lo que se expone, a traerse equismil registros por la red a su ordenador.
Si elije "articulos que empiecen por BAR", se le sirve el codigo, descripción y stock (por ejemplo) de esos artículos exclusivamente.

En 3 capas no es que no se pueda trabajar con transacciones en los clientes (se me ocurren un par de métodos trasgresores), es que no se DEBE, ya que las actualizaciones ya son lo suficientemente atómicas (osea, pequeñas).
Olvidate del tipo que le da a "nuevo pedido" y se va a tomar un café dejandote la transación abierta... ahora el buen hombre dejará su pedido a medias y cuando vuelva y lo complete se lanzará al servidor todos los cambios, si su pedido ya no es válido porque el café ha sido demasiado largo y no queda stock se resolverá en la capa servidora, obteniendo un bonito mensaje de error (o un formulario de resolución, que, realmente, es la pesadilla de cualquier usuario que no se lee el manual)


Realmente programando con esta mentalidad se consigue mas velocidad, ya que deberia funcionar incluso con poco ancho de banda (tengo incluso una appicación 3 capas corriendo sobre RDSI).


Eso si, el enfoque es completamente distinto y cuesta verlo (al menos a mi me costo lo suyo)
Recomiendo "la cara oculta de delphi" (ian marteens) como libro de cabecera... insisto en que no me llevo comisión (creo que es el tercer post en el que pongo esto, a este paso me cambian el nick a Amazon)