FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Select y Transacciones
Desde hace algun tiempo tengo esta duda:
¿ Se requieren transacciones para las consultas con "Select" ? Porque cuando trabajo, generalmente defino en el data module sólo 2 transacciones una Read Commited y otra Read_Write Table Stability, entonces asigno la "Read Commited" para todas las querys (MDOQuery) con select (sin usar StartTransacction ni commit) y la segunda para todas las actualizaciones (Insert, Update y Delete), iniciando la transacción justo antes del execSQL y ejecutando el commit inmediatamente despues. Lo que sí hago es usar algo así (en los Select):
y en las actualizaciones:
¿ debo iniciar y finalizar transacciones para los accesos de sólo lectura ? D7 + FB2 + MDO Gracias
__________________
Sitrico |
#2
|
|||
|
|||
Como usas un Modo Read_Commited para las transacciones de solo lectura no necesitas abrirlas y cerrarlas, ya que esa transaccion vera las modificaciones confirmadas sin necesidad de abrirla y cerrarla.
Otra cosa seria que usases transacciones en modo snapshot table stability en las de lecturas, en ese caso tendrias que cerrarla y abrirla porque sino nunca veria las modificaciones de la base de datos realizadas posteriormente a su apertura. Saludos |
#3
|
|||
|
|||
Las transacciones son metodo para garantizar la integridad de nuestos datos en caso de ocurrir alguna problema al momento de realizar alguna transformacion de los datos, cuando haces un select no puede decirse que transformas datos pues solamente se crea una vista de las tuplas pero estas quedan intactas, entonces no es necesaria la transaccion.
Si me equivoco por favor de correjirme lo antes posible por que tengo mucho que correjir entonces |
#4
|
||||
|
||||
Cita:
Cita:
__________________
Sitrico |
#5
|
|||
|
|||
Cita:
Tipos de transacciones: READ COMMITED ( RECORD VERSION ) Solo se ven los datos confirmados por otras transacciones, los datos que esten modificados por otras transacciones en curso no existen y se devuelve la ultima version confirmada de los datos. READ COMMITED (NO RECORD VERSION) Como la anterior solo se ven los datos confirmados por otras transacciones, pero si datos que es necesario leer han sido modificado por otras transaccions todavia no confirmadas, antes de leer estos datos, se espera a que esas otras transacciones se confirmen o cancelen, para tener asi los datos mas recientes posibles. Esto puede dar lugar a un interbloqueo y que la lectura falle por timeout en el caso de que otra transaccion que ha modificado datos que queremos leer, no finalice o tarde muchisimo en confirmarse o cancelarse. El tipo de transaccion anterior (RECORD VERSION) nunca tiene este problema ya que siempre devolvera los ultimos datos seguros aunque no necesariamente los mas recientes. SNAPSHOT Si leemos los datos con un transaccion tipo snapshot, no veremos ningun dato modificado posteriormente a la apertura de nuestra transaccion de lectura. Esto es como sacar una foto fija de la base de datos, tal cual estaba justo en el momento que se inicio la transacion, esto es util para generar informes y que estos sean coherentes, y no les afecten modificaciones de datos que se esten produciendo en el medio del calculo de los informes. Como se puede ver segun el tipo de transaccion asociada a la lectura de informacion, los datos leidos pueden ser completamente diferentes. Saludos Última edición por Mick fecha: 03-07-2007 a las 10:37:16. |
#6
|
|||
|
|||
Cita:
Ya que la lectura de datos se hace en unos pocos milisegundos de modo que los datos leidos seran los mismos en el 99% de los casos, sea una transaccion tipo snapshot o read commited. Saludos |
#7
|
||||
|
||||
Bueno Mick, Me queda poco claro lo que comentas de las transacciones, (hablemos de las transacciones de solo lectura) esto fue lo que te entendí:
Cita:
Si hago varias consultas, en diferentes momentos, dentro de una misma transacción, se mostrarán los datos confirmados (con commit) actualizados Cita:
Cita:
__________________
Sitrico |
#8
|
|||
|
|||
Me he liado un poco al explicarlo por falta de tiempo al redactar las respuestas, pero lo has entendido y resumido perfectamente XD.
Saludos Última edición por Mick fecha: 03-07-2007 a las 21:36:09. |
#9
|
|||
|
|||
yo practiicamente solo manejo mysql , pero me parecio muy interesante y util la forma en que firebird maneja las transacciones, muchas gracias por el dato
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Problema conuna consulta select...not in (select ...) | VRO | Firebird e Interbase | 2 | 11-08-2005 08:56:35 |
5 select de 5 tablas diferentes en un select solo | sakuragi | SQL | 6 | 15-06-2005 18:57:06 |
Select con Transacciones | Ana Tudela | Firebird e Interbase | 1 | 08-04-2005 16:48:00 |
Select anidado: Select from (select....) | Malon | SQL | 2 | 14-10-2004 14:01:24 |
Select anidado ( Select from select ) | Malon | Firebird e Interbase | 1 | 05-10-2004 04:14:38 |
|