Posts mit dem Label Fehler werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Fehler werden angezeigt. Alle Posts anzeigen

Montag, 23. März 2009

Reservierte Namen in der Dokumentenbibliothek

Vorsicht ist geboten bei der Namenswahl für Folder in einer Dokumentenbibliothek.
Nicht jeder Name kann auf jeder Ebene vergeben werden. Leider sind die reservierten Worte, bzw. Wortbestandteile nirgends aufgelistet oder ich habe sie noch nicht gefunden.

Nicht benutzt werden sollten:

* forms (auf Root-Ebene), da dieser Folder reserviert ist für die .aspx-Seiten, mit denen Einträge in der Dokumentenbibliothek bearbeitet werden können
* die Endungen _file, _files, .files (alle Ebenen). Benutzt werden können diese Wortbestandteile allerdings, wenn nach ihnen noch Zeichen kommen, z.B. _files2. Sollte es solch ein Verzeichnis geben, wird es von SharePoint nach dem Anlegen automatisch umbenannt und ein Unterstrich angefügt. Außerdem scheint es das Objektmodell zu verwirren denn bei Operationen auf dem SPFolder-Objekt erscheinen dann z.B. solche Fehlermeldungen: "This operation can only be performed on a file; "Documents/folder1/01_Source_Files/Folder2" is a folder."

Sollte ich auf weitere in Dokumentenbibliotheken "verbotene" Worte stoßen, werde ich sie hier posten.

Freitag, 29. August 2008

DCOM-Fehler im Windows Eventlog und wie man sie wegbekommt

Seit kurzem benutze ich ein anderes Image, welches aber von jemand anderem aufgesetzt wurde, in meinem Hyper-V, da es das 64-Bit-Image irgendwie zerstört hat. Macht aber nichts, da es sowieso ein Graus war, darauf zu arbeiten.

Scheinbar wurde da beim Einrichten von SharePoint irgendeine Einstellung vergessen oder übersehen denn ich konnte mit meinem Benutzer zwar SiteCollections anlegen aber dann keine Subwebs - im Eventlog erschien dann u.a. folgende Fehlermeldung:



Anscheinend fehlen den Benutzern spbdeveloper, spwepappdeveloper und spfarmwa Berechtigungen auf eine Applikation zuzugreifen. Eine Suche nach der CLSID {61738644-F196-11D0-9953-00C04FD919C1} brachte mich auf diese Website, die den entscheidenden Hinweis lieferte: *click*

Für den Komponentendienst IIS WAMREG admin Service müssen die drei SharePoint-Benutzer lokale Zugriffsrechte haben, der folgende Screenshot zeigt den Klickweg dazu:



Der Komponentendienst in der Systemsteuerung unter Verwaltung -> Komponentendienste zu finden.

Wurden die Berechtigungen gesetzt, muss der IIS neugestartet werden.

Mittwoch, 23. Juli 2008

...Merkwürdigkeiten...

...obwohl wir an dem System in den relvanten Teilen nichts geändert haben, haben heute morgen einige der Nintex Workflow nicht mehr funktioniert. Nach dem ich mir die Workflows im Detail angeschaut habe und alle Einzelheiten geprüft habe, aber keinen Fehler gefunden habe, habe ich sie einfach noch ein mal neu publiziert. Und siehe da, es funktioniert...

Das scheint eine dieser SharePoint Besonderheiten zu sein...

Freitag, 11. Juli 2008

Fehler bei Benutzer-Auswahlfeldern, die keine sind

Höchst erfreulich ist es, wenn man zum Feierabend am Freitag noch seltsame "Fehler" gelöst bekommt und dabei sogar noch etwas lernt:

Einer Liste haben wir über unsere Solution ein UserField hinzugefügt welches wir per FeatureReceiver auf eine - vorher in einem anderen FeatureReceiver generierte - Benutzergruppe zeigen lassen um die Suche im Katalog auf diese Gruppe einzuschränken.

Das hat auch wunderbar funktioniert... Wenn ich als SiteCollection-Administrator ein neues Element innerhalb dieser Liste erstellen möchte, sieht das Formular aus, wie erwartet. Als anderer User, egal, welche Rolle (ausser dem SiteCollection-Administrator) er innehat, erscheint die "Fehlermeldung": "Das Steuerelement ist nicht verfügbar, da Sie nicht über die erforderlichen Berechtigungen verfügen."

Googeln hat leider nichts ergeben, auch das Herumspielen mit den Berechtigungen des Users oder der Gruppe, in der er Mitglied ist, blieb erfolglos.

Dann aber fiel der Groschen, als ich mich an ein früheres SharePoint-Projekt von uns erinnerte. Düster erinnerte ich mich, dort mal eine Einstellung gesehen zu haben, die schaltet, wer Mitgliedschaften einer Gruppe anzeigen darf. Und siehe da, nachdem ich über die Oberfläche die Einstellung "Jeder" vornahm, hat es plötzlich funktioniert.

