問題タブ [documentum]

Webtop 6.5 sp3 で新しいドキュメントを作成しようとすると、composer を使用して作成およびインストールしたカスタム オブジェクト タイプが表示されません。

ただし、DA でカスタム タイプを確認でき、DA でそれらのカスタム タイプを使用してドキュメントを作成できます。

「types」ノードの da にも表示されます。

catalina の下の tomcat キャッシュと c:/documentum/cache の下の documentum キャッシュをクリアしようとしました。

Documentum Developer Edition 6.6 を使用しています。(DFS を使用して) 次の DQL 式を実行する必要があります

「dm_document」から「r_version_label」、「i_chronicle_id」、「i_position」、「r_modify_date」、「subject」、「title」、「r_object_type」、「object_name」、「r_object_id」を選択します。ここで、FOLDER (ID('0cde75d180000107')) and "r_object_type"='dm_document' order by "r_modify_date" asc, "i_position" desc

しかし、Select が返すオブジェクトの最初の N 個だけが必要です。繰り返します: 行ではなく N 個のオブジェクトです (これは、結果の属性の r_version_label が繰り返し可能なフィールドであるため重要です)。

次の DQL を使用してこれを実行しようとしました: select "r_version_label","i_chronicle_id", "i_position", "r_modify_date" , "subject","title","r_object_type","object_name","r_object_id" from "dm_document"ここで、FOLDER (ID('0cde75d180000107')) および "r_object_type"='dm_document' は、"r_modify_date" asc、"i_position" desc ENABLE (OPTIMIZE_TOP , RETURN_TOP ) で並べ替えられます

しかし、私が見たのは、返されたのはオブジェクトではなく行でした。これは、Documentum Server にデフォルトのパラメーター return_top_results_row_based (=true) があるためです。server.ini のパラメーターを変更することは私には受け入れられません。return_top_results_row_based が何であれ、同じように動作するアプリケーションを作成する必要があります。

RETURN_TOP の代わりに、RETURN_RANGE、SQL_DEF_RESULT_SET、および FETCH_ALL_RESULTS を試しましたが、それらの N も行です。

だから、今私はこれを行う唯一の方法を見ています。次の DQL を使用します。 ID('0cde75d180000107')) および "r_object_type"='dm_document' 順 "r_modify_date" asc, "i_position" desc ENABLE (OPTIMIZE_TOP , RETURN_TOP )

結果の処理中、アプリケーションは返されたオブジェクトの最初の N 個のみを使用します。「OPTIMIZE_TOP」によって、使用しないオブジェクトを読み取る時間が最小限に抑えられることを願っています。私の DBMS は MSSQL です。DQL リファレンスには、「 OPTIMIZE_TOP 」が MSSQL に影響を与えると書かれています。

多分誰かがより良い解決策を提案できますか?

tomcatを起動すると、次のエラーが発生します。

この問題を解決するにはどうすればよいですか？

tomcat を使用して Eclipse で webtop 6.5 sp3 を起動するとエラーが発生します。DFC jar は既にクラスパスとビルドパスに追加されています。Web アプリケーションにアクセスすると空白のページが表示される

これを解決する方法についてのアイデアはありますか?

Documentum Developer Edition 6.6 を使用しています。次の DQL を実行しました: select "r_object_id", "r_modify_date", "r_version_label","i_position" ,"object_name" from "dm_document" where FOLDER (ID('0bde75d18000cfa4')) and "r_object_type"='dm_document' order by "r_modify_date" asc, "i_position" desc

DQL は dm_documentum オブジェクトごとに 1 つの行を返します。この DQL を使用した以前のリクエストでは、ドキュメントごとに卵が 1 つずつありました。しかし、今日私が見たのは、一部の dm_document オブジェクトでは 1 行しか返されなかったということです。一方、他の dm_document オブジェクトでは、オブジェクトごとに複数の行が返されます! 次のように:

09de75d18000d514 7/28/2011 3:41 PM 1.0,CURRENT -1,-2 Doc1 09de75d18000d515 7/28/2011 3:41 PM 1.0 -1 Doc2 ... 09de75d18000d515 7/28/2011 3:41 PM Doc2 現在 -

