Die Liste wird in der Standardansicht angezeigt. Sie kann aus einem der folgenden Gründe nicht in der Datenblattansicht angezeigt werden: Ein mit Windows SharePoint Services-kompatibles Datenblatt-Steuerelement ist nicht installiert, Ihr Browser unterstützt ActiveX-Steuerelemente nicht oder die Unterstützung von ActiveX-Steuerelementen wurde deaktiviert .

Diese Aussagen treffen leider nicht zu, da das ActiveX-Steuerelement im Browser nach wie vor korrekt installiert und geladen ist. D.h. serverseitig muss eine Einstellung generell diesen Aufruf verhindern. Warum bleibt mir erstmal verborgen. Ärgerlich, weil gerade die Datenblattansicht ein sehr hilfreiches Element zur schnellen Bearbeitung von vielen Listeneinträgen ist.

Nach einem kurzen Blick in den Quelltext habe ich den Grund für den fehlgeschlagenenen Aufruf gefunden. Für das Darstellen der ActiveX-Komponente ist ein Aufruf des HTML-Tags

if (typeof(RenderActiveX) != “undefined”)

die auch in SharePoint 2007 implementiert ist. RenderActiveX ist eine Javascript-Methode, die eigentlich in der Datei ows.js definiert sein sollte. Ein kurzer Blick in diese (der Pfad dorthin lautet: C:\Programme\Gemeinsame Dateien\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1031) erklärt den Fehler schnell: die Methode konnte nicht gefunden werden.

Da das Service Pack auch für das englische Language Pack erforderlich war, überprüfte ich auch die Datei ows.js für den englischsprachigen Pfad (Unterordner 1033). Und siehe da, dort habe ich die Funktion gefunden. Ein kurzer Test eines Aufrufs der Datenblattansicht einer englischen Site bestätigte das Verhalten, denn dort konnte die Ansicht problemlos geladen werden.

Eigentlich sollten die Inhalte dieser Dateien nicht geändert werden, dennoch hat das Einfügen des nachfolgenden Codes auch in den deutschen Sharepoint-Sites das Aufrufen der Datenblattansicht wieder ermöglicht:

function RenderActiveX(str)
{
document.write(str);
}

Der Eintrag sollte direkt nach der Methode PortalPinToMyPage erfolgen. Evtl. muss die SharePoint-Site über die Tastenkombination Shift+F5 im Browser erneut geladen werden, damit anschließend der Aufruf diesmal klappt.

Sie können eine Liste in Datenblattansicht auf einer Microsoft Windows SharePoint Services-Website nicht anzeigen.

• Eine Tabellenkomponente, die mit Windows SharePoint Services kompatibel ist, wird nicht installiert.
• Eine Microsoft Office 2003 Professional Edition ist auf dem Computer nicht installiert.
• Das Webbrowser unterstützt ActiveX-Steuerelement nicht.
• Unterstützung von ActiveX-Steuerelement wird deaktiviert.

Die zwei letzten Möglichkeiten betreffen den Browser bzw. die darin enthaltenen ActiveX-Einstellungen. Zu finden sind diese im Internet Explorer unter Extras » Internetoptionen » Sicherheit » Stufe anpassen. Dort muss für die entsprechende Sicherheitszone das Ausführen von ActiveX-Steuerelementen aktiviert sein:

Hinweis: Es empfiehlt sich, niedrigere Sicherheitseinstellungen nur für die Zone Vertrauenswürdige Sites vorzunehmen und die entsprechende SharePoint-Site über die Schaltfläche “Sites…” zu dieser Zone hinzuzufügen.

Die beiden ersten Hinweise der Fehlermeldung deuten auf eine fehlende Installation einer Tabellenkalkulation hin. Daher sollte man sicherstellen, dass entweder Office 2003 oder 2007 Professional installiert ist. Die darin erforderlichen Komponenten wären für die Version 2003 Excel und für 2007 Access. Doch selbst dann kann der obige Fehler erscheinen. Denn das ActiveX-Steuerelement kann im Office-Setup separat installiert werden. Zu finden ist der Eintrag in der Systemsteuerung unter Software. Dort das entsprechende Office-Produkt auswählen und auf ändern klicken. Anschließend sollte der Eintrag Features hinzufügen oder entfernen ausgewählt werden. In der nachfolgenden Baumstruktur findet man unter Office Tools den entscheidenden Eintrag: Unterstützung für Windows SharePoint Services. Dort sollten alle Einträge auf von ‘Arbeitsplatz’ ausführen gesetzt sein wie auf folgender Abbildung für Office 2003 dargestellt ist:

