Asesoramiento: ¿Tablas temporales, datos en memoria...?

[[kuan-yiu]]

Empezado por Héctor Randolph

Hola kuan-yiu!

Con respecto al tema de no tener tanto tiempo abierta una transacción, leí hace poco una solución propuesta por Lepe en este hilo que se refiere a los ClientsDataset con cacheUpdates (consigues el efecto que una tabla temporal).

Te dejo un enlace con un ejemplo:


ClientDataSet y DataSetProvider en aplicaciones cliente/servidor

Saludos

mmm... Cierto, cierto, no se me había ocurrido...
(Pero voy a tener que reescribir la mitad de la aplicación porque el que lo hizo ni usaba DataModule ni UpdateSQL ni nada de nada.)

[roman]

Vamos a ver, que no soy experto en el tema así que más es pregunta que respuesta. ¿Exactamente, en este caso, cuál sería el problema de dejar una transacción abierta? No estamos hablando de dejar bloqueos de tablas activos. Dependiendo, según entiendo, del nivel de aislamiento de la transacción, los otros clientes pueden continuar su trabajo. Cualquier cosa que haya que deshacer con la transacción también ha de deshacerse con el uso de tablas temporales. No digo que no convenga usar ClientDataSets, y posiblemente sea lo más adecuado, pero tampoco me queda claro el porqué afecta una transacción abierta. Pero como dije, es más pregunta que respuesta.

// Saludos

[[kuan-yiu]]

Empezado por roman

Vamos a ver, que no soy experto en el tema así que más es pregunta que respuesta. ¿Exactamente, en este caso, cuál sería el problema de dejar una transacción abierta? No estamos hablando de dejar bloqueos de tablas activos. Dependiendo, según entiendo, del nivel de aislamiento de la transacción, los otros clientes pueden continuar su trabajo. Cualquier cosa que haya que deshacer con la transacción también ha de deshacerse con el uso de tablas temporales. No digo que no convenga usar ClientDataSets, y posiblemente sea lo más adecuado, pero tampoco me queda claro el porqué afecta una transacción abierta. Pero como dije, es más pregunta que respuesta.

// Saludos

Yo tampoco lo tengo muy claro, pero siempre me han insistido en que las transacciones tienen que durar el menor tiempo posible... Y yo me fío de quien me lo dijo.

El problema radica, creo yo, en un mal diseño inicial de la aplicación que ahora está dando muchos fallos y tengo que remendar de algún modo (usa 6 formularios diferentes durante todo el proceso, muchos de ellos de consulta y hay decenas de lugares en los que puede cancelar el proceso a media grabación produciendo los más variados desastres).
Así que lo que yo pretendo es unificar la grabación física en un único punto, al finalizar todo el proceso, para hacerla más robusta.Aunque tal vez esa tampoco sea la mejor solución.

[mamcx]

Quizas por problemas de atomicidad... mientras esta el proceso otros pueden modificar los datos de base, lo que implica que para proteger el proceso se deberia de aislar la transaccion.

Si el proceso es de mucho tiempo, las transacciones no necesariamente es lo mejor.

[roman]

Entiendo esto, pero si el que otros usuarios hagan modificaciones durante la transacción es algo que pueda afectar en este caso, pues lo mismo sucedería con las tablas en memoria ¿no?

// Saludos

[[kuan-yiu]]

El proceso dura mucho, demasiado, es el típico proceso:

Vendedor: ¿Qué desea?
Cliente: Esto... no, mejor esto...
Vendedor: ¿Así?
Cliente: No, no, vuelva atrás para ver que es lo que llevo...

O sea que puede ser rapídisimo o durar casi una hora.
El problema fundamental es que tengo que insertar cosas y luego consultar esos mismos datos... me estoy volviendo loca , estoy a punto de tirarlo todo y volver a hacerlo.

Estoy tentada de llenarlo todo de flags y de montones de mensajes de aviso y de mega-funciones-de-borrado-en-masa...