Rot umrandet im unteren Bild: die "Fehlermeldung"
Grün umrandet im unteren Bild: der Soll-Zustand des Auswahlfeldes, nachdem "Jeder" gewählt wurde




Das nächste Bild zeigt die Einstellung in den Gruppeneinstellungen:



Nun galt es noch, das ganze programmatisch umzusetzen, was in drei Zeilen erledigt war:

SPGroup spGroup = siteGroups[groupTitle];
spGroup.OnlyAllowMembersViewMembership = false;
spGroup.Update();
spGroup.OnlyAllowMembersViewMembership = true; würde bewirken, dass die Einstellung "Gruppenmitglieder" gewählt wird.

Fazit: Manchmal sind Fehler gar keine Fehler im herkömmlichen Sinne. Hier muss ich wohl noch etwas mehr in die SharePoint-Denke hineinkommen. ;-)

Mittwoch, 2. Juli 2008

BDC-Felder und die Fehlermeldung HRESULT 0x80040e14

Eine Anforderung in unserem aktuellen Projekt ist es, in einer von uns erstellten Benutzerdefinierten Liste (Custom List) Business Data Catalog-Felder (BDC-Felder) anzubieten. Um sie in unsere Solution zu integrieren, sind wir bisher so vorgegangen:

  1. BDC-Feld der Liste manuell hinzufügen
  2. Liste mit Hilfe des Solution Generators extrahieren
  3. Felddefinition aus der extrahierten schema.xml übernehmen und in unsere vorhandenen .xml-Files einbinden:
  • eine s2sfields.xml, die sämtliche unserer verwendeten Website-Columns beinhaltet
  • eine s2stypes.xml, die unsere verwendeten ContentTypes beinhaltet und
  • die schema.xml, die unser Listentemplate beschreibt
Nachdem wir die Solution dann installiert hatten und einen Eintrag in der Liste vornehmen wollten, kam, nachdem wir das Formular abschickten, diese Fehlermeldung:

HRESULT: 0x80040e14

Nach einiger Verzweiflung und rumgegoogle haben wir uns dann das SharePoint-Log noch einmal genauer angesehen und sind dann auf diese Fehlermeldung gestoßen, die uns tatsächlich einmal weiter geholfen hat:

