(27-02-2015 10:59)p3rch4 escribió:  Nacho14 coolerking , lo que dice Tizi es que si le agregas un alias a la columna que se le aplica la funcion isNull y ordenas por el verdadero nombre de la columna, no pone los NULL abajo de todo:

Select id, isNull(detalle,'sin descripcion') as el_detalle
from producto
order by detalle desc

La solucion seria ordenar por la columna por el alias:

Select id, isNull(detalle,'sin descripcion') as el_detalle
from producto
order by el_detalle

Ojo que no corre el order by desc en este caso. Directamente te manda los null abajo.

p3rch4

Gracias ya entendí. Lo que no entendi porque no se puede poner el desc... jajaami me anda

coolerking me refiero al segundo caso. Si le pones order by ALIAS desc , te quedan los null arriba de todo.

Es raro, sin el alias tenes que aclarar que sea desc. Pero si le pones un alias no hace falta, ya te los manda al fondo.

lo más fácil es hacerlo con un union all para evitar confusiones y sabes que nunca va a estar mal.

el orden de los datos es así, siempre viene primero el null y después la letra a, b, c, d, etc..
por lo tanto si ordenas por una columna y no pones nada, el motor lo va a tomar como que es ascendente y te va a dejar los nulls arriba de todo, en cambio, si pones desc el motor los va ordenar al revez y te va a poner siempre los null abajo de todo.

la cosa es diferente si ordenas por alias ya que los nulls te los va a tomar como "Sin descripcion" y ahi se va a ordenar normalmente como si fuera una cadena y no un dato NULL.


no se si se entendió espero que haya sido claro

(28-07-2014 12:41)Mobyer escribió:  Una vez que comittea la tran1, ahí hace el select y todo lo demás la t2. Pero como hace rollback queda todo como lo dejo la tran1. Asique queda en x

Ojo. El Serializable level de Tran1 va a garantizar la lectura repetida de esta, pero va a permitir el select de la tran2, ya que esto no haría ningún cambio en las rows incluidas en la transacción 1.

Así, la tran 2 se bloquearía recién al momento de llegar al update.

Acá tenés más información, en la parte de Serializable Isolation Level.
https://msdn.microsoft.com/en-us/library/cc546518.aspx

Buenas,
Vengo estudiando Isolation Levels a lo Rambo, y aclarando un poco todos los finales donde se toma esto.
El tema no es difícil, pero confunde mucho.
Probé en mi PC el código de roli93, pero un poco cambiado... Acuérdense que cada transacción se ejecuta en pestañas diferentes:

 

set transaction isolation level serializable

begin tran ta

select * from TablaPrueba where numero=2

waitfor delay '000:000:6'

update TablaPrueba set valor = 10 where numero=2

commit tran ta

 

set transaction isolation level serializable

begin tran tb

waitfor delay '000:000:3'

select * from TablaPrueba where numero=2

waitfor delay '000:000:5'

update TablaPrueba set valor = 30 where numero=2

rollback tran tb

... Efectivamente, se produce un deadlock en ese rango de registros. Primero el TA bloquea el rango de registros para sí, y después TB también bloquea ese rango tras el select. Ninguno de los dos va a soltar el rango hasta que alguna transacción haga Commit.
Cuando TA quiera updetear, se va a bloquear hasta que TB libere el recurso. Cuando TB quiera updetear, se va a bloquear hasta que TA libere el recurso!! Entonces los dos se quedan esperando por siempre....
En SQLServer2008, va a elegir un proceso víctima para matarlo... SIEMPRE elije a TB por ser el proceso que tomó último el recurso, y TA termina bien.
O sea, el resultado final lo dá TA, PERO no creo que en el final recaben tan a fondo, ya que esta es una decisión propia de cada motor.
CREO que con poner que da Deadlock alcanza.

Y de yapa:
- si los procesos fueran Repeteable Read, los bloqueos por SELECT también se aplican, por lo cual también da DEADLOCK.
- si los procesos fueran Read Committed, no se aplican bloqueos de SELECT, por lo cual los dos Select dan lo mismo y los dos Updates se ejecutan sin problema. Como los commits se ejecutan al mismo tiempo, el update de uno no influye en el update del otro.

Saludos!

El de Isolation, leyendo la teoria, lockea todo el registro cuando comienza la transaccion 1, luego comienza la transaccion 2 y queda a la espera de que finalice la 1.
Cuando finaliza la 1, hace comit y queda updeteado con 'X'', luego continua la transacion 2, hace un update con 'Y', pero al hacer rollback al final, queda entonces como resultado final 'X'

---------------------------------------------

El ultimo ejercicio seria asi:

SELECT id, detalle
FROM producto
where detalle is not null
union all
SELECT id, detalle
FROM producto
where detalle is null

No hace falta clausula de Order by, pimero pone el resultado de la primer consulta, luego la otra ordenada ascendentemente por id por defecto.

Saludos.

Para mi me parece que daria Deadlock :

