code it

Martins Tech Blog

FileNotFoundException im Konstruktor von SPSite

Als ich eben den Post zu AddFieldAsXml geschrieben habe, habe ich die Beispiele in einer Konsolenanwendung nachgestellt. Das Beispiel ist nicht sehr kompliziert und doch überraschte mich SharePoint direkt in der ersten Zeile mit einer FileNotFoundException.

Laut MSDN wird eine FileNotFoundException im SPSite-Konstruktor dann geworfen, wenn die SiteCollection unter der Url nicht gefunden werden konnte. Die Url ließ sich jedoch problemlos im Browser aufrufen - sowohl unter localhost als auch unter dem Rechnernamen wurde die SiteCollection gefunden. Nächster Versuch war also, die Credentials explizit mitzugeben, auch wenn das eigentlich nicht das Problem sein dürfte, weil sowohl Browser als auch Visual Studio mit dem gleichen Nutzeraccount verwendet wurden.

Was die MSDN-Seite verschweigt: Diese Exception wird auch dann geworfen, wenn das Platform-Target nicht stimmt. Konsolenanwendungen haben in der Visual Studio Vorlage grundsätzlich erst einmal das Platform Target x86; SharePoint aber ist eine 64-bit-Anwendung, daher muss das Platform Target der Konsolenanwendung auch x64 sein, damit es funktioniert. Also die Einstellung eben geändert, neu kompiliert und schon klappt es auch von der Konsole.

Fehlermeldung beim Öffnen von Word- und Excel-Dokumenten aus Outlook

Gelegentlich bekommt man ja auch mal Office-Dokumente per Mail geschickt. Und früher funktionierte es mal, dass man diese Dokumente auch direkt aus der Mail in Outlook per Doppelklick öffnen konnte - wie gesagt früher. Aktuell ist es bei mir so, dass ich dann von den Zielanwendungen - also Word 2010 oder Excel 2010 mit diversen Fehlermeldungen beglückt werde.

Excel meldet: "Die Datei ist beschädigt und kann nicht geöffnet werden.".

Word meint: "Fehler beim Öffnen der Datei in Word."

Und PowerPoint meldet gleich: "Die Anwendung konnte nicht korrekt gestartet werden (0x000022)." und bietet mir an, die Präsentation zu reparieren.

Ursache dafür ist das Sicherheitscenter (englisch Trust Center). Dieses findet man unter Datei -> Sicherheitscenter im jeweiligen Programm. Unter dem Menüpunkt "Geschützte Ansicht" gibt es die Option "Geschützte Ansicht für Outlook Anlagen aktivieren".

Deaktiviert man diese Option, so kann man die Dateien auch wieder aus Outlook heraus öffnen.

VirtualBox und VERR_SVM_IN_USE

Vor einigen Monaten bin ich zu VirtualBox als Virtualisierungsumgebung gewechselt. Heute nun wollte ich eine virtuelle Maschine starten und wurde begrüßt mit einer schönen Fehlermeldung:

VirtualBox schien sich also mit irgend einer anderen Virtualisierungssoftware um Ressourcen zu streiten. Da ich mir sicher war, dass keine andere Software dieser Art lief, machte ich mich auf die Suche nach anderen laufenden Prozessen. 

Nach einigem Probieren wurde ich dann auch fündig: VirtualBox und der Windows Phone 7 Emulator können nicht zur gleichen Zeit auf einem Host laufen - und irgendwie ist der Emulator ja auch eine Art der Virtualisierung.

Nur 30 Sekunden

Auf den ersten Blick mag der Titel wie der Aufmacher eines Hollywood-Action-Films sein, aber eigentlich handelt dieser Post von SQL Server Managment Studio Express 2005. Nur 30 Sekunden gibt es dem Anwender, um Queries zu einem erfolgreichen Ende zu bringen, bis der Timeout kommt.

Wie lässt sich das nachstellen? Ganz einfach: Man erstellt eine etwas komplexere View und klickt dann im Kontextmenü der View auf "Open View". Kurze Zeit später erscheint folgende formschöne Meldung:

In einem solchen Fall ist der erste Ansatz meist, in den Optionen (Tools / Options) des Management Studios nachzusehen. Und da finden sich auch wirklich zwei Einträge, die den Timeout bestimmen. Der erste findet sich unter Query Execution / SQL Server und nennt sich Execution Timeout. Bei mir steht dieser schon auf 0, was laut Beschreibung "unlimited" bedeutet und damit nicht Grund des Problems sein dürfte. Der zweite Eintrag findet sich unter Designers und erlaubt laut Beschreibung das Überschreiben des Timeouts in den Tabellendesignern. Der Haken ist bei mir deaktiviert und der Wert steht ausgegraut auf 30.

