Nachinstallieren von Visual Studio 2008 Komponenten schlägt fehl

Bei einem Kunden mussten DLLs in VB.NET und nicht C# erstellt werden, weswegen ich bei meiner Visual Studio Installation VB.NET hinzufügen wollte.

Leider scheiterte das, sowohl über Systemsteuerung > Software > Visual Studio 2008 > Ändern als auch beim Starten von der Visual Studio DVD.

Jeweils scheiterte bereits das Hochfahren der Setup-Komponente.

Am Anfang werden ja etliche Sachen in der Setup-Komponente geladen und getestet und mitten dabei brach das Setup ab, so dass ich nicht einmal zur Auswahl der Komponenten gelangte.

Glücklicherweise fand ich den Link http://blogs.msdn.com/heaths/archive/2008/10/06/adding-features-to-visual-studio-2008-may-fail-to-load-setup-components.aspx, der genau dieses Problem beschreibt.

Man kann entweder alle Patches von Visual Studio 2008 entfernen oder am besten Visual Studio 2008 Service Pack 1 installieren.

Migration SSAS 2005 > 2008: Class not registered – Fehler

Wenn man eine SSAS-Datenbank von SQL 2005 auf SQL Server Analysis Services 2008 migriert, taucht gerne folgender Fehler auf, der aber eine nicht auf Anhieb durchschaubare Fehlermeldung hat:

Die Migration geht an sich gut. Hat man die SSAS-Datenbank dann aber auf den neuen Server mit SSAS 2008 deployt, so bereitet die Datenbank nicht auf, sondern scheitert mit folgendem Fehler:

Class not registered beim Aufbereiten
(Zum Vergrößern auf das Bild klicken)

Der Fehler tritt nur auf, wenn die Daten auf dem SQL Server liegen und nach der Migration auf dem Zielserver keine SQL Server 2005-Installation mehr vorhanden ist.

Ursache ist, dass in der Data Source als OLEDB Treiber der SQL Server Native Client in der Version 2005 angegeben ist, aber auf dem neuen Zielserver nicht mehr installiert ist.

Alte Verbindung mit 2005er Treiber

Man kann einfach den Treiber auf die aktuelle Version 2008 (10.0) ändern. Dann funktioniert wieder alles (egal ob die zugrundeliegende Datenbank noch SQL Server 2005 ist oder auch auf SQL 2008 migriert wurde):

Verwendung des neuen Treibers von SQL 2008

Verhalten von Views bei Strukturänderungen der zugrundeliegenden Tabellen

Ein View, der mittels * alle Spalten einer verwendeten Tabelle zurückgibt, wie z.B.

CREATE VIEW dbo.testView
AS
SELECT u.*, k.name as Kunden_Name, k.AnzahlKinder
FROM umsatz u
INNER JOIN kunde k
ON k.kunde_id = u.kunde_id

verhält sich überaschend, wenn sich die Tabellenstruktur der zugrunde liegenden Tabellen ändert. Die Metainformationen aktualisieren sich nämlich nicht automatisch, was sogar zu Datentypsverletzungen führen kann.

Nehmen wir an, die Tabelle umsatz aus obigen Beispiel habe folgenden Inhalt:

Inhalt der Tabelle Umsatz

Damit liefert die Abfrage des Views

SELECT * FROM testView

folgende Daten:

Inhalt des TestView original

Wird nun in der Tabelle umsatz eine Spalte Rabatt hinzugefügt (und mit Werten gefüllt), liefert das SELECT überaschender Weise:

nach Hinzunahme der Spalte Inhalt des Views

Dabei fällt auf, dass die Spaltentitel die ursprünglichen Inhalte haben, d.h. Rabatt ist nirgends zu sehen, die Werte der Spalten sind aber falsch: In der Spalte Kundenname steht nun der Rabatt und im Feld AnzahlKinder (Datentyp ist eigentlich int!) steht nun der Kundenname.

Das Aktualisieren der Views geht einfach: Nach

exec sp_refreshview 'testview'

sieht wieder alles richtig aus.

Hat man mehrere Views, in einer Datenbank, kann man über

select 'exec sp_refreshview ''' + name + '''' from sysobjects
where xtype = 'V'

sich die notwendigen SQL-Statements automatisch generieren lassen, die man dann einfach ausführt.

Einige Hinweise:

  • Views können natürlich verschachtelt sein, d.h. ein View greift auf einen anderen View zu. Dann müssen die Refresh-View-Statements in der richtigen Reihenfolge oder einfach mehrfach ausgeführt werden.
  • Clustered / Indexed Views können nicht refresht werden – das Statement liefert einen Fehler und muss aus der Liste der auszuführenden Statements gelöscht werden. Das Aktualisieren eines indizierten Views ist aber auch unnötig, da die zugrunde liegenden Tabellen nicht geändert werden können (da der View mit Schema Binding angelegt wurde)