cuando TA en el instante 1 hace el select bloquea el registro cuyo id=1 para que no pueda ser modificado por TB hasta que no haga commit. Cuando TB en el instante 2 hace el select tambien bloquea dicho registro para que no pueda ser modificado por TA. En el instante 3 TA no puede hacer el update y espera el commit de TB. Lo mismo le pasa a TB: en el instante 4 no puede hacer el update porque lo tiene bloqueado TA y espera el commit de TA. Entonces ninguna de las dos Transacciones hace el commit porque el otro lo tiene bloqueado.

Estimados!, Que tal?

Mis consideraciones sobre los puntos más importantes:

El punto 3.A - Teóricamente hablando, el nivel de aislamiento serializable no permite que se ejecuten 2 transacciones al mismo tiempo, se ejecuta una tras otra. En este caso transacción A tomó primero el recurso que transaccion B, por tanto, Transaccion B debe esperar hasta que commiteé Transaccion A. Por eso el contenido de detalle es 'X'.

Si vamos a la práctica, es decir, a hacerlo en codigo Sql y ejecutarlo, increiblemente se contradice con lo anterior. Por lo que me genera dudas sobre lo que nos explicaron en clase sobre el nivel de aislamiento serializable. Sin embargo, yo apostaría más sobre mi primera apreciación debido a que es lo que nos "metieron" en la cabeza y se supone que estos ejercicios no pasan de los conceptos teoricos, ya que la practica sql o t-sql no habia nada sobre este tipo de ejercicios a implementar. No se si en PL-SQL ocurriria un deadlock.

El punto 3.B - Yo use Union, tambien podría haber usado UNION ALL, como otros compañeros lo hicieron.
Pero en este caso no cambia nada. Entiendo que la diferencia entre union y union all esta en que el ultimo te trae repetidos. Pero para este caso no aplica porque con el WHERE filtramos lo que necesitamos.

Saludos!!!

PD: si alguien tiene alguna correccion para hacerme que la haga please!! y se agradecería mucho!

(20-07-2015 22:45)gaston monico escribió:  El punto 3.B - Yo use Union, tambien podría haber usado UNION ALL, como otros compañeros lo hicieron.
Pero en este caso no cambia nada. Entiendo que la diferencia entre union y union all esta en que el ultimo te trae repetidos. Pero para este caso no aplica porque con el WHERE filtramos lo que necesitamos.

Agrego a esto que tampoco es necesario poner el ISNULL(detalle, 'Sin descripcion') en el 2º WHERE. Se puede poner directamente 'Sin descripcion' porque ya sabemos que todos los que tengan detalle NULL van a ir a parar ahí.

(15-12-2014 18:36)Danlco escribió:  Hola yo para el 3)b) lo pense asi:

select id, detalle
from producto
where detalle is not null
union all
select id, isnull(detalle, 'sin descripcion)'
from producto
where detalle is null

el union all los ordena por id y de esta forma pone los que tienen null abajo de todos.

Saludos

En este caso el ejercicio está pidiendo que se reescriba la consulta, por ende, no debe aparecer isnull que es una función propia de SQL SERVER.

La forma adecuada seria a mi entender:

select id, detalle
from producto
where detalle is not null
union all
select id, detalle
from producto
where detalle is null

Con eso es suficiente, no hace falta order by ni nada parecido, los nulos los deja abajo.
Saludos.

(27-07-2015 20:57)osk escribió:  En este caso el ejercicio está pidiendo que se reescriba la consulta, por ende, no debe aparecer isnull que es una función propia de SQL SERVER.

El "isNull" se puede usar para los ejercicios de SQL (Me refiero a que se usa en la primer guía de ejercicios, no en la de Transact SQL). Decís que lo consideran mal?

Veo que hay un poco de debate con respecto al ejercicio de concurrencia. Vengo a aportar mi opinión:

Citando a Wikipedia, Isolation(database systems)

Cita:SERIALIZABLE

This is the highest isolation level.

With a lock-based concurrency control DBMS implementation, serializability requires read and write locks (acquired on selected data) to be released at the end of the transaction. Also range-locks must be acquired when a SELECT query uses a ranged WHERE clause, especially to avoid the phantom reads phenomenon [...].

Lo que dice es que con un nivel de SERIALIZABLE, se adquieren 3 tipos de locks:
- de lectura
- de escritura
- range locks, sobre las filas afectadas por el WHERE, para prevenir phantom reads.

La Transacción A tiene locks sobre todos los registros que retorna la query en tiempo 1, por lo que cuando la Transacción B ejecuta su SELECT en tiempo 2 se bloquea hasta que finaliza la Transacción A (sea por el motivo que sea, commit o rollback). No se produce deadlock en este caso, y como la Transacción B hace rollback, la fila del producto con id 1 queda con 'X' como valor en el campo 'detalle'

Hay que tener cuidado en el 3b) porque sql no te da un order para los unions.

http://stackoverflow.com/questions/42104...-behaviour

por lo tanto hay que definirlo si o si.

Slds.

(14-12-2014 22:12)NaiaraAcosta escribió:  Incluyo un poco de lo teorico pero con algunas dudas, si ven algun error chiflen

1.a. V
1.b. F

2.a Se me ocurre Plan de ejecución, indices algo mas??

Cómo sabés que la 1 es verdadera? Gracias!