Einer unserer Kunden hat ein Problem, das wir nicht reproduzieren können. Wir kopieren programmatisch die Eigenschaften eines Dokuments mithilfe von SPFile.Properties in eine Zieldatei. Aus irgendeinem Grund stimmen die Eigenschaften der Datei jedoch nicht mit den Metadaten überein, die in der Liste angegeben sind, in der die Datei gespeichert ist.
Nun können wir das wahrscheinlich lösen, indem wir SPFile.Item.Properties kopieren (noch nicht getestet), aber ich frage mich nur, unter welchen Umständen SPFile.Properties ungleich SPFile.Item.Properties ist.
Update: Wir haben gerade ein Update von unserem Kunden erhalten. Die Verwendung von SPFile.Item.Properties gibt immer die aktuellen Informationen zurück. Wir möchten jedoch immer noch die ursprüngliche Frage verstehen.
Es gibt einen kleinen Unterschied zwischen SPFile.Properties und SPFile.Item Feldern und der erste ist viel, viel langsamer zu nennen.
Sie haben höchstwahrscheinlich das "Eigenschaften" -Fenster des Microsoft Office-Dokuments gesehen (dieses - Ссылка ). Dies sind die Eigenschaften, die gelesen werden, wenn Sie auf SPFile.Properties zugreifen. Sie zu lesen ist langsam, da es eine Code-Infrastruktur gibt, die die binäre DOC-Datei analysiert und die Eigenschaften findet. (dauert bis zu 30 oder etwas Millisekunden für jede Eigenschaft Zugriff) Weitere Informationen finden Sie hier: Ссылка
In SharePoint ist jedes Element ein SPListItem und seine Feldwerte (und ich verwende hier nicht das Wort "Eigenschaften") werden in der Inhaltsdatenbank von Sharepoint gespeichert. Wenn Sie also auf SPFile.Item.Properties zugreifen, sehen Sie sich tatsächlich den SPListItem an, an den die Datei angehängt ist, und sehen Sie sich deren Eigenschaften in der SharePoint-Inhaltsdatenbank an.
Was passiert hinter der Szene, wenn Sie eine Datei hochladen, in der einige "Office-Eigenschaften" festgelegt sind, dass SharePoint sie in die gleichnamigen Felder in SPListItem kopiert. (Einige Informationen dazu hier: Ссылка )
Dies ist der Grund, warum diese Eigenschaften normalerweise den gleichen Wert haben, ABER es passiert nur, wenn SharePoint weiß, wie man Metadaten aus Ihrer Datei liest und sie zurückschreibt. Wenn Sie also eine .txt -Datei in Ihren SharePoint-Speicher legen, erhalten Sie keine SPFile.Properties zurück.
Der Benutzer wird immer die ListItem-Eigenschaften und nicht die SPFile-Eigenschaften in einer Dokumentbibliothek sehen. Das Verwenden der ListItem-Eigenschaften in der Kopie ist also der Weg zu gehen.
Ich glaube, dass dieses Problem mit der Promotion- / Herabstufungseigenschaft der Sharepoint-Eigenschaft zusammenhängt, die das Einbetten von Dokumenteigenschaften in die physische MSOffice-Datei und das Reisen mit dem Client usw. ermöglicht. Dies wird jedoch derzeit nur für Office-Dateitypen unterstützt (to mein Wissen).
Jonathan
Der Versuch, das "offiziell dokumentierte" Objekt für Sharepoint zu finden, ist ziemlich unwiderruflich. :-D. Die Online-Dokumente saugen, Sie sind besser von Blog-Einträgen usw. verwenden.
P.S. Ich stimme Alex hier zu. Obwohl ein SPFile niemals in einer Liste ohne ein begleitendes SPListItem vorhanden ist, kann die Verbindung zwischen den beiden beschädigt werden (d. H. Das Listenelement bearbeiten, aber die Datei kann nicht geöffnet werden). Dies bedeutet für mich, Informationen über die 2 ist an verschiedenen Orten in der Inhalt db gespeichert. Ich habe das schon einmal erlebt.
Tags und Links sharepoint splistitem
