View Referenzen anzeigen / suchen

[haentschman]

Hallöle...

Ich will mal aufräumen...

Wie finde ich heraus ob die Views (3x) in Benutzung oder ob das Leichen von früher sind. Die Namen sind Schei... Eine Suche über den QT bringt reichlich Vorkommen, imho nicht mit DB zu tun. Es lebe die Dokumentation.

Beispiel:
dbo.view1
Eine View ist nicht ausführbar.

Danke für Infos...

[jobo]

Versteh die Frage nicht ganz.
Was ist QT?
Geht es um Quellcode DFM Analyse in Delphi? Da müsste man mE nur eine Tool mit Batchsuche alle Viewnamen füttern oder?

Du kannst im Information Schema nach definierten Views schauen.
Im Query Cache kannst Du "sehen", welche wirklich benutzt werden.
Im Information Schema / Dictionary findest Du auch Angaben zu defekten Objekten. Sowas wie View "geht nicht, weil die Tabelle xy fehlt". Dafür gibt es auch meist Queries, die Objectabhängigkeiten zeigen, verschachtelte Views, User definierte Typen usw.

Query Cache ist mit Vorsicht zu genießen, bzw. man muss vielleicht geduldig sein.. ich weiß nicht, wie lang das gepuffert wird bei MS SQL. Notfalls löscht man am Ende Views, die erst beim Jahresabschluss benutzt werden.

Ich würde vielleicht nicht einfach alles unbenutzte löschen. Manchmal hat sich jemand was gedacht und das findet man konzeptionell in einer Reihe von Views wieder, auch wenn es aktuell keinen interessiert. Und Namen kann man ändern.

Bei großen Anwendungen haben wir tw selbst Nutzungs Logging eingebaut. Die heißen Ecken kennt man sowieso, spannend sind aber die ruhigen, wo alle sich am Kopf kratzen.

[haentschman]

Danke...

QT = Quelltext incl. PAS/DFM

Zitat:

Da müsste man mE nur eine Tool mit Batchsuche alle Viewnamen füttern oder?

siehe

Zitat:

Eine Suche über den QT bringt reichlich Vorkommen, imho nicht mit DB zu tun

Zitat:

Notfalls löscht man am Ende Views, die erst beim Jahresabschluss benutzt werden.

...genau. Ich habe mich nun entschieden, die Views als Scripte zu speichern (Ticket) und für den Notfall wieder anzulegen.

[jobo]

QT, ok
Das Vorgehen finde ich etwas gewagt.
Wenn es so gemacht wird, dass es der Nachwelt erhalten bleibt vielleicht ok.

Ansonsten ist das Aufräumen nur auf einer Seite (DB) irgendwie seltsam oder?

P.S.: Ich weiß nicht, wie MS SQL reagiert, wenn man Views (objekte) dropped, die von anderen noch verwendet werden. In manchen Systemen geht das gar nicht, andere lassen sich immerhin bequem abfragen zu den Konsequenzen oder "reparieren" auch defekte Objekte automatisch, wenn die Umgebung wieder passt. Jedenfalls kann man beim Droppen vielleicht schauen, ob man gerade ganz unten am Jenga Turm etwas gezogen hat oder wirklich nur irgendwas verkümmertes erwischt hat.

[haentschman]

Zitat:

Ansonsten ist das Aufräumen nur auf einer Seite (DB) irgendwie seltsam oder?

Ich habe nix im Quelltext gefunden was mit den Views zusammenhängt. Selbst die alten SQL, die schon abgekündigt sind, haben keine Referenz.

Und Tschüß View...

[Redeemer]

Gefährlich bei MSSQL ist auch, dass MSSQL bei Views keine Spalten über den Namen ansprechen kann. Beim Speichern eines Views werden alle Spaltennamen verworfen und durch Spaltennummern ersetzt. Fügst du also eine Spalte in einer Tabelle oder einem View ein, zerschießt das alle Views, die Spalten nutzen, die hinter der eingefügten sind.

Lösung ist dann, die Views zu öffnen und ohne jegliche Änderung zu speichern. Dann übersetzt MSSQL die Spaltennamen aus dem getrennt gespeicherten Quelltext wieder in die aktuellen Spaltennummern.

