Hola. Quería pedir el final de la 1er fecha de Febrero o bien si pueden comentar como fue.

Muchas gracias.

Hola, envio el final que tomaron. No se si las respuestas que escribí son correctas.
Espero que te sirva.
Atte
Paula

Muchas gracias por el aporte. Aporto mi resolución "on the fly".
1)
a) F. Contraejemplo: select count(*) from tabla
b) F.

2)
a) Performance.
b) Triggers, constraints (podrían ser también vistas y procedimientos pero estos sirven mas que nada para el acceso de datos)

3) Supongo que la respuesta es la A. Si la tabla esta vacía, al querer insertar un dato NULL en una columna que no los admite "rompe". Por lo tanto la transacción 2 no termina de ejecutarse por completo. La transacción 1 se ejecuta sin problemas y el resultado del count seria el mismo para ambas sentencias.

4) Trigger que nos impida un hacer insert/update de un valor que no sea consecutivo a los de la tabla (cuando llego a casa lo desarrollo).

Gente, subo el final scaneado por si alguno lo quiere imprimir.
Éxitos para los que vayan a rendir !
   

¿La respuesta al ejercicio 3 no sería la D "No hay suficiente información"?
Porque dependiendo del isolation level (que no lo menciona en el ejercicio) el proceso 1 puede o no ver lo que insertó el proceso 2.

podes justificar eso, o podes tomar el default value de isolation level (el cual como hice gdd hace 2 años no recuerdo ahora).

Pasa que el default value depende del motor, y no te dicen que es (uno asumiria que es sql server por la sintaxis y porque se ve en la cursada, pero tecnicamente...)

Recuerdo alguna vez a uno de los profes de gdd diciendo que podian valer cualquiera de las 2 respuestas, si estan bien justificadas

Hola, alguno tiene la resolución del punto 4??

gracias!!!!

yo haría un trigger instead of insert, y que haga un insert de count(*) + 1

---

algo asi (no me acuerdo bien la sintaxis, puede que algo pifie, es pseudo codigo arre)

 create trigger dbo.SoloNaturalesInsert on Tabla

instead of Insert

as

begin 

insert into Tabla select count (*)  + 1 from tabla

dice que se acceden de distintas maneras

asique se podria borrar un elemento.
Eso significa que deahi en adelante tenes que retrasar todos los elementos en -1
nuevamente, haria un trigger instead of delete

 create trigger dbo.SoloNaturalesDelete on Tabla

instead of Delete

as

begin



delete from tabla where col1 in (select col 1 from deleted) -- el in siempre deberia traer un solo elemento

-- actualizamos desde donde borramos en adelante, retrasando 1 siempre

update Tabla set col1 = col1 - 1 where col1 in (select col1 + 1 from deleted)

end

no estoy seguro, me da fiaca pero creo que se puede hacer con un "after delete" y solo haciendo el update


y para el update lo mismo.. imagino que habrá que updatear los valores desde ese valor en adelante.. asique es otro trigger

Para el ejercicio 4, un trigger que se comporta de una manera un poco mas copada, si lo que insertas es el siguiente o los siguientes numeros al ultimo que tiene la tabla, te lo inserta, sino no hace nada (se podria mandar un error tambien)... Esta testeado en sql server y anda bien![/code]
Lo unico que tiene es que no contempla el caso de que tengas un conjunto sin huecos pero que no empiece desde cero (ejemplo 456) y quieras agregar desde abajo (por ejemplo 23, para que queden 23456)... Esto ya era demasiado complejo.

Falta el trigger instead of update (que no deberia hacer nada, solo sustituir la operacion update por un mensaje de error)

 

create trigger trigger_insertnumber on TABLA_FINAL

instead of insert

as

declare @numero int

declare curs cursor for select numero from inserted order by numero asc

open curs

fetch next from curs into @numero

	if(((select max(numero) from TABLA_FINAL) is NULL) and (@@FETCH_STATUS = 0))

	begin

		if (@numero = 0)

		begin

			insert into TABLA_FINAL(numero) values (@numero)

			fetch next from curs into @numero

		end

	end

	while @@FETCH_STATUS = 0

	begin

	if(@numero = (select max(numero) from TABLA_FINAL) + 1)

		begin

		insert into TABLA_FINAL(numero) values (@numero)

		end

	fetch next from curs into @numero

	end

