pero lo que fallaria en ese caso no seria unicamente la sesion 2? no entiendo porque fallaria los count de la sesion 1

Gente, no sé por qué marcan que hay un error de sintaxis. La sintaxis de INSERT INTO SELECT en SQL SERVER es perfectamente válida.

 

CREATE TABLE prueba (

  col1 int

  );



SELECT * FROM prueba;



INSERT INTO prueba (col1)

(SELECT count(col1) + 1 FROM prueba);



SELECT * FROM prueba;

En el primer SELECT no devuelve nada, en el segundo devuelve 1.

Lo que yo argumentaría en este punto es que, basandonos en la suposición de que estamos en SQL SERVER, el isolation level por defecto es READ COMMITTED. Ergo, Tran1 garantiza evitar Dirty Reads. Al commitear tran2 recién luego de ejecutar el 2do SELECT en tran1, la lectura de @a y @b es igual, 0 (tomando como axioma la tabla vacía al momento de ejecutar las transacciones).

Si el commit de Tran2 se hubiese dado antes del segundo SELECT de Tran1, aun teniendo como isolation level READ COMMITTED en Tran1 hubiesemos obtenido la diferencia, ya que la función agregada count se basa en la totalidad de la tabla y READ COMMITTED sólo lockea los rows involucrados en el select a repetir, en este caso, en ningún row.

Comenten si piensan diferente, así aprendemos todos!

Perdon pero el VoF, el
1A es falso no? Lo mejor son las vistas
1B es falso tambien? Siempre devuelven lo mismo o no?

(02-03-2015 14:29)coolerking escribió:  Perdon pero el VoF, el
1A es falso no? Lo mejor son las vistas
1B es falso tambien? Siempre devuelven lo mismo o no?

La primera casi seguro que es falsa
Y la segunda también.

Solo en caso de que en vez de union sea union all seria verdadera, porque si tenemos union all en el caso en que tenemos los registros

(1,2)


la primer consulta me va a dar una fila con 1
y la segunda consulta me va a tirar 1 y abajo otro 1, ya que contaría los repetidos, no se si me expliqué

(01-03-2015 20:20)hiderocks escribió:  Gente, no sé por qué marcan que hay un error de sintaxis. La sintaxis de INSERT INTO SELECT en SQL SERVER es perfectamente válida.

 

CREATE TABLE prueba (

  col1 int

  );



SELECT * FROM prueba;



INSERT INTO prueba (col1)

(SELECT count(col1) + 1 FROM prueba);



SELECT * FROM prueba;

Compilar y ejecutar código

En el primer SELECT no devuelve nada, en el segundo devuelve 1.

Lo que yo argumentaría en este punto es que, basandonos en la suposición de que estamos en SQL SERVER, el isolation level por defecto es READ COMMITTED. Ergo, Tran1 garantiza evitar Dirty Reads. Al commitear tran2 recién luego de ejecutar el 2do SELECT en tran1, la lectura de @a y @b es igual, 0 (tomando como axioma la tabla vacía al momento de ejecutar las transacciones).

Si el commit de Tran2 se hubiese dado antes del segundo SELECT de Tran1, aun teniendo como isolation level READ COMMITTED en Tran1 hubiesemos obtenido la diferencia, ya que la función agregada count se basa en la totalidad de la tabla y READ COMMITTED sólo lockea los rows involucrados en el select a repetir, en este caso, en ningún row.

Comenten si piensan diferente, así aprendemos todos!

Para mi la tran2 hace el insert normalmente(osea nunca se bloquea en el momento 5) ya que antes solo se hizo un select, no se modifico la tabla, y segun tengo entendido, el que bloquea el select es el repeatable able o serializable(bloquea todo)

Puede ser? Este tema me esta volviendo loco :/

Para mi la respuesta seria la D. Como no sabemos el nivel de aislamiento, no podemos inferir el resultado. Ademas es diferente el resultado por ejemplo si se permiten lecturas fantasmas o no. Alguien que este de acuerdo ?

Estimados,

Con respecto al ejercicio 3.A. - La sintaxis es correcta, no hay errores para decir que se retrotrae las operaciones de la Sesion 1 y Sesion 2. Pero más allá de eso. Como no podemos suponer, la respuesta es la D, porque si no sabemos el nivel de aislamiento, no sabemos cuales son los bloqueos entre transacciones. No sabemos si se permiten lecturas fantasmas, lecturas repetibles o lecturas sucias. Por tanto, considero que es la D, no hay suficiente información. ¿Comparten con lo que digo? ¿Quien eligió otra respuesta? ¿y por qué?

Saludos, atte.

(18-07-2015 22:26)gaston monico escribió:  Estimados,

Con respecto al ejercicio 3.A. - La sintaxis es correcta, no hay errores para decir que se retrotrae las operaciones de la Sesion 1 y Sesion 2. Pero más allá de eso. Como no podemos suponer, la respuesta es la D, porque si no sabemos el nivel de aislamiento, no sabemos cuales son los bloqueos entre transacciones. No sabemos si se permiten lecturas fantasmas, lecturas repetibles o lecturas sucias. Por tanto, considero que es la D, no hay suficiente información. ¿Comparten con lo que digo? ¿Quien eligió otra respuesta? ¿y por qué?

Saludos, atte.