Für Office 2007 sieht der Setupeintrag folgendermaßen aus:

Oftmals wird aber auch trotz korrekter Installation dieser Komponenten ein Aufruf der Datenblattansicht mit obiger Meldung verhindert. Wie ich heute im Blog der Mindbusiness GmbH gelesen habe kann aber auch ein falscher Eintrag in der Registry das Laden des Add-ons verhindern. Dort wurde mit Hilfe des Microsoft Supports folgender Lösungsvorschlag gemacht:
Unter HKEY_LOCAL_MASCHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility einen Eintrag mit der CLSID 65BCBEE4-7728-41A0-97BE-14E1CAE36AAE suchen. Falls dieser vorhanden ist, sollte das Löschen dieses Knotens und ein Neustart des Internet Explorer nun das Problem beheben.

Der Vorteil ist, dass dieses Webpart ohne Administratorberechtigungen auf jeder beliebigen SharePoint-Seite integrierbar und mit ein wenig HTML/Javascript Kenntnissen flexibel anpassbar ist. Dazu einfach das Inhalts-Editor-Webpart an eine beliebige Stelle innerhalb einer Webpartzone einfügen und anschließend über den Toolbereich den Quelltexteditor aufrufen. Dort muss nur folgender Code eingefügt werden:

<div style="text-align:center;"><div>
<a href="http://www.google.de"><img src="http://www.google.de/logos/Logo_40wht.gif" border="0" alt="Google" align="absmiddle"></a>
<input type="text" onKeyDown="if (event.keyCode==13) submit_google();" id="google_q" size="31" maxlength="255" value="" />
<button id="btnGoogle" type="button" onclick="submit_google();">Google Suche</button></div>
<div><input type="radio" id="g_site" name="g_scope" value="1" /> diese Seite
<input type="radio" name="g_scope" value="2" checked="checked" /> Web</div>
</div>
<script language="javascript" type="text/javascript">
// <![CDATA[
function submit_google()
{
	var googleQuery = document.getElementById('google_q');
	var g_url = "http://www.google.de/search?hl=de&q=";

	if(googleQuery)
	{
		if(googleQuery.value.length > 0)
		{
			var s = encodeURI(googleQuery.value);

			if(document.getElementById('g_site').checked)
			{
				s = "site:" + window.location.host + " " + s;
			}

			var g_w = window.open(g_url+s, "google_window");
			if(g_w != null) g_w.focus();
		}
		else
		{
			alert("Bitte einen Suchbegriff eingeben.");
		}
	}
}
// ]]>
</script>

Anschließend sollte das Webpart die Google Suchmaske wiefolgt anzeigen:

Sollte der Popupblocker des Browsers das Öffnen der Suchergebnisse verhindern (weil das neue Fenster über eine Javascript-Funktion geöffnet wird), muss die SharePoint-Seite dort entsprechend als vertrauenswürdig eingerichtet werden.

In diesem Beispiel verwende ich zwei Listen, für die jeweils eine neue Ansicht in der schema.xml definiert wird:

<view BaseViewID=”2″ OrderedView=”TRUE” Type=”GRID”>
…
</view>

Wichtig sind hier die Angaben BaseViewID=”2″ (zur späteren Referenzierung beim Hinzufügen des WebParts in der onet.xml) und Type=”GRID” (damit die Ansicht standardmäßig als Datenblatt geladen wird).

Die WebParts selber werden innerhalb eines Moduls in der Datei onet.xml festgelegt:

<module Name=”datasheet_wps” Path=”DOCTEMP\SMARTPGS”>
<file Url=”spstd1.aspx” Name=”datasheet_wps.aspx” Type=”Ghostable”>
<view List=”501″ WebPartZoneID=”Main” WebPartOrder=”1″ BaseViewID=”2″></view>
<view List=”502″ WebPartZoneID=”Main” WebPartOrder=”2″ BaseViewID=”2″></view>
</file>
</module>

