2
Primärschlüsselabfrage von MSSQL 2005 auf 2000 (v9 nach v8) portieren ?
Hallo, ich habe ein kleines Problem die untenstehende Abfrage
der Spalten eines Primärschlüssels (MSSQL2005) nach MSSQL 2000 zu portieren.
Die Tabellen sind ganz anders aufgebaut und ich finde da keinen entsprechenden zusammenhang.
Kann mir da mal bitte jemand helfen ?
Danke, Pseumin
der Spalten eines Primärschlüssels (MSSQL2005) nach MSSQL 2000 zu portieren.
Die Tabellen sind ganz anders aufgebaut und ich finde da keinen entsprechenden zusammenhang.
select co.name, sc.name from sys.key_constraints co, sys.tables ta, sys.indexes ix, sys.index_columns ic, sys.syscolumns sc
where ta.object_id = co.Parent_object_id
and ix.object_id = co.Parent_object_id
and ic.object_id = co.Parent_object_id
and sc.id = co.Parent_object_id
and ix.is_primary_key = 1
and ix.index_id = ic.index_id
and sc.colid = ic.index_column_id
and ta.name = 'tabelle' Kann mir da mal bitte jemand helfen ?
Danke, Pseumin
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 93545
Url: https://administrator.de/contentid/93545
Printed on: April 19, 2024 at 06:04 o'clock
2 Comments
Latest comment
Moin pseumin,
gehen tut ja alles, aber du brauchst eine völlig andere strategie bzw ganz andere SysViews.
die Abfrage oben ist ja nun auch nur von bescheidener Eleganz... wieso Du da über die Sys.Tables gehst, das ist vermutlich eine persönliche Note.
Anyhow, zum allgeneinen Erstaúnen willst Du ja von den PKs die Constraint-Namen haben und das wiederum bezogen auf den Spaltennamen?!?
Frage: Sind PKs bei Dir immer auf eine Spalte bezogen??? *staun*
SQL2000 und vermutlich auch die meisten Laien wie ich würden den PK zwar als eine (benamsbare) constraint bezeichnen, aber keine Ein-Spalten-Constraint, sondern eine Constraint einmalig pro Table.
Entsprechend ist auch in SQL2000 und früher die Tabelle sysconstraints, die Du eventuell mal angeschaut hast eine Sackgasse. PKs stehen da nicht auf eine colId bezogen drin wie in der SQl2005-Query drin, wäre ja auch vollkommen absurd.
IMHO musst Du ohnehin über sysusers + sysobjects + sysindexes + sysreferences gehen.
Aber wenn Du "nur" den PK-Constraint einer Dir namentlich bekannten Tabelle ermitteln willst und meine Theorie stimmt, dass ein PK einmalig je Tabelle dort abgelegt wird, dann müsste ein superbilliges Dünnbrett-Statement reichen:
Wenn Du sicher(er) gehen willst, eine gültige PK-Constraint zu erwischen, dann solltest Du noch die ID mit der sysobjects verjoinen und dort die Felder Category und ColId in die Where-Bedingung aufnehmen.
Die Spalte sysobjects.Category muss das Bit 512 gesetzt haben.
Und Spalte sysconstraints.colId muss gleich 0 sein.
Also skizziert:
Aber ich verstehe nicht, was Du mit nur dem tabellennamen und dem Constraintnamen des PKs anfangen willst.
Brauchst Du nicht die Felder des PK und die Reihenfolge?
Dann nusst Du doch ohnehin über die Sysindexes und sysreferences.
Wie willst Du denn einen PK-Constraintnamen ändern, wenn ein oder zwei Felder des PK zufällig auch FK-Spalten sind.
Für eine Erläuterung des Plans bzw. des anwendungsfalls wäre ich dankbar - ich versuche gerade, mir ein wenig SQL anzueignen....
Grüße
Biber
gehen tut ja alles, aber du brauchst eine völlig andere strategie bzw ganz andere SysViews.
die Abfrage oben ist ja nun auch nur von bescheidener Eleganz... wieso Du da über die Sys.Tables gehst, das ist vermutlich eine persönliche Note.
Anyhow, zum allgeneinen Erstaúnen willst Du ja von den PKs die Constraint-Namen haben und das wiederum bezogen auf den Spaltennamen?!?
Frage: Sind PKs bei Dir immer auf eine Spalte bezogen??? *staun*
SQL2000 und vermutlich auch die meisten Laien wie ich würden den PK zwar als eine (benamsbare) constraint bezeichnen, aber keine Ein-Spalten-Constraint, sondern eine Constraint einmalig pro Table.
Entsprechend ist auch in SQL2000 und früher die Tabelle sysconstraints, die Du eventuell mal angeschaut hast eine Sackgasse. PKs stehen da nicht auf eine colId bezogen drin wie in der SQl2005-Query drin, wäre ja auch vollkommen absurd.
IMHO musst Du ohnehin über sysusers + sysobjects + sysindexes + sysreferences gehen.
Aber wenn Du "nur" den PK-Constraint einer Dir namentlich bekannten Tabelle ermitteln willst und meine Theorie stimmt, dass ein PK einmalig je Tabelle dort abgelegt wird, dann müsste ein superbilliges Dünnbrett-Statement reichen:
SELECT object_name(id), object_name(constid) from sysconstraints
where objectname = 'tabelle'
and (Status & 1 )=1 and ColId = 0Wenn Du sicher(er) gehen willst, eine gültige PK-Constraint zu erwischen, dann solltest Du noch die ID mit der sysobjects verjoinen und dort die Felder Category und ColId in die Where-Bedingung aufnehmen.
Die Spalte sysobjects.Category muss das Bit 512 gesetzt haben.
Und Spalte sysconstraints.colId muss gleich 0 sein.
Also skizziert:
SELECT object_name(o.id), object_name(sc.constid)
from sysconstraints sc, sysobjects o
where o.id = sc.id and
(sc.Status & 1) = 1 and
(o.category & 512) = 0 and sc.colid = 0Aber ich verstehe nicht, was Du mit nur dem tabellennamen und dem Constraintnamen des PKs anfangen willst.
Brauchst Du nicht die Felder des PK und die Reihenfolge?
Dann nusst Du doch ohnehin über die Sysindexes und sysreferences.
Wie willst Du denn einen PK-Constraintnamen ändern, wenn ein oder zwei Felder des PK zufällig auch FK-Spalten sind.
Für eine Erläuterung des Plans bzw. des anwendungsfalls wäre ich dankbar - ich versuche gerade, mir ein wenig SQL anzueignen....
Grüße
Biber
Hi Biber,
danke für die Ausführungen.
Ich bin kein hauptberuflicher Datenbankprogrammierer und mit den Systemtabellen habe ich mich bisher eigentlich überhaupt nicht beschäftigt (den Ansatz für diese Lösung habe ich in einen anderen Forum gefunden), aber unser System nutzt halt eine Datenbank. Diese DB entwickelt sich seit ca. 15 Jahren mit unserem System fortlaufend weiter (dadurch ist der DB-Aufbau inzwischen auch unter aller Sau
).
Für einen Spezialfall brauchte ich jetzt für eine Tabelle Funktionen, die automatisch bei allen Kunden überprüft, ob der Primärschlüssel
schon das neue Format (3 Spalten) besitzt, oder ob er noch aus 2 Spalten besteht.
Ja, ne. In dem Ergebnis ist halt in der 1. Spalte der Constraint-Name enthalten (zwar n Mal, da n Spalten, aber egal).
In der 2. Spalte ist dann der Spaltenname enthalten, also für einen Primärschlüssel mit 3 Spalten bekomme ich 3 Zeilen zurück. Reihenfolge ist in unserem Fall derzeit unwichtig und daher nicht erforderlich.
Die Spaltennamen brauche ich, um den derzeitigen Primärschlüssel auf gültigkeit zu überprüfen.
Den Constraint-Namen brauche ich, um den Primärschlüssel eventuell löschen zu können.
Folgender Ablauf also bei uns:
Ist der Ist-Primärschlüssel <> Soll-Primärschlüssel, dann lösche Alt-Primärschlüssel und lege Neu-Primärschlüssel an (zuvor Nullwerte eliminieren und Spalte auf "NOT NULL" setzen).
Ok, die Reihefolge wird so nicht berücksichtigt, ist in unserem Fall aber egal. Tiefere Zusammenhänge (ich glaube, mit
Fremdschlüsseln kann es beim löschen noch Probleme geben) gibt es bei uns auch nicht. Daher : "Egal."
Ich habe gestern Abend übrigen auch noch eine Lösung für v8 gefunden (die Lösung für v9 behalte ich so bei weils einfach funktioniert):
danke für die Ausführungen.
Ich bin kein hauptberuflicher Datenbankprogrammierer und mit den Systemtabellen habe ich mich bisher eigentlich überhaupt nicht beschäftigt (den Ansatz für diese Lösung habe ich in einen anderen Forum gefunden), aber unser System nutzt halt eine Datenbank. Diese DB entwickelt sich seit ca. 15 Jahren mit unserem System fortlaufend weiter (dadurch ist der DB-Aufbau inzwischen auch unter aller Sau
).Für einen Spezialfall brauchte ich jetzt für eine Tabelle Funktionen, die automatisch bei allen Kunden überprüft, ob der Primärschlüssel
schon das neue Format (3 Spalten) besitzt, oder ob er noch aus 2 Spalten besteht.
Anyhow, zum allgeneinen Erstaúnen willst Du ja von den PKs die Constraint-Namen haben und
das wiederum bezogen auf den Spaltennamen?!?
das wiederum bezogen auf den Spaltennamen?!?
Ja, ne. In dem Ergebnis ist halt in der 1. Spalte der Constraint-Name enthalten (zwar n Mal, da n Spalten, aber egal).
In der 2. Spalte ist dann der Spaltenname enthalten, also für einen Primärschlüssel mit 3 Spalten bekomme ich 3 Zeilen zurück. Reihenfolge ist in unserem Fall derzeit unwichtig und daher nicht erforderlich.
Die Spaltennamen brauche ich, um den derzeitigen Primärschlüssel auf gültigkeit zu überprüfen.
Den Constraint-Namen brauche ich, um den Primärschlüssel eventuell löschen zu können.
Folgender Ablauf also bei uns:
Ist der Ist-Primärschlüssel <> Soll-Primärschlüssel, dann lösche Alt-Primärschlüssel und lege Neu-Primärschlüssel an (zuvor Nullwerte eliminieren und Spalte auf "NOT NULL" setzen).
Ok, die Reihefolge wird so nicht berücksichtigt, ist in unserem Fall aber egal. Tiefere Zusammenhänge (ich glaube, mit
Fremdschlüsseln kann es beim löschen noch Probleme geben) gibt es bei uns auch nicht. Daher : "Egal."
Ich habe gestern Abend übrigen auch noch eine Lösung für v8 gefunden (die Lösung für v9 behalte ich so bei weils einfach funktioniert):
SELECT CONSTRAINT_NAME PKeyName, COLUMN_NAME ColumnName FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
where Constraint_name in (
select name from sysobjects
where parent_Obj in (
select id from sysobjects
where name like 'Tabelle'
and xtype = 'PK' 
