私はロータスドミノにフィールドを持つアプリケーションを持っています
UNIDID -数値(計算)...
新しいエントリが作成されるたびに、このフィールドが 1 ずつ増加し、新しい値が新しいレコード ドキュメントに保存されるようにしたいと考えています。
UNIDID フィールドの最後のエントリを取得する @dbcolumn 式があります。
mFind:=@DbColumn("" : "NoCache" ; @DbName ; "lkpEmpMasterbyOnlyUnidCode";1);
mFind をインクリメントして「UNIDXXXX」の形式で送信するにはどうすればよいですか?
特定の質問に答えるには：
lastEntry := @Subset(mFind;-1); "UNID" + lastEntry;
ただし、次の 2 つの点について考慮する必要があります。
「UNID」は、ノーツおよびドミノで非常に特殊な意味を持つ用語です。これは、すべてのデータベース内のすべてのドキュメントに自動的に割り当てられるユニバーサル ID を指します。アプリケーションでこの用語を別の目的で使用すると、いつか他の Notes エキスパートがアプリケーションを調べなければならないときに、混乱を招く可能性があります。
連続した ID を割り当てる最善の方法は、サーバーに任せることです。つまり、空のフィールドでドキュメントを保存し、新しいドキュメントと編集されたドキュメントで実行され、空のフィールドをチェックし、必要に応じて次に使用可能な ID を割り当てるエージェントを作成します。一度にデータベース内で実行できるエージェントは 1 つだけであり、一度に 1 つのドキュメントに対してのみ機能するため、同じ一意の ID で同時に保存された 2 つのドキュメントを持つことができないことが保証されます。これの欠点は、エージェントが実行される前にユーザーにシーケンシャル ID を表示できないことです。
IBMerAndreGuirardによって書かれたNotes/Dominoの連番の包括的な取り扱いを読んでください。彼は、連続番号付けに@DBColumnを使用することでパフォーマンスが大幅に低下すると考えており、代替アプローチのアルゴリズムとコードを提供しています。
リスト2のコードを使用して、「Number Generation OnDemand」という見出しの下でアプローチすることをお勧めします。ドキュメントのロックはやり過ぎです。番号付けドキュメントが読み取られてから変更されたかどうかを検出し、それに応じて対応するだけで十分です。
この数式は私のテクニカル ノート データベースからのもので、フォームの構成時に計算されたフィールドを使用して順次増加する数値を生成するため、ユーザーは数値を確認できますが、ドキュメントを保存するときにのみ固定されます。
T_List:=@DbColumn("" : "NoCache"; ""; "RefNumView"; 1); @If(@IsNewDoc & @Elements(T_List)=0;1;@IsNewDoc & !@IsError(T_List);@Subset(T_List;1) + 1;RefNumber)
ビューにレコードがない場合、上記のコードは1から番号付けを開始します。
データベースはノーツ 4.5 で開発されましたが、私は今でも 8.5 のノーツ クライアントとデザイナーで使用しており、式を変更する必要はありませんでした。実際、それ以降のすべてのバージョンで何年にもわたって何度も再利用されてきました。ドキュメントが複数のサーバーで作成されている場合、スケジュールされたエージェントが真に一意の連続番号を取得する唯一の方法であるため、機能しません。