Innerhalb der View-Tags werden nun die weiter oben beschriebenen Listen mit der zugehörigen ID (501 und 501) angesprochen und als Standardansicht die gewünschte Datenblattansicht mit der BaseViewID 2 gewählt.

Beim Erstellen einer neuen SharePoint Site auf Basis dieser Site Definition wird nun (vorausgesetzt das Modul wird entsprechenden im Configuration-Tag geladen) eine neue aspx-Seite (datasheet_wps.aspx) erzeugt, die genau die zwei Listen-WebParts enthält. Da diese aber untereinander noch nicht verbunden sind, muss dies noch innerhalb eines Code-Abschnitts nach dem Erstellen der Site erfolgen. Voraussetzung ist natürlich, dass die Site ebenfalls programmatisch erzeugt wurde.

SPWebPartCollection wpc = web.GetWebPartCollection(web.Url + “/datasheet_wps.aspx”,Storage.Shared);
wpc[0].ConnectionID = new Guid(“00000000-0000-0000-0000-000000000001″);
wpc.SaveChanges(wpc[0].StorageKey);
wpc[1].ConnectionID = new Guid(“00000000-0000-0000-0000-000000000002″);
wpc[1].Connections = “00000000-0000-0000-0000-000000000002,
00000000-0000-0000-0000-000000000001,
ListViewFilterConsumer_WPQ_,ListViewRowProvider_WPQ_,
ListViewFilterConsumer_WPQ_,ListViewRowProvider_WPQ_,
field_consumer=field_provider”;
wpc.SaveChanges(wpc[1].StorageKey);

Voraussetzung für das Funktionieren des Codes ist ein gültiges SPWeb-Objekt (web), das die eben erzeugte Site referenziert, sowie das Vorhandensein der datasheet_wps.aspx-Seite, die die zwei WebParts in folgender Reihenfolge beinhalten muss: An erster Stelle die Liste, die den Filter vorgibt und an zweiter Stelle die Liste, die den Filter ausführt.
Für jedes WebPart muss eine (auf dieser Seite) eindeutige ID festgelegt werden. Für ein beliebiges WebPart muss außerdem der Connections-String gesetzt werden, der folgende Angaben erwartet (siehe auch http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.connections.aspx):

• ID des “Consumer” WebParts
• ID des “Provider” WebParts
• Name des “Consumer” Interfaces (legt die Art der Verbindung fest, hier: das Feld, nach dem gefiltert werden soll)
• Name des “Provider” Interfaces (muss passend zum “Consumer” Interface sein, hier: Datenzeile, die für die Filter-Id angezeigt werden soll)
• Name des “Consumer” Interfaces (siehe oben)
• Name des “Provider” Interfaces (siehe oben)
• Beziehung des Verbindung, sprich: das Feld des Providers in Beziehung zum Feld des Consumers

Damit alle Änderungen in die Datenbank geschrieben werden, muss für jedes WebPart die Methode SaveChanges der SPWebPartCollection aufgerufen werden.

 Nach einigen Tests fand ich heraus, dass die Site zwar in der Datenbank angelegt wurde, aber keiner Vorlage zugewiesen wurde und deshalb auch nicht aufrufbar war. Ein Test, die Site über die Kommandozeile anzulegen, war erfolgreich, deshalb konnte es nur am Aufruf über das Site Directory liegen. Also versuchte ich, einen neuen Eintrag in der Liste anzulegen, ohne zusätzlich eine Site zu erstellen. Und auch das klappte nicht, jedenfalls nicht über die newform.aspx. Per Datenblatt-Ansicht war ich erfolgreicher. Da aber nach dem Service Pack Update die entsprechende Site Definition selbst (diese liegt unter C:\Programme\Gemeinsame Dateien\Microsoft Shared\web server extensions\60\TEMPLATE\1031\SPSSITES\LISTS\SITESLST) nicht geändert wurde, suche ich immer noch nach der Ursache des Fehlers. Von offizieller Seite konnte ich dazu leider noch nichts hören, lediglich ein Eintrag im MSDN-Forum wies mich darauf hin, dass das Problem nicht nur auf meinem Server besteht.

