過去の桐井戸端ＢＢＳ　（桐ver.８）

7663	重複禁止について	タカシ	2000/09/14-22:59
ここでのアドバイス、お蔭様でシステムに多いに有効になっています。 ｖ８ 一括無 フォームにて入力をしています。 顧客的なＩＤを使って重複禁止をかけています。 でも、１レコード入力後でないと重複禁止が有効になりません。 （説明でもそう書いてありましたが） そこで、入力項目が少なければ良いのですが、１レコード２１項目有ます、ＩＤ入力時期ははじめの方です。 重複禁止をかけた項目（ＩＤ）入力後直ぐに「重複しています」のエラーが出れば良いなぁと思っているのですが、可能でしょうかね。
7667	重複禁止について	佐田　守弘	2000/09/15-00:03
記事番号7663へのコメント タカシさん ちょっと先に確認させて頂く事になります。 顧客IDの様な項目で重複禁止を設定するという事は、これは顧客マスタの様な表ではないでしょうか。 そして、この顧客IDは、この表の主キーとなるべき項目ではないかと思うのですが。 その様な場合には、項目値を入力するのではなく桐に任せる方法、つまりカウンタ項目を使うのが適していると思います。 カウンタ項目とは、桐が自動的に値をインクリメントして、重複しない値を自動的に設定してくれる項目です。 実際には、このカウンタに設定した項目は、表示もせずに、桐に勝手に入力させます。 佐田守弘(KS-00119)
7669	Re:重複禁止について	タカシ	2000/09/15-00:57
記事番号7667へのコメント >カウンタ項目とは、桐が自動的に値をインクリメントして、重複しない値を自 >動的に設定してくれる項目です。 >実際には、このカウンタに設定した項目は、表示もせずに、桐に勝手に入力さ >せます。 初めのシステムではこの手を使いましたが、検索などで不合理が生じました。 更に、入力終了後削除した場合に連番（カウンタの作ったNO）が飛んでしまいます。 現在としては検索対応として、［元号スペル］（平成は「Ｈ」と）［顧客NO］ （ダミー項目かな？）の項目を設け、計算式に、 #全角([入校元号スペル]+#文字列([利用年])+#文字列([顧客ID])［元号スペル］＋［顧客NO］）を ［顧客ＩＤ］としてこの［顧客ＩＤ］を元に表を使って表引きなどを行っています。 ［元号スペル］と[利用年]の項目は自動生産しています。 なんか　遠回りしているようですけど 理解不明な説明ご勘弁下さい。 　　　　　　　　　　　　　　タカシ
7671	Re:重複禁止について	宮城	2000/09/15-11:34
記事番号7663へのコメント タカシさん、こんにちは。 KEV使えば、きめ細かくチェックできますよ。 ＩＤをソースとするテキストボックスのソース値更新後イベントにより次のチェックを行います。 手続き定義開始　テキストＸ::ソース値更新() 　＆行番号＝＃行番号 　絞り込み　単一化＝｛[ＩＤ]｝ 　ケース開始 　　ケース（．NOT ＃終端行） 　　　メッセージボックス　"適当なタイトル"￥ 　　　　　　　　　　　　，"ＩＤがダブっています"￥ 　　　　　　　　　　　　，アイコン＝！￥ 　　　　　　　　　　　　，ボタン指定＝１￥ 　　　　　　　　　　　　，＆応答 　ケース終了 　絞り込み解除 　ジャンプ　行番号＝＆行番号 　メソッド呼び出し　＠フォーム．更新モード設定（２） 手続き定義終了 （ここではすべて全角表記にしています。） もちろん、他にＩＤダブりはないとか、ここまでで絞り込みは行っていないという前提です。
7679	Re:重複禁止について	タカシ	2000/09/15-21:22
記事番号7671へのコメント 申し訳ございません、一括処理使えなく困っていた次第です。
7680	Re:重複禁止について	宮城	2000/09/15-22:09
記事番号7679へのコメント あの、これ一括処理じゃなくてイベントハンドラエモンなんですけど。 覚える気がなけりゃそれはしかたがありませんね
7682	主キーなどに使うID項目について（１）	佐田　守弘	2000/09/15-22:59
記事番号7669へのコメント タカシさん。 質問の主旨と少し離れるかも知れませんが、ID項目と重複禁止に関わる概念についてお話します。 （長文のため、２つの書き込みに別れます） ●データを識別するために使うID項目 言葉について先に断っておきますが、「ID項目」といった特別な言葉がある訳ではありません。 これは、例えば顧客マスタであれば、顧客を識別するために使う項目の事です。 顧客データなら、氏名などでも識別できそうですが、同姓同名の人がいないとも限らないわけで、 氏名の代わりに番号を付けて、この番号で識別しようとするのが、ID項目です。 ID項目は漢字、アルファベットで作っても構わないのでしょうが、単純な値の方がデータ処理がしやすい (速度も早い)ので、一般的には番号が使われます。 ●IDとなる項目の必要要件 それは、「項目値が重複してはならない事」。これだけです。 後から話しますが、人間がそのIDを見て、顧客名なり商品名を連想しやすい事は、必要要件ではありません。 ●IDの付け方 顧客番号、商品番号、学籍番号など、これらは全てIDとなる項目です。 ＜年号や記号を入れたID、分類の中での連番号IDの功罪＞ システムを設計しようとすると、まず先にIDをどの様につけるかの議論される事があります。 「年が分かる様に先頭２桁は年号にして、その下を連番号にする」、「商品群を大、中、小分類して その中で連番号を付ける」などがその例です。 この方法は、IDを見て、大ざっぱに中身が分かる利点があります。 このため、この様な分類付きのIDが使われて来た事もありました。 しかしこの方法は破綻するケースが少なくありません。 例えば、使える最大の連番号を超えてしまった場合とか、どの分類にすべきかが不明確な商品、 あいるは後から商品群の組み替えを行ったために、IDを振り直さなければならないケースなどです。 ＜IDは単純な連番号でよい＞ 顧客や商品の分類などには関係無く、単純に上から順に連番号を振って、それをIDとする。 これだけで、IDの必要要件を満たします。 また、仮に後から途中の番号を削除したために、飛び番号になっても構わないのです。 飛び番号であっても、重複していない事が保証されていれば、それでIDの要件は満たされます。 （次のコメントへ続く） 佐田守弘(KS-00119)
7683	主キーなどに使うID項目について（２）	佐田　守弘	2000/09/15-23:01
記事番号7669へのコメント （前コメントの続き） ●とても奇異に感じるIDの付け方であるけど この完全連番号方式のIDの概念を私が最初に知ったのは、Accessのカウンタ項目でした。 そして私は最初、これは奇異な方法だと思いました。 連番号とはある程度の識別記号があり、その後ろに連番号を付けた形とするものだと思っていたからです。 しかし、よくよく考えてみれば、IDは重複しない値である事だけが必要要件ですから、全く問題ないわけなのです。 ついでに言えば、Accessのカウンタ項目では、一度使った値は二度と使えない仕様になってました。 当初、これにも閉口しました。（桐の場合にはカウンタ項目でも値の振り直しは可能です） でも、実際にはそれで構わないのですね。 例えば印刷済みの伝票などで、連番号が予め印刷されているものを思い浮かべてみて下さい。 仮に、書き損じてそのページを破棄した場合には、その番号は欠番になります。 ●IDに使うカウンタ項目値は元来は見せる必要がない IDが完全な連番号で、しかも飛び番号を許す方式とすると、「IDを振り直して欠番をなくしてほしい」と言った声が出ます。 クライアントやエンドユーザーだけでなく、開発者がそう思う場合さえあります。 本来、IDは人間が見る必要はないのです。なぜなら、桐で言えば結合を行うときの主キー項目として、 あるいは表引きや併合を行うときの参照項目として使えば良いからなのです。 つまりシステムが識別できる値であれば、それで役割を果します。 だからIDの項目は、表示から隠してしまって見せなくするのも１つの方法です。 ●それではIDでの検索が行えないのでは 元来は、IDで検索する必要はないと思います。 氏名や電話番号などもっと分かりやすい項目で検索すればよいでしょう。 顧客の入力を行うときにも、IDを表示する必要はありません。 顧客台帳の必要な項目を別のフォームで表示し、「処理行指定」風に(処理行指定コマンドは使えない)、 画面で選び、選んだ行のIDの値を自動的に入力すればよいのです。 つまり、IDはあくまでもシステムが使う値であり、人間が見る必要はないのです。 ●ダミーのIDを作る どうしても見るためのIDが欲しければ、意味があるかどうかは分かりませんが、 人間に見せるためだけのダミーのIDを作る方法も考えられますね。 頭に適当な識別記号を付け、後ろを連番号にした見掛け上のIDです。 欠番が出たら、番号の振り直しをしますから、例えば「S-100」は先月は「佐藤」さんだったものが、 今月は「鈴木」さんになる、そんな本来のID機能を果さない見掛け上のIDです。 もちろんこれを主キーに使ったり、表引きの参照項目に使ってはいけません。 データの整合性がなくなりますから。 佐田守弘(KS-00119)
7684	検索に使うための項目とは	佐田　守弘	2000/09/15-23:02
記事番号7669へのコメント タカシさん 質問の方の話題に入ります。 ●欠番で困る事、検索で困る事とは 　>初めのシステムではこの手を使いましたが、検索などで不合理が生じました。 　>更に、入力終了後削除した場合に連番（カウンタの作ったNO）が飛んでしまい 　>ます。 と書かれておりますが、具体的にどの様な不都合なのかお知らせ下さい。 どうやらこのあたりのシステムの考え方に解決の糸口がありそうです。 ●検索対応の項目とは 検索用に年号や顧客番号などを組み合わせた項目を作っている様ですが、 この項目がないと困るのでしょうか。 桐の検索機能(絞り込みでも同じ)は、複数の項目での検索ができますから、 元来はこの様な項目はいらないと思うのですが。 佐田守弘(KS-00119)
7692	Re:重複禁止について	yasuyukis	2000/09/16-18:36
記事番号7663へのコメント 運用で簡単に逃げるとすると、 顧客ＩＤを入力直後に、Ｆ４を押して いったん表示状態にして、チェックをかけるということはできますが。。。 その後はＦ２を押して入力を継続するわけですが、 １レコードの入力につき、２タッチ増えますが、 ２１項目あるのならば、まあ最後までいくよりは、 精神衛生上はよろしいでしょう。
7694	Re:検索に使うための項目とは	タカシ	2000/09/16-22:39
記事番号7684へのコメント >質問の方の話題に入ります。 >●欠番で困る事、検索で困る事とは >　>初めのシステムではこの手を使いましたが、検索などで不合理が生じました。 >　>更に、入力終了後削除した場合に連番（カウンタの作ったNO）が飛んでしまい >　>ます。 >と書かれておりますが、具体的にどの様な不都合なのかお知らせ下さい。どうやらこの >あたりのシステムの考え方に解決の糸口がありそうです。 年間の利用顧客数がこのＩＤ的なもので把握(客観的な見方かも知れませんが)できる >●検索対応の項目とは >検索用に年号や顧客番号などを組み合わせた項目を作っている様ですが、この項目がな >いと困るのでしょうか。 平成　　　1１年　　１００番 　Ｈ　＋　１１　＋　１００ 「Ｈ１１１００」が顧客ＩＤとしている もしこの顧客（同一人）が別件顧客となった場合は、同一顧客であっても、別ＩＤが使われる。 顧客履歴的なものには、電話番号にてリンク（ホームやレポートでは）しています。 >桐の検索機能(絞り込みでも同じ)は、複数の項目での検索ができますから、元来はこの >様な項目はいらない思うのですが。 このＩＤで絞り込みし、別表に「書き出し」している様な事を、数回繰り返しています。 当然では有ますが、元表のデータからは削除（複写・コピーで）しませんが。 即察知できないような説明、ごめんなさい。 佐田守弘　様(KS-00119)
7695	Re:重複禁止について	タカシ	2000/09/16-22:48
記事番号7680へのコメント >あの、これ一括処理じゃなくてイベントハンドラエモンなんですけど。 「イベントハンドラエモン」も知らない「桐」利用者でして すみませんでした。 >覚える気がなけりゃそれはしかたがありませんね 一つ一つやっては居るのですが、なかなか理解度が乏しくて・・ いつかは・・と思って居る次第です。（今のシステムに押され気味）

戻る