Si, estoy de acuerdo. Yo la justificaría así:

Si el isolation level fuera SERIALIZABLE, la respuesta sería la a), ya que ambas variables son cero.
Si el isolation level fuera READ UNCOMMITED, la respuesta sería la c), ya que la variable @b cuenta al valor insertado en la sesión 2, que no fue commiteado todavía.
Por lo tanto, al no saber el isolation level que se está usando, la respuesta es la d)

Estoy probando el 1b) con esta página http://www.w3schools.com/sql/trysql.asp?...select_all y me sucede que una vez que uso el union, no me devuelve valores repetidos! Entonces si hago select 1 bla bla union select 1 bla bla, me va a devolver un solo registro siempre, o 0 registros, ya que no me da resultados repetidos. Es un error del motor de la página??

Aviso: si van a probar la página, les aclaro que se pueden crear otras tablas!!

Respecto al 3b) Lo único que me pide que es para aquellos casos donde el mail y el teléfono sean NULL, estos aparezcan abajo de todo en el resultado de mi consulta, con simplemente cambiar el order by teoricamente funcionaría.

ORDER BY mail DESC, telefono DESC
El motor considera a NULL como el valor más bajo, si ordeno con DESC, los null van a estar abajo de todo.
Lo unico malo de esta solución es que no lo voy a tener más ordenado por razon social como en el script original, una alternativa simple seria
ORDER BY mail DESC, telefono DESC, 1

Y sino calculo que la solución del UNION que planteó uno de los compañeros debe funcionar. Alguno lo testeó? son medios tramposos los unions para mi.

La diferencia entre UNION y UNION ALL es que UNION no devuelve registros repetidos y UNION ALL si, por lo tanto:

el 1b) dice que NUNCA obtienen el mismo resultado las queries, excepto cuando no devuelven filas ninguno de los dos.

Por lo tanto vamos a demostrar que es falso con un contraejemplo.

Si la tabla cuenta con UN solo registro donde campo1 = 1, la primera query va a retornar un solo registro con el valor 1
y la segunda query tambien porque la primera parte del UNION va a devolver un registro con un 1, y la segunda parte del UNION no va a retornar ninguna fila mas.

Por esto indicamos que es falso.

Slds.

Buenas, estoy preparando el final para el próximo martes 15/12/2015. Vi que hay muchas dudas acá, así que dejo mi resolución (no garantizo que esté bien), por si a alguien le sirve.

1a. F. El alías te oculta el nombre y el dueño, pero no restringe campos de la tabla; para eso se usaría una vista.
1b. F. Si el campo2 != 2 para todos los registros, la segunda query de la segunda query (es decir, la que viene después del union) daría null, porque ningún registro cumple. Entonces, como null es neutro para la unión, se puede simplificar en:

select 1 from tablita where campo1= 1 union select 1 from tablita where campo2= 2

Y como dijimos que ningún registro tiene campo2 = 2, esa condición siempre va a dar falso, que es el elemento neutro en el or, entonces podemos simplificar el where de la primer query:

select 1 from tablita where campo1= 1 or campo2= 2

Por lo tanto, si ningún registro tiene campo2 = 2, ambas querys son equivalentes, y la afirmación es falsa.

3a. Acá pasa algo que me parece que nadie vio, que es que la tabla está vacía y el campo col1 no acepta nulos. El subselect que hace el insert va a dar nulo, porque no hay nada en la tabla, y por la contraint no va a poder insertar, o sea que la transacción de la sesión 2 va a rollbackear, y no va a afectar de ninguna manera a la otra transacción, por lo que la respuesta correcta sería la A, a y b siempre son iguales.
Es por esto que habrán insistido que no era tema de interpretación, más allá del motor y de si el isolation level default es read commited u otro, ese insert siempre va a fallar, por lo que la respuesta es bien concreta y no presenta ambigüedades.

3b. Acá, si bien no lo dice, considero que hay que mantener el orden que le da la query original. Para mi lo más fácil es partir la query en dos, una con nulos y la otra sin, y hacer un union, ordenando por un campo extra que tome valores contantes, siendo, por ejemplo, 1 para las que no tienen nulos, y 2 para las que sí tienen nulos en esos campos. Después, con otro select descartás el campo ese auxiliar. Sería así:

 select t.razonsocial, t.email, t.telefono

from (

	select c.razonsocial, ISNULL(c.email, 'sin mail') as email, ISNULL(c.telefono, 0) as telefono, 1 as aux

	from tl_clientes c, tl_facturas f

	where 

		codcli = faccli and 

		estado = 'IMPAGA' and

		(c.email is not null or

		c.telefono is not null)



	union



	select c.razonsocial, 'sin mail', 0, 2 as aux

	from tl_clientes c, tl_facturas f

	where 

		codcli = faccli and 

		estado = 'IMPAGA' and

		c.email is null and

		c.telefono is null

	) t

order by t.aux, 1

Hay que tener en cuenta que dice que van al final solo los que registros que no tienen tanto telefono como mail, es decir, si tienen valor para alguno de los dos campos se tienen que ordenar normalmente, es por eso que el ISNULL/2 no se puede sacar del primer subselect, y en el where hay que usar el OR en vez de AND.


Repito, pueden haber cosas mal, sean libres de opinar y/o corregir.

Saludos!