Um diese großen Datenmengen aber in kleinen Häppchen verarbeiten zu können (damit man ein mögliches Script Timeout umgehen kann), gibt es die Möglichkeit, über sog. URL-Parameter (gekennzeichnet durch …aspx?param1=wert1…) die entsprechenden Werte an das Programm zu übergeben und fortlaufend hochzuzählen bis alle Vorgänge abgearbeitet wurden. SharePoint lässt standardmäßig aber keine Updates in der Datenbank zu, die in Folge dieser GET Requests entstanden sind. Folgender Fehler wird beim Versuch, dies trotzdem durchzuführen, ausgegeben:

Updates are currently disallowed on GET requests. To allow updates on a GET, set the ‘AllowUnsafeUpdates’ property on SPWeb.

bzw. auf Deutsch:

Aktualisierungen von GET-Abragen sind momentan untersagt. Um GET-Aktualisierungen zu gestatten, stellen Sie bitte die Eigenschaft ‘AllowUnsafeUpdates’ von SPWeb ein.

Dies lässt sich beim Update von Listen oder Dokumentbibliotheken relativ leicht umgehen, denn das SPSite und das SPWeb Objekt enthalten jeweils eine Eigenschaft AllowUnsafeUpdates, die durch vorheriges setzen auf true ein solches Update ermöglicht.

Ich hatte aber das Problem, dass ich eine ganze Reihe SharePoint Sites einer SiteCollection über genau diese Routine hinzufügen wollte. Und dort half das Setzen der AllowUnsafeUpdates Eigenschaft nichts. Da mir eine Lösung per Javascript am einfachsten erschien, habe ich mir überlegt, dass das wiederholte Absenden des in der SharePoint Site integrierten Formulars (was dann einem POST Request entspricht) dieser Sicherheitsüberprüfung standhalten sollte. Die Formularfelder können – ähnlich wie die Parameter beim GET Request – über Page.Request.Form["param1"] abgefragt werden. Sie müssen zuvor nur gesetzt und mit den entsprechenden Werten gefüllt werden. Aber auch das ist kein Problem, folgende Anweisung fügt ein als hidden deklariertes Formularfeld in die bestehende Seite ein:

