Sharepoint:ユーザーが作成/編集したすべてのドキュメントを検索するSQL

StackOverflow https://stackoverflow.com/questions/281373

  •  07-07-2019
  •  | 
  •  

質問

特定のユーザーIDによって作成/タッチされたすべてのドキュメントを表示するために、Sharepoint 2003で機能するクエリを探しています。

ドキュメントを含むテーブル(Docs)とユーザー用のテーブル(UserInfo、UserData)が見つかりました しかし、その関係は少し奇妙に思えます-userdataテーブルには99,000レコード、userinfoには12,000レコードがあります-400人のユーザーがいます!

400のレコードを持つユーザーテーブルとの単純な1対多の関係を期待しており、それをドキュメントテーブルに結合していると思いますが、そうではありません。

ご協力いただければ幸いです。

編集: ありがとう、ビヨン、 そのクエリをSharepoint 2003の構造に変換して戻しました。

select 
d.* from 
userinfo u join userdata d 
on u.tp_siteid = d.tp_siteid  
and 
u.tp_id = d.tp_author 
where
u.tp_login = 'userid' 
and
d.tp_iscurrent = 1

これにより、siteid / listid / tp_idのリストが取得されます。これらをファイル名/パスまでトレースできるかどうかを確認する必要があります。 すべて:追加のヘルプは引き続き歓迎します!

役に立ちましたか?

解決

SharePoint 2003のデータベースを見たことはありませんが、2007年にはUserInfoはサイトに接続されています。つまり、すべてのユーザーが各サイトコレクション(または2003の同等の概念)のUserInfoに行を持っています。そのため、ユーザーが何を行うかを特定するには、そのサイト内のサイトIDとユーザーIDの両方が必要です。 2007年には、次のようなことから始めます。

select d.* from userinfo u 
join alluserdata d on u.tp_siteid = d.tp_siteid 
and u.tp_id = d.tp_author 
where u.tp_login = '[username]'
and d.tp_iscurrentversion = 1

更新:他の人がここに書いているように、SharePointデータベースに直接アクセスすることはお勧めしませんが、頭を使って注意してください。更新はすべて大文字です。ただし、選択はコンテキストによって異なります。

他のヒント

直接SHAREPOINTデータベースを照会しないでください!

それを十分に明確にしたのだろうか? :)

C#で利用可能なオブジェクトモデルを実際に確認する必要があります。SiteCollectionのSPSiteインスタンスを取得し、SPSiteおよびSPWebオブジェクトに属するSPListインスタンスを反復処理する必要があります。

SPListオブジェクトを取得したら、必要なユーザーをフィルタリングするクエリを使用してGetListItemsを呼び出す必要があります。

これは、あなたが望むことを行うためのサポートされている方法です。

SharePointはそのためにまったく設計されておらず、データベースの構造がバージョンとアップグレード間で同じであるという保証はありません(実際には特定の警告があります)ため、データベースに直接アクセスしないでください。さらに、コンテンツがファーム内の複数のコンテンツデータベースに分散している場合、あるコンテンツデータベースで実行されるクエリが別のコンテンツデータベースで期待どおりに動作するという保証はありません。

繰り返しのオブジェクトモデルを見るとき、作成したSPSiteおよびSPWebオブジェクトをdispose()する必要があることに注意してください。

ああ、はい、400人のユーザーがいるかもしれませんが、30のサイトがあると思います。情報はサイトごとにデータベースで繰り返されます... 30 x 400 =データベースの12,000エントリ。

Sharepointでそのクエリを使用する場合、コンテンツデータベースでビューを作成するか、データベースに対して直接クエリを実行することは、大したことではないことを知っておく必要があります。回避策は、オブジェクトモデルを反復処理し、結果を独自のデータベースに書き込むカスタムコードです。これは、タイマーベースまたはイベントトリガーに基づくことができます。

ロックを使用してSELECTを実行しないでください。つまり、クエリにWITH(NOLOCK)を追加する必要はありません。システムの一部の部分は非常にタイムアウトに敏感であり、システムが予期していなかったロックの導入を開始すると、システムが異常な状態になることがわかります。

しかし、実際には、オブジェクトモデルを介してこれを行う必要があります。 IronPythonのようなものをめちゃめちゃにしたり、OMを使って実験したりするのは、実に快適です。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top