close curs

deallocate curs

go





create trigger trigger_deletenumber on TABLA_FINAL

instead of delete

as

declare @numero int

declare curs cursor for select numero from deleted order by numero desc

open curs

fetch next from curs into @numero

	while @@FETCH_STATUS = 0

	begin

	if(@numero = (select max(numero) from TABLA_FINAL))

		begin

		delete from TABLA_FINAL where numero = @numero

		end

	fetch next from curs into @numero

	end

close curs

deallocate curs

go

para que vas a hacer un cursor recorriendolos todos si al estar numerados, sabiendo la cantidad de filas ya sabes cuanto vale el ultimo ?

(22-02-2014 22:16)gonnza escribió:  yo haría un trigger instead of insert, y que haga un insert de count(*) + 1

---

algo asi (no me acuerdo bien la sintaxis, puede que algo pifie, es pseudo codigo arre)

 create trigger dbo.SoloNaturalesInsert on Tabla

instead of Insert

as

begin 

insert into Tabla select count (*)  + 1 from tabla

Compilar y ejecutar código

dice que se acceden de distintas maneras

asique se podria borrar un elemento.
Eso significa que deahi en adelante tenes que retrasar todos los elementos en -1
nuevamente, haria un trigger instead of delete

 create trigger dbo.SoloNaturalesDelete on Tabla

instead of Delete

as

begin



delete from tabla where col1 in (select col 1 from deleted) -- el in siempre deberia traer un solo elemento

-- actualizamos desde donde borramos en adelante, retrasando 1 siempre

update Tabla set col1 = col1 - 1 where col1 in (select col1 + 1 from deleted)

end

Compilar y ejecutar código

no estoy seguro, me da fiaca pero creo que se puede hacer con un "after delete" y solo haciendo el update


y para el update lo mismo.. imagino que habrá que updatear los valores desde ese valor en adelante.. asique es otro trigger

Me parece buenísimo la resolución con los triggers
pero me agarró una duda en el de delete.
por ejemplo se insertaron ya:

1
2
3
4
5
6

Y alguien hace un delete al 4, ok, el trigger de delete borra el 4 y hace el update al 5 poniendolo en 4, pero me deja el 6 dejando un hueco
1
2
3
4
6

O hay algo que no estoy viendo?

Gracias!

no solo tenes razon, sino que yo no me fío de mi propio comentario que dice "el in siempre deberia traer un solo elemento, actualizamos desde donde borramos en adelante, retrasando 1 siempre"

porque podrían borrarse varios a la vez (where num > x) asique también estaría mal

de cualquier manera, respecto a tu pregunta puntual, se podria hacer un cursor que itere deleted, y haga set col1 = col1- 1 cuando col1 > <numero-iterado-de-deleted>

no me acuerdo la sintaxis de cursor ni a palos


el insert deberia quedar igual

---

debería hacerse un trigger para update también me parece

(13-02-2014 10:51)ortiba escribió:  ¿La respuesta al ejercicio 3 no sería la D "No hay suficiente información"?
Porque dependiendo del isolation level (que no lo menciona en el ejercicio) el proceso 1 puede o no ver lo que insertó el proceso 2.

No puede ser la D. Por mas que especifique el isolation level, no cambiaria nada. Porque el proceso 2 tira error (si se ejecuta el proceso 1 primero o el 2 primero).
Es la A, pq es cierto que a y b siempre son iguales, siempre valen 0.

Pero son procesos que por mas que se ejecuten en paralelo, son independientes.
Porque el proceso 2 falla, pq la tabla no tiene nada, y no puede insertar null en la tabla.
El proceso uno, solo define unas variables, pero no inserta nada en la tabla que pueda llegar a modificar la consulta del proceso 2.

corrijanme si me equivoco

Saludos

Al punto cuatro tambien habria que hacer algo con el update, porque con un update el usuario romperia todo!

Alguno me podría justificar la 2da del VoF

Gracias