30? 30 und TimeOut? Ok, kann ja sein, dass hier jemand den Haken nicht korrekt auswertet und sinngemäß könnte das "Open View" ja schon noch unter Designerbedienung fallen. Also Haken rein, Wert auf 3600 gesetzt, Management Studio neu gestartet und... (Trommelwirbel) ... nach 30 Sekunden die Ernüchterung.

Um es kurz zu machen: Anscheinend gibt es für das Problem kein passendes Eingabefeld. Ich hab letztenendes alle Einstellungen wieder zurückgesetzt und den Wert in der Registry gesetzt. Verantwortlich für diesen TimeOut ist der Wert SQLQueryTimeOut unter HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\ShellSEM\DataProject. Setzt man diesen auf einen höheren Wert als 30, so gibt man damit dem Management Studio mehr Zeit, die View zu öffnen. Problem daran: Dieser Wert wird anscheinend bei jedem Start des Management Studios zurückgesetzt - das ist also nur eine temporäre Lösung.

Laufzeitfehler 3049 beim Import von Daten in Access 2003

Vor die Aufgabe gestellt, mehrere hundert csv-Dateien analysieren, hab ich mich dafür entschieden, diese in eine Access-Datenbank zu importieren. Access bietet die integrierte Funktion DoCmd.TransferText, um CSV-Daten einfach einzulesen. Also schnell einen Fünfzeiler geschrieben, der durch alle Dateien des Ordners iteriert und für jede Datei DoCmd.TransferText aufruft. 

Nach einigen Durchläufen bekam ich allerdings "Laufzeitfehler 3049" mit der vielsagenden Meldung "Datenbank '' konnte nicht geöffnet werden". Aber welche Datenbank eigentlich? Ich importiere doch aus Textdateien und wieso steht da eigentlich kein Name? Glücklicherweise bietet mir der Dialog ja die Möglichkeit, zu debuggen. Und einmal im Sourcecode konnte ich auch schnell herausfinden, welche Datei gerade importiert werden soll - vielleicht hatte ja nur der Entwickler der Funktion im Office-Team vergessen, den Dateinamen mit auszugeben. Die Datei war dann auch schnell im Dateisystem gefunden und ich öffnete sie, um sie zu prüfen. Ergebnis: Sie war nicht gesperrt und auch im richtigen Format.

Nach einiger Zeit kam ich dann auf die rettende Idee: Vielleicht handelt es sich ja wirklich um eine Datenbank und nur der Rest der Fehlermeldung ist verwirrend. Eine Prüfung der Access-Datenbank zeigte: Die Datei war mittlerweile an die Grenzen ihrer Möglichkeiten gelangt und zu einer Größe von 2 GB angewachsen. Da diese Größe bei mir hauptsächlich daraus resultierte, dass ich zuvor einen Testlauf durchgeführt hab und zwischendurch nicht komprimiert hatte, konnte ich das Problem sehr schnell lösen durch einen Aufruf von Datenbank komprimieren und reparieren. 

Problem gelöst - aber: Eine aussagekräftigere Fehlermeldung hätte mich schneller zum Erfolg gebracht....

Das Outlook-Fenster kann nicht geöffnet werden...

Vor wenigen Tagen begrüßte mich Outlook mit der vielsagenden Meldung "Microsoft Office Outlook kann nicht gestartet werden. Das Outlook-Fenster kann nicht geöffnet werden."

Seltsam daran war, dass im Hintergrund dieser Meldung sehr wohl ein Outlook-Fenster zu sehen war, dieses aber nach einem Klick auf OK in obiger Meldung gleich wieder verschwand.

Einige Suche brachte zu Tage, dass das Profil neu erstellt werden muss oder XML-Dateien korrupt sind oder oder oder....

Aber alle diese Hinweise brachten mich zu keinem Erfolg. In einem letzten Aufbäumen der Kreativität versuchte ich dann noch die Reparatur-Kommandozeilenoptionen von Outlook selbst und siehe da - mit outlook.exe /resetnavpane hatte ich Erfolg und Outlook startet seitdem wieder normal.

Was tun bei Fehler 4046 bei der Anmeldung am SQL-Server?

