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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93545
Url: https://administrator.de/forum/primaerschluesselabfrage-von-mssql-2005-auf-2000-v9-nach-v8-portieren-93545.html
Ausgedruckt am: 02.05.2025 um 14:05 Uhr
2 Kommentare
Neuester Kommentar
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 = 0
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:
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 = 0
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