(23-02-2012 22:44)fedevega escribió:  Buenas gente, por el último punto, yo uso T-SQL e implementaría una FK que tenga ON DELETE CASCADE de la siguiente manera:

alter table Det_fact
add constraint FK_DetFact_nFact
foreign key(n_fact) references Cab_fact(n_fact)
on delete cascade;

Y con esto le peleo a muerte que usé el Objeto de BD "Foreign Key".

Alguno fue a rendir este examen? surgió alguna discusión por esto?

Saludos !!

Fede.-

Fede, haciendo esto quedarian 2 constrain FK, una sin el delete cascade, y otra con, igual funciona por lo que probe.. cuando borras, se borra todo, pero afectara en algo? mmm
Lo ideal creo que seria hacer un drop de la vieja, no?

Saludos

a mi se me ocurrió más facil con un trigger

CREATE TRIGGER ON CAB_FACT
AFTER DELETE
AS
BEGIN

DECLARE @N_FACT_A_BORRAR INT
SET @N_FACT_A_BORRAR = (SELECT N_FACT FROM DELETED)

DELETE FROM DET_FACT WHERE N_FACT = @N_FACT_A_BORRAR

END


aviso que no lo probé pero creo que funciona


saludos

(27-02-2015 21:31)Nacho14 escribió:  CREATE TRIGGER ON CAB_FACT
AFTER DELETE
AS
BEGIN

DECLARE @N_FACT_A_BORRAR INT
SET @N_FACT_A_BORRAR = (SELECT N_FACT FROM DELETED)

DELETE FROM DET_FACT WHERE N_FACT = @N_FACT_A_BORRAR

END

La implementación del trigger está bien, pero hay que tener en cuenta que en el caso de existir una FOREIGN KEY en Det_fact que referencia a Cab_Fact (como la que se plantea en el diagrama de entidades, mediante el "(fk)"), el DELETE sobre Cab_Fact que se requiere para disparar el trigger nunca podría ejecutarse. (Esto lo digo después de haberlo probado).

O sea, si nos ponemos quisquillosos, si o si tenés que plantear el hacer drop al FOREIGN KEY que ellos nos dan, alterando la tabla, y después elegís el camino que más te guste. Aunque, si tenés que alterar la tabla, ya seguí por ahí y hacé el FK de nuevo con un ON CASCADE DELETE y listo.

(01-03-2015 14:43)hiderocks escribió:  

(27-02-2015 21:31)Nacho14 escribió:  CREATE TRIGGER ON CAB_FACT
AFTER DELETE
AS
BEGIN

DECLARE @N_FACT_A_BORRAR INT
SET @N_FACT_A_BORRAR = (SELECT N_FACT FROM DELETED)

DELETE FROM DET_FACT WHERE N_FACT = @N_FACT_A_BORRAR

END

La implementación del trigger está bien, pero hay que tener en cuenta que en el caso de existir una FOREIGN KEY en Det_fact que referencia a Cab_Fact (como la que se plantea en el diagrama de entidades, mediante el "(fk)"), el DELETE sobre Cab_Fact que se requiere para disparar el trigger nunca podría ejecutarse. (Esto lo digo después de haberlo probado).

O sea, si nos ponemos quisquillosos, si o si tenés que plantear el hacer drop al FOREIGN KEY que ellos nos dan, alterando la tabla, y después elegís el camino que más te guste. Aunque, si tenés que alterar la tabla, ya seguí por ahí y hacé el FK de nuevo con un ON CASCADE DELETE y listo.

ahi corregí el trigger con lo que estaba mal, este sí creo que funciona, ahora lo pruebo y aviso.

CREATE TRIGGER borradoCascada ON CAB_FACT
INSTEAD OF DELETE
AS
BEGIN

DECLARE @N_FACT_A_BORRAR INT
SET @N_FACT_A_BORRAR = (SELECT N_FACT FROM DELETED)

DELETE FROM DET_FACT WHERE N_FACT = @N_FACT_A_BORRAR
DELETE FROM CAB_FACT WHERE N_FACT = @N_FACT_A_BORRAR

END


-------------------------
probado, funciona perfecto !

Consulta re tonta. En los V o F solo hay que indicar si es uno u otro. O también hay que justificar el por qué de la respuesta?.

(01-03-2015 18:00)Martin. escribió:  Consulta re tonta. En los V o F solo hay que indicar si es uno u otro. O también hay que justificar el por qué de la respuesta?.

Por lo que vi depende de la fecha, algunos finales son con justificación y otros son jugartela entre V o F pero en este ultimo caso si está mal la respuesta te resta un punto.