Unexpected query execution failure, error code 8143. Additional error information from SQL Server is included below. "Der '@nvarchar3'-Parameter wurde mehrmals bereitgestellt." Query text (if available): "SET NOCOUNT ON; DECLARE @ItemId int,@@iRet int,@ExtraItemSize int,@DN nvarchar(256),@LN nvarchar(128),@@S uniqueidentifier,@@DocUIVersion int,@@Level tinyint;SET @@S='91713DD8-88FA-448A-8596-67313E781F4F';SET @@Level=1;SET @@DocUIVersion = 512;BEGIN TRAN;SET @ItemId=NULL;SET @DN=N'websites/speed2sales/as1/Lists/BasicList';SET @LN=NULL;SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_AddListItem @SiteId = '91713DD8-88FA-448A-8596-67313E781F4F',@WebId='0770642C-837D-4897-AF07-1B28D3F0C212',@ListID = 'F9870FF9-DA52-40F3-A77A-80D98A7F461B',@RowOrdinal = 0,@ItemDocType = 0,@ItemId = @ItemId OUTPU...
Unexpected ...T,@ItemDirName=@DN OUTPUT,@ItemLeafName=@LN OUTPUT,@UserID = 1,@TimeNow = '20080702 13:40:20',@ServerTemplate = 100,@Basetype= 0,@Level= 1,@tp_GUID ='03863A1B-2194-41FC-911F-D85A480DC4B8',@AddNamespace=1,@CheckDiskQuota=1, @tp_ContentTypeId = ?, @nvarchar29 = ?, @nvarchar32 = ?, @nvarchar33 = ?, @nvarchar34 = ?, @int1 = ?, @nvarchar2 = ?, @nvarchar28 = ?, @nvarchar3 = ?, @nvarchar4 = ?, @nvarchar5 = ?, @nvarchar6 = ?, @nvarchar3 = ?, @nvarchar4 = ?, @nvarchar5 = ?, @nvarchar6 = ?, @nvarchar7 = ?, @nvarchar8 = ?, @nvarchar9 = ?, @nvarchar10 = ?, @nvarchar11 = ?, @nvarchar12 = ?, @nvarchar13 = ?, @nvarchar14 = ?, @nvarchar15 = ?, @nvarchar16 = ?, @nvarchar17 = ?, @nvarchar18 = ?, @int2 = ?, @nvarchar35 = ?, @datetime1 = ?, @datetime2 = ?, @datetime3 = ?, @datetime4 = ?, @datetime5 = ?, @date...
Unexpected ...time6 = ?, @datetime7 = ?, @datetime8 = ?, @float1 = ?, @nvarchar36 = ?, @int3 = ?, @ntext2 = ?, @int4 = ?, @int5 = ?, @int6 = ?, @int7 = ?, @int8 = ?, @int9 = ?, @int10 = ?, @ntext3 = ?, @nvarchar37 = ?, @tp_ID = ?, @tp_ContentType = ?, @tp_Modified = ?, @tp_Created = ?, @tp_ModerationStatus = ?, @Size = 266, @ExtraItemSize = @ExtraItemSize ,@ItemName=N'UKSH',@acl=0xF3FE000001000000000000000C00000001000000001001083000000002000000FFFFFFFFFFFFFF7F0300000041104308B000000004000000FFFFFFFFFFFFFF7F0500000061104308B000000006000000EF12433CB001000007000000001001083000000008000000FF1B5F3CB001000009000000EF1BE77EF00100400A000000FF13433CB00100000B00000021100308300000000C0000000010010830000000; IF @@iRet <> 0 BEGIN ROLLBACK TRAN; GOTO DONE; END SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_AddListItem...
Unexpected ... @SiteId = '91713DD8-88FA-448A-8596-67313E781F4F',@WebId='0770642C-837D-4897-AF07-1B28D3F0C212',@ListID = 'F9870FF9-DA52-40F3-A77A-80D98A7F461B',@RowOrdinal = 1,@ItemDocType = 0,@ItemId = @ItemId OUTPUT,@ItemDirName=@DN OUTPUT,@ItemLeafName=@LN OUTPUT,@UserID = 1,@TimeNow = '20080702 13:40:20',@ServerTemplate = 100,@Basetype= 0,@Level= 1,@tp_GUID ='03863A1B-2194-41FC-911F-D85A480DC4B8',@AddNamespace=1,@CheckDiskQuota=1, @datetime1 = ?, @Size = 0, @ExtraItemSize = @ExtraItemSize ,@ItemName=N'UKSH',@acl=0xF3FE000001000000000000000C00000001000000001001083000000002000000FFFFFFFFFFFFFF7F0300000041104308B000000004000000FFFFFFFFFFFFFF7F0500000061104308B000000006000000EF12433CB001000007000000001001083000000008000000FF1B5F3CB001000009000000EF1BE77EF00100400A000000FF13433CB00100000B00000021100308300...
Unexpected ...000000C0000000010010830000000; IF @@iRet <> 0 BEGIN ROLLBACK TRAN; GOTO DONE; END EXEC proc_ClearLinks @@S,@DN,@LN,@@Level,'6BA51930-9043-4ACC-8783-27C3FE29B6C8'; EXEC proc_ClearLinks @@S,@DN,@LN,@@Level,'15877298-3228-4D5B-A5A5-E45D53BCBC67';COMMIT TRAN; DONE: SELECT @@iRet, @ItemId "
Medium Unknown SPRequest error occurred. More information: 0x80040e14
An "nvarchar3" konnte ich mich erinnern, das taucht als Wert beim Attribut ColName in der extrahierten Felddefinition für das BDC-Feld auf:

Und da ging mir dann das Licht auf: wir hatten im Laufe der letzten Wochen öfter einige Änderungen an den BDC-Feldern vorgenommen, bzw. neue hinzugefügt, alte gelöscht usw.
Und natürlich nicht jedes mal alle Feld neu extrahiert sondern immer nur die veränderten.

Dadurch existierten dann im Code tatsächlich mehrere Definitionen unterschiedlicher BDC-Felder mit den Attributen ColName="nvarchar3".

Daraufhin änderten wir alle nvarcharXX-Einträge so ab, dass von oben nach unten nun die Zahlen in aufsteigender Reihenfolge vergeben wurden, also nvarchar1, nvarchar2, etc.

Et vóila: der Fehler war beseitigt! :-)

Darauf müssen wir aufpassen, wenn wir bei späteren Change Requests weitere BDC-Felder hinzufügen, verändern oder was auch immer.

Nachtrag: Wer lesen kann, ist klar im Vorteil: das WSS-SDK sagt zu ColName folgendes:

"Optional Text. An internal attribute that defines the mapping of the field to the physical storage name for this field. This must be a valid name in the underlying database and must be identical to the name used in the database table. If not specified, the server generates a column name that does not collide with any existing column names and that contains only characters that are allowed by Microsoft SQL Server."

Wenn wir dieses Attribut also komplett aus sämtlichen unserer Felddefinitionen entfernen, sollten wir weder jetzt noch bei zukünftigen Updates Probleme damit bekommen.