Eben war man noch am SQL-Server angemeldet und konnte mit seinen Datenbanken arbeiten und im nächsten Moment bekommt man bei der Anmeldung diese Meldung präsentiert:

Die Meldung ist recht eindeutig: Jemand - vielleicht sogar man selbst - hat die Default-Datenbank des Benutzers gelöscht. Wird keine andere Datenbank angegeben, so versucht SQL-Server den Benutzer an dieser Datenbank anzumelden. Diese Einstellungen kann man in den Eigenschaften des jeweiligen Logins vornehmen:

Welche Möglichkeiten bestehen nun, wieder auf den Server zu kommen, um zumindest mit den anderen Datenbanken zu arbeiten oder die fehlende Datenbank wiederherzustellen?

Möglichkeit 1
Die wohl einfachste Möglichkeit ist, den Datenbankadministrator (DBA) zu bitten, die fälschlicherweise gelöschte Datenbank aus einem Backup wiederherzustellen. Wichtig dabei ist, dass die wiederhergestellte Datenbank den gleichen Namen hat wie die zuvor gelöschte Datenbank, denn in den Eigenschaften des Logins wird der Datenbankname als Text gespeichert.

Möglichkeit 2
Sollte es kein Backup geben, so kann man auch eine neue Datenbank mit dem gleichen Namen erstellen und allen relevanten Logins wieder Zugriffsrechte auf dieser Datenbank einräumen. Das ist allerdings nur in Ausnahmefällen sinnvoll - man kann sich dann zwar wieder anmelden, hat aber eine leere Datenbank.

Möglichkeit 3
Hat der Benutzer noch auf andere Datenbanken Zugriffsberechtigungen, so kann auch im Login-Dialog selbst der Name der Datenbank angegeben werden zu der sich Managementstudio verbinden soll. Die Einstellung dazu findet man im Tab Connection Properties (dazu ggf. vorher auf Options klicken):

Ist man dann auch noch mit administrativen Rechten ausgestatten, kann man nach erfolgreichem Login die Einstellung unter Login Properties selbst auf einen korrekten Wert ändern.

Möglichkeit 4
Man kann auch einen netten Kollegen mit administrativen Rechten oder eben den DBA bitten, die Default-Datenbank unter Login Properties auf einen gültigen Wert zu ändern.

Möglichkeit 5
Hat man sich als Administrator selbst ausgesperrt, kann man die Login-Properties auch per sqlcmd setzen. Dazu verbindet man sich zunächst mit sqlcmd zu einer existierenden Datenbank (z.B. master) und ändert dann per ALTER-LOGIN-Statement die Eigenschaften seines Logins:

sqlcmd -d master -U sa -P sapassword

und dann

alter login sa with default_database = master

Wenn Applikationen versuchen, eine Datenbankverbindung aufzubauen, sollte der Hersteller by design schon darauf achten, im ConnectionString eine Datenbank anzugeben und sich nicht blind darauf zu verlassen, dass die Login-Properties korrekt gesetzt sind. Daher sollte diese Meldung auch nur beim Login über solche Tools wie Management Studio o.ä. vorkommen.

Backup schlägt fehl

Bevor ich heute ein Update meines Projektes auf die neue Version vornehmen wollte, wollte ich als vorbildlicher Entwickler ein Backup der bestehenden Daten vornehmen. Doch der Aufruf des Backup-Befehls im Kontextmenü der Datenbank im Management-Studio brachte mir diese Fehlermeldung:

 

Auch der angegebene Hilfelink brachte keine weitere Hilfe – außer dass das Backup fehlgeschlagen ist.

 

 Ein Blick in die laufenden Prozesse zeigt den Übeltäter

select [session_id], [start_time], [text]
from sys.dm_exec_requests r
cross apply sys.dm_exec_sql_text(sql_handle) t

Bereits seit einer Woche läuft ein Prozess, der nicht erfolgreich abgeschlossen werden konnte.

Dieser blockiert das neue Backup. Also lautet die Devise: Den alten Prozess killen, eine Weile warten und dann erneut versuchen…

Ungültige Werte für Eingabeparameter?

Nach längerer Zeit hab ich mich nun auch mal wieder mit einem MS-Access-Problem auseinander gesetzt. Mein bestehendes Projekt besteht aus einer ADP im Frontend und einer Datenbank auf Basis von SQL-Server 2005 im Backend.

Einige der Anwender bekamen folgenden Fehler, wenn sie Daten in ein Formular eingeben wollten:

