Como guardar Maestro Detalles entorno de red

[guillotmarc]

Hola.

La forma en que te recomiendo hacerlo es :

Abrir Transacción
Guardar Encabezado
Guardar Detalles
Finalizar Transacción

Como decía en el mensaje anterior, las transacciones tienen que ser lo más cortas posibles. Tienes que diferenciar entre transacciones que solo consultan datos y transacciones que los modifican. Las transacciones que consultan datos pueden permanecer abiertas durante minutos, ya que no bloquean nada, pero las transacciones que modifican datos solo deberían existir durante unos milisegundos : se abre, modificas y cierras la transacción, puesto que los datos que modifiques van a estar bloqueados y no podrán ser modificados (NOTA: por eso tu problema mejora al poner COMMITS dentro del bucle, en ese momento estás liberando el bloqueo sobre el producto introducido).

Asi pues, si tienes transacciones para mostrar datos, las puedes dejar abiertas tanto tiempo como necesites. Pero si quieres modificar datos, tienes que abrir una nueva transacción, modificar los datos, y cerrarla en el menor tiempo posible.

NOTA: Esta es una de las razones que hacen tan recomendables los ClientDatasets : nunca dejan transacciones abiertas, cuando abres una tabla, abre una transacción, lee los datos y los copia en memoria local, y cierra la transacción. A partir de ese momento trabajas en la copia local que tienes de los datos (sin que exista ningún tipo de transacción abierta). En el momento en que guardas los cambios del ClientDataset, se abre una transacción, aplica los INSERTS o UPDATES para transmitir los cambios a la base de datos, e inmmediatemente cierra la transacción. Las probabilidades de encontrarte con deadlocks son ínfimas (y en caso de que ocurra, solo tienes que volver a guardar, ya que la transacción que te bloqueó inicialmente ya ha terminado seguro).

[Toni]

Hola compañeros,

Una pregunta Guillotmarc, entonces en una aplicacion grande en la que hay muchas consultas de datos (solo lectura) y entradas de datos varias, tu crees que seria necesario o aconsejable usar varios componentes de transacciones?

Es decir, tener un componente de transaccion para los clientdataset de solo lectura y otro componente de transaccion para los clientdataset de entrada modificacion de datos?

A todo esto, utilizo firebird+ibx+clientdataset.

Tal y como esta actualmente, todo con un solo componente TIBTransaction realmente a mi no me genera problemas, pero si realmente se puede mejorar o minimizar problemas me interesaria saberlo.



Saludos,

[guillotmarc]

Empezado por Toni

Hola compañeros,

Una pregunta Guillotmarc, entonces en una aplicacion grande en la que hay muchas consultas de datos (solo lectura) y entradas de datos varias, tu crees que seria necesario o aconsejable usar varios componentes de transacciones?

Es decir, tener un componente de transaccion para los clientdataset de solo lectura y otro componente de transaccion para los clientdataset de entrada modificacion de datos?

A todo esto, utilizo firebird+ibx+clientdataset.

Tal y como esta actualmente, todo con un solo componente TIBTransaction realmente a mi no me genera problemas, pero si realmente se puede mejorar o minimizar problemas me interesaria saberlo.



Saludos,

Hola Toni.

Si siempre utilizas componentes IBX+ClientDataset no hay ninguna necesidad de tener más de una transacción. Puesto que el ClientDataset nunca deja abierta la transacción. Solo la abre momentáneamente en el momento de cargar datos o en el momento de guardarlos, y la cierra inmediatamente. Nunca permanece abierta más de unos milisegundos.

Otra cosa es que utilizaras también componentes IBDataSet. Estos componentes requieren que la transacción esté abierta tanto tiempo como el Dataset permaneza abierto. En ese caso, mientras tengamos transacciones abiertas, sí que deberíamos tener diferentes transacciones, y ser muy cuidadosos de cuando se abren, se confirman, en que transacción se hacen los cambios, etc. ...

[Toni]

Muchas gracias por la respuesta Guillotmarc,

El tema de las transacciones como te comentaba realmente no me daba, era por estudiar si era conveniente reestructurar el proyecto. Pero ya me queda claro que no.

Lo que si me que da algun que otro quebradero de cabeza utilizando 'firebird+ibx+clientdataset' es al actualizar o modifcar algunas tablas, que da el mensaje este de que no encuentra el registro o otro usuario lo ha modificado. El problema es que no encuentra el registro sobre todo en las tablas que tienen un llave primaria de varios campos. (no pasa siempre, incluso rara vez)

Lo he podido solucionar 'temporalmente' en el caso de estas tablas creando los campos estaticos y definiendo que campos son los que forman parte de la llave primaria. Con esto se soluciona, pero me gustaria encontrar una solucion que me permita seguir utiizando los campos de forma 'dinamica', es decir que no esten estaticos en la aplicacion.

[guillotmarc]

Sí. Ese es un problema del ClientDataset, que debes tener los campos estáticos y debes definir cuales forman la clave primaria.

Yo como siempre creo los campos estáticos, no tengo problemas con ello.

En tu caso, quizás después de abrir el ClientDataset, puedes especificar por código quienes son los campos de clave primaria.

Es decir.

ClientDataset1.Open.
IBDataset1.FieldByName('CAMPO').ProviderFlags := IBDataset1.FieldByName('CAMPO').ProviderFlags + pfInKey;

Pero no sé si aun estarán disponibles los campos en el IBDataset, para poder marcarlos como los campos de clave primaria.

Saludos.

[rastafarey]

Tenias razon. De verdad tenia mucho timepo sin ver este error. Como nunca dejo transaciones pendientes. Tenia muchismo tiempo sin ver este error de bloqueo. Ya ni me acordaba que me dio mil dolores de cabezas en mis inicios de programdor. Normalmente no le dejo la tarea de actualizacion de datos a los db aware sera por eso que no se me han presentados los bloqueos.