つまり、09de75d18000d514 では 1 つの行 (配列として繰り返し可能な「r_version_label」と「i_position」を含む) が返されましたが、別のドキュメント 09de75d18000d515 では繰り返し可能なプロパティが別々の行として返されました。バグ – ドキュメント 09de75d18000d514 と 09de75d18000d515 には本質的な違いがないため、通常の dm_document インスタンスであり、それ以上のものではありません。

さらに重要な質問は、私に何ができるかということです。DQL から「"i_position" desc」を削除すると、問題が解消されることがわかります。各 dm_object が単一の行として返されます。しかし、「i_position」の対応する値に従って「r_version_label」をソートするには、この「「i_position」desc」ソートが必要でした (「r_version_label」配列の各項目は、その「位置」を含む「i_position」配列の項目に対応します)。番号"）。「"i_position" desc" を指定したため、Documentum は "i_position" に応じて "r_version_label" を順序付ける必要がある」という私の仮定は間違っていたのでしょうか? もしそうなら、これに対処する唯一の方法がわかりました:

• 「"i_position" desc」なしで DQL を使用しています</li>
• 私のソフトウェア (DFS を使用) は、「i_position」からのインデックスを使用して、DQL が結果をもたらした後、「r_version_label」アイテム自体をソートします。

たぶん、より良い解決策が利用可能ですか？

Webtop を使用して仮想ドキュメントをチェックアウトする場合、[ルートおよび読み取り専用の子孫] オプションがあります。Documentum Foundation Services (DFS) を使用して同じ機能を実現するにはどうすればよいですか?

ありがとう、

寧

私は奇妙な問題に直面しています。私が望むのは、DFC で新しいフォルダーを作成することだけです。しかし、コード (JUnit またはアプリケーション内) を実行すると、フォルダーは作成されず、驚くべきことに例外はスローされません。したがって、エラーは別の場所にあると思います。

これは私のコードです:

見返りに sysobject id を取得していますが、dql ステートメントでそれを取得しようとすると、それが見つかりません。

代わりに、フォルダーを作成する dql create クエリを実行しようとしました。これは JUnit や実行中のアプリケーションでは機能しませんが、手動で実行すると簡単に機能します。

これは私の getSession() メソッドです

それに関するアイデアはありますか？

次のバージョンラベルを持つドキュメントをエクスポートしています：「V1、CURRENT、1.2」

しかし、エクスポートしたXMLドキュメントには次のテキストしか含まれていません：dctm：version_label="CURRENT"。

すべてのバージョンラベルをXMLにエクスポートする方法を知っている人はいますか？私は次のコードを使用しています：

ありがとうございました。

Documentumアプリケーションでオブジェクトを取得する場合、長い時間がかかります。データソースochで長時間実行クエリオプションをアクティブにしましたが、以下のクエリに時間がかかりすぎることがわかりました。

ご覧のとおり、テーブル「a」はポリシーテーブルであり、7つのレコードしかありません。object_id両方の「または」演算子の後のSQLステートメントで、テーブル「a」で100個の間のオブジェクトを探しています。クエリを実行し、テーブル "b"（systemObjects）でそれらのオブジェクトを検索したところ、これらのオブジェクトがテーブルbに属していることがわかりました。

上記のクエリには約17分かかります。テーブルの「または」演算子の後のテーブルの名前をbに変更した場合、10秒しかかかりませんでした。

このクエリは間違っていると思います。Documentumのバグなのか、Documentumの設定が間違っているのかはわかりません。このSQLまたは関連コンポーネントを作成するDQLをどこで見つけることができるかわかりませんか？何か案が？

documentumdm_methodがあります

期間600秒でdm_jobを介して呼び出されます。しかし、私の方法は600秒以上動作する可能性があります（ユーザーによって生成された入力データのサイズによって異なります）

Javaで実装されたdm_methodでmax_timeoutを超えた場合はどうなりますか？

DFCジョブマネージャーはThread.interrupt（）を送信しますか？DFCはジョブの終了を待機し、警告のみをログに記録しますか？Documentumのドキュメントに詳細な説明が見つかりませんでした。