1. Lösungsversuch – Ist die Datengrundlage aktualisierbar?:

Die Datengrundlage des betroffenen Formulars ist eine Sicht aus mehreren Tabellen, die mittels INNER JOIN verknüpft sind. Wenn hier die Einstellungen nicht korrekt sind, ist die Sicht nicht aktualisierbar. Ich öffnete die Sicht also im SQL-Server und versuchte Daten einzugeben. Nachdem ich alle NOT-NULL-Felder ausgefüllt hatte, wurde der Datensatz in meiner Tabelle erfolgreich angelegt. Daran konnte es also nicht liegen.

2. Lösungsversuch – Stimmen die Eigenschaften im Formular?

Wenn man mit aktualisierbaren Sichten als Datengrundlage arbeiten möchte, ist es wichtig, dass a) die Primärschlüsselspalten mit in der Sicht sind und b) die Eigenschaft UniqueTable des Formulars auf die Tabelle gesetzt ist, in die Access die Daten einfügen soll. Aber auch das war korrekt eingestellt. Wieder nichts… Aber gegen diese generellen Probleme sprach auch, dass es bei einigen Nutzern funktioniert und nur bei einigen anderen nicht.

3. Lösungsversuch – Ist an den Eingabeparametern wirklich was falsch?

Die Meldung sagt, dass Eingabeparameter falsch sind. Und dass ich in Statuswerten nähere Informationen finde. Leider sagt sie eben nicht, wo ich die Statuswerte finde. Also machte ich mich auf dem herkömmlichen Weg auf die Suche nach ungültigen Eingabeparametern. Vielleicht geben die Nutzer wo es auftritt ja im Formular etwas anderes an und der Fehler ist nicht korrekt abgefangen. Per Fernwartung schaute ich beiden Benutzern bei der Eingabe auf den Monitor und konnte keine Unterschiede feststellen. Alles war ausgefüllt und alles waren logische Werte. Trotzdem kam die Meldung. Wieder Sackgasse…

4. Lösungsversuch – Unterschiedliche Nutzer = unterschiedliche Berechtigungen?

Unterschiedliche Nutzer können ja auch unterschiedliche Rechte auf Datenbankobjekten haben. Also prüfte ich die Berechtigungen auf dem SQL-Server. Hier gab es einen Unterschied: Die Benutzer die keine Probleme hatten, waren in der Rolle db_owner für diese Datenbank. Die anderen waren in einer eigenen Rolle, die auf den Tabellen SELECT-, INSERT-, UPDATE- und DELETE-Berechtigung hatten. Da nicht alle Benutzer in die Gruppe db_owner genommen werden sollten, galt es nun, herauszufinden, welche Berechtigung noch notwendig ist, damit Access Inhalte einfügen kann. Nach einer kurzen Probierphase hatte ich die Lösung:

Benutzer, die über eine Sicht in einem Access-Formular Daten eingeben sollen, müssen auf der zugrundeliegenden Tabelle zusätzlich die Berechtigung “View Definition” haben, damit Access die Werte korrekt einfügen kann.

Nicht aktivierbares Feature “Office SharePoint Server Publishing Infrastructure”

Für einen Test hatte ich in meiner Site Collection das Feature “Office SharePoint Publishing Infrastructure” (Office SharePoint Server-Veröffentlichungsinfrastruktur) deaktiviert. Leider gestaltete sich das erneute Aktivieren dieses Features ertwas schieriger als erwartet. Nach einiger Zeit erschien ein sehr aussagekräftiger Fehler, der besagt, dass der Vorgang leider nicht erfolgreich war.

 

Auch der Hinweis, es erneut zu versuchen, brachte keinen Erfolg.

Was die Benutzeroberfläche nicht hinbekam, schaffte stsadm. Folgende Befehle in der Kommandozeile eingegeben und das Feature war wieder aktiv:

stsadm -o activatefeature -filename publishing\feature.xml -url http://mysiteurl -force
stsadm -o activatefeature -filename publishingresources\feature.xml -url http://mysiteurl -force
stsadm -o activatefeature -filename publishingSite\feature.xml -url http://mysiteurl -force
stsadm -o activatefeature -filename publishingweb\feature.xml -url http://mysiteurl -force
stsadm -o activatefeature -filename publishinglayouts\feature.xml -url http://mysiteurl -force
stsadm -o activatefeature -filename navigation\feature.xml -url http://mysiteurl -force