Dafür wäre aber halt auch wichtig zu wissen, wo man das machen muss.

[jobo]

cooles Feature!

Ist das bei aktuellen Versionen so?

Spricht wie so oft für ein simples alter table add column, also Kommandozeile..

[Redeemer]

Also ich hab das Problem mit 2019.
Auf die Idee, einfach alle Views einer Datenbank zu Öffnen und zu Speichern und das zu automatisieren, bin ich noch nicht gekommen.
Man müsste auch noch gucken, ob das Problem bei Objekten des Typs Programmierbarkeit auch passiert. Sonst könnt man statt eines Views einfach eine „Tabellenwertfunktion mit einer Anweisung“ nehmen.

(Weniger) lustig ist übrigens auch, dass SSMS den Originalquelltext beim Speichern scheinbar möglichst hässlich und unleserlich macht, indem es wahllos Absätze, Einrückung, Klammern und optionale reservierte Wörter wie „AS“ einfügt, „SELECT *“ auflöst, aber wiederum andere Klammern und alle Kommentare löscht. Meines Wissens ist das nicht abschaltbar. Das ist aber kein Bug Feature von MSSQL sondern von SSMS und passiert erst nach dem Speichern und nach dem Öffnen. Den Originalquelltext des Views kann man – manchmal – in Heidi angucken. Wenn Heidi denn funktioniert. Wenn es nicht gerade ums Einfügen, Ändern und Löschen von Daten geht (dann aber bitte keine Bits im PK), ist auf Heidi bei MSSQL leider kein Verlass. Wenn Heidi eine View-Definition anzeigen kann (und nicht nur ein leeres Eingabefeld zeigt), sind da immer mehrere Absätze am Anfang des Quelltextes, aber das stört ja nicht. Ich frag mich bloß immer, wie die da reinkommen.

[Redeemer]

Zitat von Redeemer:

Also ich hab das Problem mit 2019.
Auf die Idee, einfach alle Views einer Datenbank zu Öffnen und zu Speichern und das zu automatisieren, bin ich noch nicht gekommen.

Vermutlich kann man es wohl einfach so machen:

Code:

SELECT MODS.DEFINITION FROM SYS.OBJECTS OBJ
JOIN SYS.SQL_MODULES MODS ON OBJ.[OBJECT_ID]=MODS.[OBJECT_ID]
/* JOIN SYS.SCHEMAS SCHS ON OBJ.SCHEMA_ID=SCHS.SCHEMA_ID */ -- nur nötig, sollte man nach Schema filtern wollen: SCHS[.NAME]='dbo'
WHERE OBJ.TYPE='V' 
AND MODS.DEFINITION IS NOT NULL /* rausfiltern, wo das Recht SHOW VIEW fehlt */

Dann ersetzt man in jedem Ergebnis das erste CREATE , was kein Kommentar ist, durch ALTER und führt das Ergebnis als Befehl aus. Oder sehe ich da was falsch?

Zitat von Redeemer:

Den Originalquelltext des Views kann man – manchmal – in Heidi angucken. Wenn Heidi denn funktioniert.

Lag an meinen Rechten.

[jobo]

Bei Oracle war/ist es eigentlich auch so. Wenn man das DM ändert (natürlich auch views), gehen abhängige Objekte u.U. "kaputt" (invalid). Aber es läuft gleichzeitig ein Mechanismus, der sie wieder heilt, spätestens wenn man in aufruft oder wenn man die Objekte (die kaputt sind) explizit "recompiled". Funktioniert eigentlich fast geräuschlos, außer bei komplexeren Modellen.
Für Views habe ich mir deshalb angewöhnt, die Sourcen in einer einzigen Quelldatei zu verwalten, die man notfalls immer durchjagen kann. Ist nur bei Selbstreferenzen manchmal nicht erfolgreich. Dann am besten einzelne Objekte recompilieren.

Das ist am Ende ziemlich ähnlich zu dem Ansatz, den Du mit Deinem SQL Statement zu Fuß machst.