0

ライブラリ コンテンツをFilenet Content ServicesからFilenet P8に移行しています。

そこで、フォルダ ツリーとドキュメント リストの両方を XML 形式で出力するエクストラクタを作成しました。各ドキュメントには、バージョン、プロパティ、および親フォルダが含まれています。このエクストラクタは、FileNet オブジェクトを仮想化する自作の dll に依存しています。

ドキュメントはこの方法で取得されます (巨大な sql リクエスト):

Public Function getAllDocumentIds() As ADODB.Recordset
  Dim cmdProperties As New Dictionary

  cmdProperties.Item("Maximum Rows") = 0
  cmdProperties.Item("Page Size")    = 0

  Set getAllDocumentIds = _
    executeADOQuery("SELECT idmId,            idmVerFileName, "  & vbNewLine & _
                    "       idmVerCreateDate, idmAddedByUser"    & vbNewLine & _
                    " FROM FNDOCUMENT ORDER BY idmId ASC", & _
                    cmdProperties)
End Function

ただし、この方法で親フォルダーを取得すると問題が発生します (例として使用するために少し変更されています)。

Public Function getFolders(document As IDMObjects.document) As Collection
  Dim f As IDMObjects.Folder
  ' [...]
  For Each f In document.FoldersFiledIn '
    ' folders retrieval
  Next
End Function

少量のドキュメントの場合、いくつかの「間違った」親フォルダ(「[ドキュメントが] ファイリングされているフォルダ」) が報告されます。

次の方法では、ドキュメントがファイルされていることが報告されないため、「間違っています」（コードもわずかに変更されています）：

Public Function getDocumentIds(folder As IDMObjects.Folder) As Collection
  Dim rs As ADODB.Recordset
  Dim cmdProperties As New Dictionary

  ' Actually there is a control here, to prevent Filenet crashing.
  ' Indeed, setting "Page Size" to 0 crashes if no results are returned.
  ' *Maybe* a product bug.

  cmdProperties.Add "SearchFolderName", internalObject.id ' Folder parent
  cmdProperties.Item("Maximum Rows") = 0 ' No limits
  cmdProperties.Item("Page Size") = 0 ' No limits. Crashes if Recordset is empty

  ' Here, the cmdProperties entries are copied to an
  ' ADODB.Command object, into the "properties" member.
  ' The query are copied to this object, into the "CommandText" member.
  ' Then ADODB.Command.Execute is invoked and returs an ADODB.RecordSet.
  ' So this Recordset contains all documents filled in this folder.
  Set rs = executeADOQuery("SELECT * from FnDocument", cmdProperties)

  Exit Function

End Function

より多くのリソースが必要になる可能性がある回避策に取り組んでいます (ドキュメントごとに再確認してください...)。しかし、同じ結果が得られない理由を理解することは、ライブラリをチェックすることに関連している可能性があります。

4

1 に答える 1

1

私が問題を正しく理解していれば、結果セット内の親レコードと子レコードの論理的な順序はクエリでは保証できないというのが簡単な答えだと思います。IDシーケンスについて仮定しています。ドキュメントは移動できるため、フォルダー ID がドキュメント ID の前に発生すること、またはその逆になることを保証するものは何もありません。大規模なドキュメント セットの場合、再帰なしでこれを解決するには、親なしで子レコードを延期し、後で解決します (サンプルでは、​​センチネルを使用してそのようなレコードにフラグを立てたりフィルターをかけたりしました)。「孤立した」行の数に応じて、これをメモリ内で実行できる場合と、2 回目のパスが必要な場合があります。getrows メソッドを使用すると、特に XML を使用していてメモリ不足を避けたい場合に、「巨大な」データセットを処理できます。

于 2016-06-17T19:52:31.973 に答える