Controls.Add(new LiteralControl("<input type="\"hidden\"" name="\"param1\"" value="\"wert1\"" />"));

Das Absenden des Formulars im Kontext des Benutzers übernimmt eine kleine Javascript Funktion, die zeitverzögert alle fünf Sekunden aufgerufen wird. Diese wird ebenfalls in den Quelltext geschrieben:

<script language=javascript>
function stepAhead()
{
document.forms[0].submit();
}window.setTimeout("stepAhead()", 5000);
</script>


Damit klappt dann auch das programmgesteuerte, wiederholte Erzeugen von Sub Sites mit integrierter Sicherheitsüberprüfung ohne auf die AllowUnsafeUpdates Eigenschaft zurückgreifen zu müssen. Voraussetzung ist, dass das benutzte Formular ein FormDigest enthält, welches die Sicherheitsüberprüfung beim Absenden von Formularen bereitstellt.

Alle anderen Dienste funktionierten aber einwandfrei und auch über den Browser konnte ich auf alle anderen Inhalte zugreifen bzw. Dokumente hochladen. Was ist also das Problem? Ich habe schon vermutet, dass es damit zusammenhängt, dass der Server über keine Netzwerkverbindung verfügt, was unter virtuellen Umgebungen wie Virtual PC oder VMware bzw. zu Testzwecken auf Standalone PCs nicht unüblich ist.

Der Grund für den Fehler ist, dass Office vor dem Übertragen der Daten prüft, ob eine Netzwerkverbindung besteht, über die die Daten zum Server geschickt werden können. Auch wenn das in meinem Fall ohne Verbindung klappen würde, bricht Office die Übertragung ab, wenn diese Prüfung negativ ausfällt.

Zur Behebung des Problems reicht eine simple Deaktivierung des Dienstes “System Event Notification” (Systemereignis-Benachrichtigungsdienst). Dafür muss in einer Kommandozeile (Start->Ausführen) folgender Befehl ausgeführt werden: net stop sens.

Eine andere Möglichkeit ist natürlich, dass man dafür sorgt, dass eine Netzwerkverbindung besteht

So liefert das Dokument tabellarisch eine Übersicht folgender Produkte bzw. Versionen:

• Windows SharePoint Services 3.0
• SharePoint Portal Server 2003
• Office SharePoint Server 2007 for Search
• Office Forms Server 2007
• Office SharePoint Server 2007 Standard CAL
• Office SharePoint Server 2007 Enterprise CAL or for Internet Site

Ausserdem werden alle Features nach folgenden Kategorien in separaten Datenblättern zusammengefasst:

• Collaboration
• Portal
• Search
• Content Management
• Business Process and Forms
• Business Intelligence
• Management
• Platform

Gerade bei der Frage nach der passendsten Lizenzierung dürfte dieses Dokument eine entscheidende Hilfe sein.

Wenn man mehrere Dokumente auf einmal aus dem SharePoint heraus (z.B. auf die lokale Festplatte) kopieren will, empfiehlt sich die Verwendung der Explorer-Ansicht. Diese zeigt eine Dokumentbibliothek in einer Ordner- bzw. Baumstruktur an wie man es im Windows Explorer gewohnt ist. Damit lassen sich auch Verschiebe- oder Löschvorgänge mit mehreren Dokumenten ziemlich einfach realisieren.

Wenn nun ein Benutzer mit Leserechten auf eine Dokumentbibliothek zugreift, kann er über die Standard View einzelne Dokumente ganz normal öffnen und auch lokal abspeichern. Über die Explorer Ansicht aber lässt sich mit alleinigen Leserechten kein Dokument kopieren, lediglich öffnen. Gibt man diesem User zusätzlich noch Schreibberechtigung auf die Bibliothek, so klappt auch der Kopiervorgang.

Da die Explorer View eine clientseitige Anwendung (ActiveX Control) darstellt, scheint keine einfache Lösung in Sicht zu sein. Über Ratschläge, Hinweise und Tipps wäre ich an dieser Stelle sehr dankbar!

Die Liste habe ich über eine Site Definition erstellt und in der Schema.xml benutzerdefinierte Felder hinzugefügt, die über das Attribut ReadOnly=”TRUE” schreibgeschützt sein sollten. Dies bewirkt laut SDK, dass diese Felder in den Formularen zum Anlegen und Bearbeiten eines Eintrages nicht angezeigt werden, aber in Ansichten dargestellt werden können. Genau, was ich wollte und eigentlich auch hervorragend funktionierte.

Bis ich die Liste und die nicht schreibgeschützten Felder über die Datenblattansicht bearbeiten wollte. Die schreibgeschützten Felder konnten zwar auch dort angezeigt werden und der Versuch, sie zu bearbeiten wurde mit der Meldung, dass die gewählten Zellen schreibgeschützt sind, unterbunden. Alle Änderungen wurden wie gewünscht übernommen und auch korrekt angezeigt. Doch die Werte der schreibgeschützten Felder, die ich programmgesteuert gesetzt hatte (so lässt sich der Schreibschutz umgehen), wurden für alle Datensätze, die zuvor bearbeitet wurden, gelöscht. Einfach weg!

Nach kurzer Suche fand ich diesen Eintrag im Microsoft Support Center. Dort wird genau das Problem beschrieben, wenn man ein schreibgeschütztes Feld über den Lists Web service erstellt. Aber der Workaround funktioniert auch für die Schema.xml. Die Lösung ist recht simpel: statt ReadOnly=”TRUE” sollte ReadOnly=”True” notiert werden, also genau auf Groß- und Kleinschreibung in diesem Fall achten.

Danach werden aber diese Feld in den zuvor erwähnten Formularen zum Anlegen und Bearbeiten der Datensätze wieder zur Verfügung gestellt und können dort bearbeitet werden. Abhilfe schaffen zwei weitere Attribute, die eingefügt werden sollten, falls noch nicht geschehen: ShowInEditForm=”FALSE” und ShowInNewForm=”FALSE”. Bitte hier wieder genau auf Großschreibung achten