nadine1985 Geschrieben 2. November 2010 Teilen Geschrieben 2. November 2010 Hallo liebe Community ich habe folgendes Problem. Ich soll eine Datenbank mit MSSQL SERVER 2008 erstellen in der es 2 Tabellen gibt. CREATE DATABASE Uebung1; USE Uebung1; CREATE TABLE Produkt ( PID char(2) NOT NULL Primary Key, Artikel varchar(255) NOT NULL, Anzahl int NOT NULL, ); CREATE TABLE Kauf ( KID int Primary key, PID char(2) NOT NULL Foreign key references Produkt(PID), Preis float, Kunde varchar(255), ); INSERT INTO Produkt (PID,Artikel,Anzahl) VALUES ('C1','COMPUTER',0); INSERT INTO Produkt (PID,Artikel,Anzahl) VALUES ('D2','DRUCKER',0); INSERT INTO Produkt (PID,Artikel,Anzahl) VALUES ('B1','BEAMER',0); INSERT INTO Kauf (KID,PID,Preis,Kunde) VALUES (1,'C1',233.20,'Max'); INSERT INTO Kauf (KID,PID,Preis,Kunde) VALUES (2,'B1',320.00,'Paul'); INSERT INTO Kauf (KID,PID,Preis,Kunde) VALUES (3,'D2',99.45,'Max'); INSERT INTO Kauf (KID,PID,Preis,Kunde) VALUES (4,'C1',123.20,'Fritz'); INSERT INTO Kauf (KID,PID,Preis,Kunde) VALUES (5,'D2',100.20,'Egon'); Dieses funktioniert in dieser Form ersteinmal. Allerdings wurde uns als weitere Aufgabe gestellt das bei einer Änderung einer PID die Änderung an die andere Tabelle weitergegeben werden soll. Meine Frage hierzu wäre, ob ich mit der Option eines Triggers richtig liege!? Anders kann ich mir zumindest keine Lösung vorstellen. Ich habe bereits folgendes hierzu versucht: CREATE TRIGGER PID_Update ON dbo.Produkt AFTER UPDATE AS DECLARE @NEW_PID CHAR(2) SET @NEW_PID = (SELECT PID FROM inserted) UPDATE dbo.Produkt SET PID = @NEW_PID Wobei die Erzeugung des Triggers auch wieder funktionierte, allerdings macht entweder A: Der Trigger nicht das was gefordert ist oder B: Ich habe etwas mit den Primary key bzw Foreign Key nicht ganz verstanden denn UPDATE dbo.Produkt SET PID = 'K1' WHERE PID = 'C1' gibt mir folgende Fehlermeldung aus: Meldung 547, Ebene 16, Status 0, Zeile 1 Die UPDATE-Anweisung steht in Konflikt mit der REFERENCE-Einschränkung 'FK__Kauf__PID__108B795B'. Der Konflikt trat in der 'Uebung1'-Datenbank, Tabelle 'dbo.Kauf', column 'PID' auf. Die Anweisung wurde beendet. :confused: Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 2. November 2010 Teilen Geschrieben 2. November 2010 Hi, da ist schon mal das DB-Modell falsch. Ein Pk ist immutable - sprich er darf sich nicht ändern. Damit schließt sich die Verwendung eines fachlichen Werts als Pk, wie Du es getan hast, aus. Verwende als PK eine Nummer, die Du per Sequence füllst, so wie Du es auch schon in der Tabelle KAUF getan hast, ändere den entsprechenden FK-Constraint und fertig. Andere Lösungsmöglichkeiten sind technisch gesehen nicht korrekt. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
.NETter Geschrieben 2. November 2010 Teilen Geschrieben 2. November 2010 Hallo, ich kann Dr.Dimitri da nur zustimmen. Ein Wert der geändert wird ist als PK gänzlich ungeeignet. Anstatt wie in Oracle eine Sequence zu verwenden (die gibts im SQL Server in diesem Sinn nicht) definierst Du den neuen PK als [iNT IDENTITY(1,1)]. Somit hast du einen PK vom Typ INT welcher sich selbsständig inkrementiert. Ein Trigger könnte in etwas (nur ein Vorschlag) so aussehen: CREATE TRIGGER PID_Trigger ON dbo.Produkt AFTER UPDATE AS BEGIN DECLARE @PIDvorher char(2) DECLARE @PIDnachher char(2) SELECT @PIDvorher = PID FROM DELETED SELECT @PIDnachher = PID FROM INSERTED IF(@PIDvorher <> @PIDnachher) BEGIN UPDATE dbo.Kauf SET PID = @PIDnachher WHERE PID = @PIDvorher END END Die PID soll ja nur in der Tabelle Kauf geändert werden wenn sie einen neuen Wert erhalten hat... Viele Grüße, Thomas Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 2. November 2010 Teilen Geschrieben 2. November 2010 Noch als Ergänzung: Die PID sollte nur einmalig vorhanden sein und nicht in mehreren Tabellen gepflegt werden. Ansonsten müsste man auch den Rückweg abfangen (also Änderung der PID in KAUF). Und meine Meinung zum Thema Trigger dürfte hier bekannt sein Dim PS: Ein PK ist bereits NOT NULL das muss man nicht nochmal definieren. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
nadine1985 Geschrieben 4. November 2010 Autor Teilen Geschrieben 4. November 2010 Hallo ihr lieben, danke für eure Antworten, habe das Problem nochmal angesprochen. Lösung des Ganzen: http://www.yard-sql.de/doc/YARD-SQL_g/f56.html Das Ganze läuft über ein CASCADE Option welche auf Ereignisse hinsichtlich des PKs reagiert Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.