Hola, quería pedir el final del 06/08/2013 Alguien lo tiene?

Muchas gracias!

   
   

Yo en el primero de SQL puse que no compilaba por el group by, que no acepta funciones.
En el segundo puse la opción c.

Me saqué un 7.. así que no sé qué hice bien o mal

Se pueden meter funciones en el group by, porque en este caso son columnas. Acabo de probar una consulta corta con el ISNULL y anda. Un amigo probó la consulta entera y dijo que compiló.

Yo dí este final

y el práctico es:

3A)la respuesta es la d

3B) la respuesta es la c

Saludos!

(07-08-2013 23:16)Anirus escribió:  Se pueden meter funciones en el group by, porque en este caso son columnas. Acabo de probar una consulta corta con el ISNULL y anda. Un amigo probó la consulta entera y dijo que compiló.

Yo probé la consulta entera y compiló, lo que no me cierra es el order by dia_detalle, 2 cuando decía: 'Ordenado por día de la semana (según su detalle)'

Hola Gente. Perdon por levantar un thread viejo. Pero estaba viendo este final y queria saber si el punto 3B), la respuesta es el item "e".
Pregunto esto porque como vi ahi arriba, MCS dijo que era la opcion c. pero no entiendo por qué. A mi me dio "0 1 0" en los Selects.

Gracias.
Saludos

hola luksenberglm, te cuento que yo tb ando preparando gestion para rendir el martes, te comento como lo plantié por que yo tb llegué a la opcion C.
en el tiempo 4 empieza tran2 en read commited.
en el tiempo 5 hace un insert
en el tiempo 6 hace un select,le devuelve el 1
en el tiempo 7 tran1 quiere hacer un select,pero tran2 lo lockea por que en read commited, para liberar la transaccion, tiene que commitear o rollbackear
en el tiempo 8 commitea el 1,entonces libera la transaccion(va,creo que lo estoy diciendo mal,no se si seria decir que libera la tabla)
y deja que tran1 haga el select que tenia en el punto 7,le devuelve un 1
en el tiempo 9 tran2 realiza un rollback,pero como no hizo ninguna operacion despues de commitear el 1, entonces no rollbackea nada
en el tiempo 10 tran1 realiza otro select y obtiene lo mismo,un 1
en tiempo 11 commitea y fin

---

de lo que veo de tu respuesta, vos primero estas ejecutando el select del tiempo 7 y por eso te devuelve un 0 como primer lectura de la tabla, ojo que el read uncommited lo lockea la tabla cuando comienza un begin tran, entonces deja que tran2 realice sus operaciones sin lockearlo,no se si se entiende

Disculpen que retome el tema, pero no seria la B? La transaccion 2 es READ COMMITED, lee solo valores comiteados y lo unico comiteado es que no hay 0. su insert todavia no esta comiteado por lo que leeria 0.
Saludos!

(22-02-2016 15:38)Alhasar escribió:  Disculpen que retome el tema, pero no seria la B? La transaccion 2 es READ COMMITED, lee solo valores comiteados y lo unico comiteado es que no hay 0. su insert todavia no esta comiteado por lo que leeria 0.
Saludos!

Si para mi tambien es la opcion B, porque todavia no esta commiteado el valor del insert, entonces la tabla esta vacia.

(17-12-2016 17:28)Milton Brandes escribió:  

(22-02-2016 15:38)Alhasar escribió:  Disculpen que retome el tema, pero no seria la B? La transaccion 2 es READ COMMITED, lee solo valores comiteados y lo unico comiteado es que no hay 0. su insert todavia no esta comiteado por lo que leeria 0.
Saludos!

Si para mi tambien es la opcion B, porque todavia no esta commiteado el valor del insert, entonces la tabla esta vacia.

El tema de READ COMMITED es que lee registros commiteados de otras transacciones, esa es propia, por ende debería poder verla.

Yo entiendo que es la respuesta "C".

Para el punto 3A la hubiera cagado de nuevo, pensé que era la respuesta "C" porque el right join me parecia que estaba mal...

No me termina de cerrar. Entiendo que read committed sea para otras transacciones, por eso TRAN2 (Tiempo 6) = 1. La única opción con esta posibilidad es c), salvo que fuera ninguna de las anteriores...

Pero me queda la duda con el Select del tiempo 7, según los PDF lo que dice rogerivan no ocurre en read committed sino que ocurriría en el modo repeatable read ("una operación de lectura (SELECT) establecerá bloqueos compartidos (shared locks) sobre los datos que está leyendo, y los mantendrá hasta el final de la transacción, garantizando así que no se produce lecturas no repetibles (non repeatable reads)"). Pero, no sé honestamente. Yo hubiera seleccionado alguna opción 1 / 0 / 1, en mi caso sería f), no termino de entender por qué la segunda es 1.

Es que la T1 no hace ninguna sentencia bloqueante para T2, ya que lo único que hace son lecturas de datos, justamente es el nivel que no bloquea nada.
Teniendo eso en cuenta, todo lo que las demás Transacciones modifiquen en el medio te lo va a leer (siempre) tal cual está la tabla en ese momento, hayan commiteado o no. Para este caso particular T1 lee justo 2 veces seguidas DESPUÉS de una modificación y muestra los mismos datos.

T2, en cambio, solo "pide" que si alguien le va a alterar datos que está a punto de leer, que se lo commiteen primero, sino freno y espero a que lo hagas.

Buah, sí, hice toda la deducción pensando en que la committed era la primera, por eso me parecía que su lectura era 0. Qué gil. Gracias.