View verhält sich merkwürdig bis idiotisch :-|

[Bart Simpson]

Ich verwende den SQL Server 2000 und benutze zum Datenanzeigen eine kleine View die im Prinzip genau die Daten einer Tabelle 1:1 wiedergibt. Einziger Unterschied zur Tabelle ist, dass die View zusätzlich 2 berechnete Spalten anfügt die auf Benutzerdefinierten Funktionen innerhalb des SQL Servers beruhen. Diese machen ein paar Berechnungen über best. Spalten der Tabelle und geben ihr Ergebniss wieder. Im wesentlichen sieht's also so aus:

SELECT Tabelle1.*,
Func1(Tabelle1.Wert1,Tabelle1.Wert2) AS Calc1,
Func2(Tabelle1.Wert1,Tabelle1.Wert2) AS Calc2,
FROM Tabelle

Wobei die Funktionen jeweils int-Werte zurückgeben (Normalerweise <> 0).
Wenn ich nun im Query Analyzer das SQL Statement ausführe, klappt alles wunderbar. Packe ich das Ganze aber in eine View dann ist Calc1 und Calc2 plötzlich 0!

Ich dacht mir schon ich spinne, aber es kommt noch besser... Der besseren Lesbarkeit halber hab ich die View nochmal überarbeitet (aber _nichts_ verändert!) und siehe da, plötzlich geht's.
Na schön, denk ich mir war wohl doch ein Fehler den ich übersehen hab, kann ja sein... 2-3 Wochen später: Plötzlich geht wieder nichts mehr. Selbes Problem, selbe Auswirkung.
Doch diesmal war ich schlauer: View zum bearbeiten öffnen, Leerzeichen rein & wieder löschen (sprich: verändert, aber wieder absolut identisch), speichern...und es geht.
Bin mal gespannt wie lang es diesmal dauert.

Kennt jemand dieses Phänomen? Irgendwelche Ratschläge?

Bart Simpson

[shmia]

Strukturänderungen (Löschen, Einfügen, Ändern von Felder) an Tabelle1 bringen die
View durcheinander.
Dann muss man die Views refreshen.

Dazu folgende stored procedure:

SQL-Code:

CREATE PROCEDURE spRefreshAllViews
(
     @TableName    nvarchar(128) = NULL,
     @OwnerName    nvarchar(128) = NULL
)
AS
/*
     Aktualisiert alle von einer Tabelle abhängigen Sichten
     der aktuellen Datenbank via sp_refreshview
*/
     DECLARE
         @cViewName            nvarchar(128),
         @cOwnerName           nvarchar(128),
         @fullname             nvarchar(256),
         @msg                  nvarchar(255)

     SET NOCOUNT ON

     IF @TableName IS NULL
         SELECT @TableName = '%'
     IF @OwnerName IS NULL
         SELECT @OwnerName = USER_NAME()

     DECLARE curViews CURSOR FOR
         SELECT DISTINCT VIEW_SCHEMA, VIEW_NAME
         FROM INFORMATION_SCHEMA.VIEW_TABLE_USAGE
         WHERE TABLE_SCHEMA LIKE @OwnerName AND TABLE_NAME LIKE @TableName

     OPEN curViews
     FETCH NEXT FROM curViews INTO @cOwnerName, @cViewName
     WHILE (@@fetch_status <> -1)
     BEGIN
         IF (@@fetch_status <> -2)
         BEGIN
             SELECT @fullname = quotename(@cOwnerName) + '.' + 
quotename(@cViewName)
             PRINT @fullname

             EXEC ('sp_refreshview ' + '''' + @fullname + '''')
         END
         FETCH NEXT FROM curViews INTO @cOwnerName, @cViewName
     END
     CLOSE curViews
     DEALLOCATE curViews
     RETURN 0
GO

Du könntest deine View auch mit dem Attribut SCHEMABINDING versehen,
um Strukturänderungen zu blockieren:

SQL-Code:

CREATE VIEW [ < database_name > . ] [ < owner > . ] view_name [ ( column [ ,...n ] ) ] 
WITH SCHEMABINDING
AS ...

[Bart Simpson]

Gilt also hier der alte Werbeslogan "It's not a bug, it's a feature" ???



Heisst Das dass ich _alle_ Views (die auf die Tabelle zugreifen) aktualisieren muss, wenn ich eine Tabelle verändere??? Auch wenn's die View(s) gar nicht betrifft, weil ich z.B. nur weitere Felder hinzugefügt habe?
Da freu ich mich jetzt schon auf zukünfitge Änderungen...

Trotzdem, vielen Dank für den Hinweis. Nur noch eine Frage: Ist das eine persönliche "Entdeckung" oder gibt's das auch irgendwo nachzulesen? Z.B. in der Online Hilfe zum SQL Server?

Bart Simpson

[shmia]

Zitat von Bart Simpson:

Heisst Das dass ich _alle_ Views (die auf die Tabelle zugreifen) aktualisieren muss, wenn ich eine Tabelle verändere??? Auch wenn's die View(s) gar nicht betrifft, weil ich z.B. nur weitere Felder hinzugefügt habe?

Nein, nur die abhängigen Tabellen sind betroffen.
CREATE VIEW xyView AS SELECT TabelleA.*, TabelleB.cxdf FROM TabelleA INNER JOIN TabelleB ON ....

Bei Änderungen an TabelleA muss die View auf jeden Fall refreshed werden.
TabelleB ist weniger kritisch, da nur ein Feld entnommen wird.
Die View wird sozusagen intern compiliert und als Objektcode gespeichert.
Und wenn dann der * in der Feldliste auftaucht wirds kritisch.

Zitat von Bart Simpson:

Trotzdem, vielen Dank für den Hinweis. Nur noch eine Frage: Ist das eine persönliche "Entdeckung" oder gibt's das auch irgendwo nachzulesen? Z.B. in der Online Hilfe zum SQL Server?

Na ja, aber sehr versteckt:
Hinweise (Topic CREATE VIEW)
Wenn eine Sicht von einer Tabelle (oder Sicht) abhängt, die gelöscht wurde, erzeugt SQL Server eine Fehlermeldung, falls jemand versucht, die Sicht zu verwenden. Wenn eine neue Tabelle (oder Sicht), deren Struktur sich nicht von der vorherigen Basistabelle unterscheidet, erstellt wird, um die gelöschte zu ersetzen, wird die Sicht wieder verwendbar. Wenn sich die Struktur der neuen Tabelle (oder Sicht) ändert, muss die Sicht gelöscht und neu erstellt werden.

[Bart Simpson]

Hmm... wer suchet der findet! Zumindest scheint die Online-Hilfe so aufgebaut zu sein

Was mich aber wundert: Warum tut das der SQL Server eigentlich nicht selbständig? Er führt doch wunderbar Buch darüber welches Objekt von welchem Objekt abhängt usw. Es wäre doch ein leichtes einfach die Neucompilierung gleich mit anzustossen, wenn Sie schon nötig ist, oder? Aber das bleibt wohl das sahnige Geheimnis von Microsoft

Naja, egal... Vielen Dank jedenfalls. Da wär ich vermutlich Ewigkeiten lang nicht draufgekommen, weil ich gar nicht erst an der Stelle nach der Ursache gesucht hätte.

Bart Simpson