こんにちわ。

肝心なことが書いてないので確認ですが、この関数で取得した管理番号付きの文書はどのタイミングで保存するのでしょうか？

• 文書を新規作成後、取得してすぐに保存

• 文書を新規作成時に取得するけど後で保存

• 文書保存直前に取得して保存

たぶん3番目だと思うのですが念のため確認。

/Yac

yac4423様

管理番号の付番タイミングは 1番目の「文書を新規作成後、取得してすぐに保存」 となります。
よって、文書の作成日時≒付番タイミング となり、
作成日時の間隔が開いているので同時タイミングの付番が原因とは考えにくいなと判断しています。
 

私の環境でも連番発番の処理がありますが、過去重複したのは発番後に別の処理の為に文書の保存に時間がかかってしまう為でした。

保存の直前に発番する事で回避できています。今回のお話は、保存の直前に発番しているという事で、このミスは無いという事ですね。

検索するビューのインデックスがおかしくなっている可能性もあるので、ビューの更新を最初に実施するのが良いかもしれません。

さて、ソースを拝見してバグを発見しました。

生成したキーで文書を検索した結果のNotesDocumentを格納した変数とその後のif分の変数名が違います。

タイプミスかと思われます。

この結果、折角重複確認していても必ずループせずに処理を終了しています。

おそらくこれが原因かと思われます。

変数は厳密にするため、暗黙宣言を無効にするのが良いかと思います。

また、最初にビューのRefreshを実施した方が良いのではと思います。

直接関係ありませんが、私ならこう書きます。

1. GetDocumentByKeyの直前でRefreshを行う

2. 最初のGetDocumentByKeyでの第二引数を必ず設定する

3. 型変換は厳密に行う

いかがでしょうか。

Nekoichi Kobe様

ソースのご指摘ありがとうございます。
変数名のミスタイプについては、投稿用にソース編集を行った際のミスでした。オリジナルの方は問題ありませんでした。
ただ、Option Declare による暗黙宣言無効をしていないため宣言無し変数が点在しているようなので
それは今後の課題としたいと思います。


> 直接関係ありませんが、私ならこう書きます。
> 1. GetDocumentByKeyの直前でRefreshを行う
> 2. 最初のGetDocumentByKeyでの第二引数を必ず設定する
> 3. 型変換は厳密に行う

こちらも参考にさせていただきます。


あとは「ビューが壊れてしまって、NotesView の Refresh が効かなくなっている」なんて可能性が頭をよぎったのですが
そういう事ってあるんですかね・・・？

いったん、ビューの再構築を行ってみて様子を見てみることにします。
何か進展があればお知らせします。

原因がわかりました。DBレプリカによるものだったようです。

Domino Server を運用系と待機系（ホットスタンバイ）の二台で動かしていて、
対象DBはレプリカで連動していました。


特定のユーザーが、誤って待機系の側のDBに対して操作をしていたようで、
運用系と待機系がレプリケーションされる間の時間で
運用系と待機系でそれぞれ文書が作成されて同じ管理番号になってしまっていたということのようです。

(1) レプリケーションが行われる (最新の管理番号は DN-20160009 とする)
(2) 運用系DBでAさんが管理番号 DN-20160010 の文書を作る
(3) 待機系DBでBさんが管理番号 DN-20160010 の文書を作る
(4) レプリケーションが行われる ( 運用系に Bさんの作った文書が追加され同じ管理番号の文書ができてしまう )


私自身もそういう構成で動いていることをすっかり忘れていて、
皆様に正確な情報を伝えられずの質問になってしまって申し訳ないばかりです。