Zitat:
Original erstellt von blacky1985:
Okey, wäre toll, wenn einer mir da noch das Skript ein wenig erklären könnte.
Servus Blacky,
deine Ungeduld sei mit einer um so ausführlicheren Antwort belohnt. Sei mir nicht böse, aber gerade mal ein Tag Wartezeit, noch dazu wenn den Beitrag am Freitag Abend postest, muss schon drin sein.
also erst mal zum Skript:
ALTER TABLE PART ADD T_BEZ5 VARCHAR(30) NULL GO
Der Tabelle PART wird das Feld T_BEZ5 hinzugefügt, als Textfeld mit maximaler Länge von 30 Zeichen.
IF EXISTS (
SELECT * FROM tempdb..sysobjects
WHERE id=OBJECT_ID('tempdb..#tmpErrors'))
DROP TABLE #tmpErrors
Es wird geprüft, ob die Tabelle #tmpErrors in der Datenbank tmpdb existiert. Falls ja, wird diese Tabelle gelöscht.
Zur Erklärung: Tabellennamen, die mit einem #-Zeichen beginnen, sind temporäre Tabellen mit lokaler Gültigkeit. Temporäre Tabellen werden vom SQLServer in der tempdb-Datenbank abgelegt.
CREATE TABLE #tmpErrors (
ERROR INT, MODULE VARCHAR(30), OBJECT VARCHAR(128), POSITION INT, DESCRIPTION VARCHAR(256))
Die Tabelle #tmpErrors wird angelegt, mit den angegebenen Feldern.
SET XACT_ABORT ON
Sort dafür, dass fehlerhafte Transaktionen mit einem Rollback rückgängig gemacht werden, somit ist das explizite führen von Transaktionen nicht notwenig.
IF EXISTS (
SELECT * FROM tempdb..sysobjects
WHERE id=OBJECT_ID('tempdb..#AIM_UPD_VIEWS'))
DELETE FROM #AIM_UPD_VIEWS
Prüfung, ob die temporäre Tabelle #AIM_UPD_VIEWS existiert, falls ja, wird deren Inhalt gelöscht.
ELSE CREATE TABLE #AIM_UPD_VIEWS (ALIAS sysname NULL, PCOLUMN sysname NULL, CHANGE_REQUEST VARCHAR(3))
falls diese Tabelle nicht existiert, wird sie angelegt.
INSERT INTO #AIM_UPD_VIEWS (ALIAS, PCOLUMN, CHANGE_REQUEST) VALUES ('T_BEZ5', 'P.T_BEZ5', 'ADD')
Der Tabelle #AIM_UPD_VIEWS wird ein neuer Eintrag hinzugefügt.
EXECUTE aim_update_view 'VIEW_PART'
EXECUTE aim_update_view 'VIEW_ALL_PART'
EXECUTE aim_update_view 'VIEW_XREF_CHILD_PART'
EXECUTE aim_update_view 'VIEW_XREF_CHILD_PART_EDIT'
EXECUTE aim_update_view 'VIEW_XREF_PARENT_PART'
EXECUTE aim_update_view 'VIEW_XREF_PART'
EXECUTE aim_update_view 'VIEW_XREF_PART_CLASS'
Die gespeicherte Prozedur "aim_update_view" wird mehrmals mit diversen Parametern aufgerufen, und zwar jeweils mit den Namen jener Views, in denen das neue Feld der PART-Tabelle hinzugefügt werden soll.
Nun zu deinen Fragen:
Meiner Meinung müsste dieses Skript auch auf SQL2000 problemlos laufen, zumindest die Syntax stimmt. Wie sieht also deine Fehlermeldung aus bei einem SQL2000?
Zum Anpassen der Views:
PSP spricht bei einem Großteil seiner Abfragen an die Datenbank die Views an, nicht die Tabellen. Deshalb ist es notwendig, ein neues Feld einer Tabelle in den entsprechenden Views ebenfalls verfügbar zu machen.
Das Anpassen der Views über den EnterpriseManager ist nicht gerade komfortabel. Das Schreiben von SQL-Skripts dazu ist zwar möglich, aber auch da muss immer die ganze View-Definition wieder herangezogen werden, das einzelne Ändern der Views bleibt also im Prinzip erhalten.
Es gäbe allerdings die Möglichkeit, sich die DDL (= Data Definition Language, also die SQL-Definition des Objekts) der Views aus den Systemtabellen auszulesen. Die DDLs findest in der Systemtabelle syscomments, wenn ich mich recht erinnere.
Wenn du weißt wie die Views aufgebaut sind und nach welchen Schlüsselwörten du suchen musst bzw. kannst, so kannst du mit SQL-Funktionen die bestehende SQL-Definition in Textbausteine zerstückeln. Anschließend fügst du die neuen Textbausteine, sprich das neue Feld, ein, fügst das ganze wieder zu einer gültigen SQL-Anweisung zusammen, und führst die neue Anweisung aus. Schon hast du eine neue View.
Ich hatte mir zu meinen aktiven PSP- bzw. Compass-Zeiten genau ein solches Skript geschrieben, bis ich kurz darauf bemerkte, dass die Prozedur aim_update_view eigentlich auch genau das macht. Dazu wird zunächst die Tabelle #AIM_UPD_VIEWS erstellt und mit den Informationen gefült, welches Feld mit welchem Alias an eine View angefügt oder aber auch von einer View entfernt werden soll. Die Prozedur aim_update_view liest diese Tabelle aus, und je nach CHANGE_REQUEST wird die View, deren Namen im Parameter angegeben wird, entsprechend angepasst, nach oben beschriebenem Schema.
Eventuelle Fehlermeldungen werden von der Prozedur in die Tabelle #tmpErrors geschrieben, der Inhalt von #tmpErrors am Ende der Prozedur ausgegeben, um dem Anwender eine Rückmeldung zu geben, ob das Skript funktioniert hat.
Mit dem System, die DDL auszulesen und dynamisch zu manipulieren, ließe sich in weiterer Folge auch die Herausforderung bewerkstelligen, automatisch alle Views anpassen zu lassen, die auf einer bestimmten Tabelle basieren, eben z.B. alle Views, die die PART-Tabelle verwenden. Diesen Aufwand würde ich mir allerdings sparen. Wenn man sich ein wenig mit dem Aufbau der PSP-Datenbank beschäftigt, und das muss man so oder so wenn man die Daten oder Objekte dort manipulieren will, so hat man den Dreh eigentlich recht schnell raus und weiß irgendwann einfach, welche Views auf welche Tabellen zugreifen. Die PSP-Datenbank ist doch recht einfach gestrickt und beinhaltet nicht sonderlich viele Objekte.
------------------
An Optimist Is A Person Who Has Not Been Shown All The Facts Yet!!!
[Diese Nachricht wurde von WolfgangE am 11. Mai. 2008 editiert.]
[Diese Nachricht wurde von WolfgangE am 12. Mai. 2008 editiert.]
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP
Foren auf CAD.de (alle Foren)
| 
