TSQL Skript Composite Primary Key/ Syntax Fehler?

[Frank333333]

Hallo zusammen,

wir brauchen dringend eure Hilfe. Wir versuchen verzweifelt seit 2 Wochen einen Fehler in unserem TSQL-Skript zu finden. Wir benutzen Visual Studio 2010 und möchten mit dem TSQL-Skript die Tabellen bzw. das Datenbankdiagramm erstellen. Mit dem Datenbankdesigner sollen wir nicht arbeiten, sondern die Datenbank durch das SQL-Skript erstellen. Insgesamt haben wir 9 Tabellen. 2 dieser Tabellen enthalten Composite Primary Keys. Müssen wir hierbei etwas Bestimmtes beachten? Wenn wir nämlich anstatt der Composite Keys jeweils ein zusätzliches IDENTITY-Attribut als alleinigen Primary Key benutzen, dann funktioniert alles.

Hier mal die Fehlermeldung und die 2 Tabellen mit den Composite Primary Keys:

Fehlermeldungen:
Meldung 3728, Ebene 16, Status 1, Zeile 1
'PK_Application' ist keine Einschränkung.
...
Meldung 1769, Ebene 16, Status 1, Zeile 10
Der 'FK_Employee_Workplace'-Fremdschlüssel verweist auf die ungültige 'ArbeitsplatzID'-Spalte in der verweisenden 'Employee'-Tabelle.
Meldung 1750, Ebene 16, Status 0, Zeile 10
Die Einschränkung konnte nicht erstellt werden. Siehe vorherige Fehler.
Tabellen:
CREATE
TABLE Application (
ArbeitsplatzID int NOT NULL,
BewerberID int NOT NULL,
Bewerbungsstatus nvarchar (30) DEFAULT 'aufgenommen' NOT NULL,
Bewerbungszeitpunkt datetime NULL,
CONSTRAINT PK_Application PRIMARY KEY CLUSTERED (ArbeitsplatzID,BewerberID),
CONSTRAINT CK_AppStatus CHECK (Bewerbungsstatus IN ('aufgenommen','eingeladen','angenommen','abgelehn t','abgelehntAndererBewerber','abgelehntAndererArb eitsplatz')),
CONSTRAINT FK_Application_Workplace FOREIGN KEY (ArbeitsplatzID) REFERENCES Workplace (ID),
CONSTRAINT FK_Application_Applicant FOREIGN KEY (BewerberID) REFERENCES Applicant (ID),
)
...
TABLE ObjectToQualification(
Typ int NOT NULL,
ObjectID int NOT NULL,
QualifikationsID int NOT NULL,
QualifikationslevelID int NOT NULL,
CONSTRAINT PK_ObjectToQualification PRIMARY KEY CLUSTERED (Typ,ObjectID,QualifikationsID),
CONSTRAINT FK_ObjectToQualification_Qualification FOREIGN KEY (QualifikationsID) REFERENCES Qualification (ID),
CONSTRAINT FK_ObjectToQualification_QualificationLevel FOREIGN KEY (QualifikationslevelID) REFERENCES QualificationLevel (ID),
)

Die Fehlermeldung sieht folgendermaßen aus:
Meldung 3728, Ebene 16, Status 1, Zeile 1
'PK_Application' ist keine Einschränkung.
...
Meldung 1769, Ebene 16, Status 1, Zeile 10
Der 'FK_Employee_Workplace'-Fremdschlüssel verweist auf die ungültige 'ArbeitsplatzID'-Spalte in der verweisenden 'Employee'-Tabelle.
Meldung 1750, Ebene 16, Status 0, Zeile 10
Die Einschränkung konnte nicht erstellt werden. Siehe vorherige Fehler.

Liegt es möglicherweise daran in welcher Reihenfolge wir die Tabellen erzeugen?

Ist es sinnvoll „Constraints“ wie Primary Keys, Foreign Key und Checks mit „Alter“ hinzuzufügen? Auch hier wieder die Frage der Reihenfolge?

Und wann macht es Sinn ein „GO“ zu setzen? Nach jedem Table-Create und jeder „Alter“-Anweisung? Oder nur bei Bestimmten?


Wir würden uns sehr über eine Antwort und Anregungen freuen.

Viele Grüße,
Frank

PS: Den vollständigen SQL-Skript haben wir hier hochgeladen Link. Vielleicht kann ihn ja jemand mal ausprobieren?! Sind echt verzweifelt...:(

[Bummi]

Das Problem sind soweit ich es sehe nur die ForeingKeys, diese einfach nach dem Erstellen der Tabellen per Alter hinzufügen.
Wie VisualStudio mit dem GO umgeht kann ich nicht sagen, in Delphi zerlege ich derartige Scripte und setze die Blöcke zwischen den GO's einzeln ab.

[tsteinmaurer]

Natürlich ist die Reihenfolge wichtig. Du kannst nicht die Tabelle DEPARTMENT erstellen, wenn die Tabellen DDL eine FK-Definition auf EMPLOYEE beinhaltet, wenn es die EMPLOYEE Tabelle noch gar nicht gibt.

Ich halte es so, dass FK-Constraints mit ALTER TABLE ... nach dem Anlegen aller Tabellen erstellt werden.

[tsteinmaurer]

Aja, und man findet auch interessante Dinge wie:

Code:

CONSTRAINT CK_EmpGebutsdatum CHECK (Geburtsdatum < getdate()-18)

D.h. ihr beschäftigt niemanden unter 18? :-D