いいね!数

0

閲覧数
615

Notesクライアントで動作するシステムについて、
連番でセットされる管理番号が重複してしまう現象が発生しました。

同時アクセスで番号が重複してしまった、というのならば
Notes のシステムではよくあることですし納得できたのですが、
どうも今回はアクセス時間が数十分程度の間隔があいていて、その線は薄いようです。
(長年動作していたシステムで、今回になって現象発生報告があったというのも少し不可解ではあります)
 

同時編集以外の原因で管理番号が重複してしまうケースに遭遇されたという方はいらっしゃいますか?
 

-------

<実行環境>

Domino バージョン: 9.0.1 FP4 (Windows 2012 R2 64bit)
Notes バージョン: 9.0.1 (Windows 7 32bit)



<ソース概要>

添付した GetDOCNO.lss が管理番号の連番を取得する部分のソースになります
(実際のソースから不要部分を除去したりなどの改変はしています)

(1) 管理番号取得用のビューから、最新の番号を取得する
(2) 最新の番号に +1 した番号を新しい番号とする
(3) 管理番号取得用のビューに (2) の番号が存在した場合は再度(1)からやり直し

 

File TypeSizeFile Name
application/octet-stream 1 KB GetDOCNO.lss
サーバー情報: | クライアント情報: | 
カテゴリ:アプリ開発 - Notes アプリ | タグ:
  | 質問日時:May 24, 2016, 6:16:29 PM

回答・コメント

いいね!数

0

こんにちわ。

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

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

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

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

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

/Yac

回答日時:May 25, 2016, 8:24:07 AM

いいね!数

0

yac4423様

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

回答日時:May 25, 2016, 8:40:56 AM

いいね!数

1

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

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

 

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

 

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

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

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

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

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

 

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

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

 

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

1. GetDocumentByKeyの直前でRefreshを行う

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

3. 型変換は厳密に行う

 

いかがでしょうか。

回答日時:May 25, 2016, 10:12:52 AM

いいね!数

0

Nekoichi Kobe様


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


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

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


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

回答日時:May 25, 2016, 11:01:19 AM

いいね!数

0

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

回答日時:May 25, 2016, 4:57:26 PM

いいね!数

0

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

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


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

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


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

回答日時:May 27, 2016, 12:01:02 PM