自前の採番処理をするとリレーションが

自前の採番処理を作成するのが初めてなので質問したいのですが

自前の採番処理をしてオートナンバー型を主キーで使用しないようにすると、リレーションが、参照整合性のところが設定出来ません。自動連鎖更新など。
これは、普通のことでしょうか？

あと、MainとSubのFormがある場合、Subフォームでの自動採番処理はどのようにすれば良いでしょうか？

よろしくお願いします。

No.8 ベストアンサー 回答者： f_a_007 回答日時： 2014/11/23 07:17

Q1、売上が確定するとは、入金された時ということでしょうか？

A1、それは、私ではなく会社に聞くべき事柄。

私は、一般論として発生主義としか言えません。

Q2、どこで、どうやって帳尻を合わせたらいいのでしょうか？
A2、それも、私ではなく会社に聞くべき事柄。

私は、帳尻を合わせる必要はさらさらないと思いますよ。
そのための、見積り金額からの自由の確保ですから・・・。

この回答へのお礼

いろいろとご説明して頂き、大変ありがとうこざいます。

見積書の金額が請求金額と違う場合は有りうるということで、それで見積書の金額を修正するかしないかも、依頼元会社との相談次第となるようです。
見積書が変えられない場合には、自社持ちとなりうる。
見積書でも、請求書でも、マイナスの金額とその摘要欄をもうけて対処するのが良いのかと今考えていますが・・・

お礼日時：2014/11/28 10:36

No.7 回答者： f_a_007 回答日時： 2014/11/22 19:52

＞「見積金額 <> 売上金額」となるような事例は？

ゼロであって欲しいが、希に色んな原因で起こり得る。ですから、システムとしては「「見積金額 =売上金額」という考え方は皆無。

そういうことです。

この回答への補足

fa007様

ご回答ありがとうございます。
それでは、
＞「見積金額 <> 売上金額」となるような事例は？
ゼロであって欲しいが、希に色んな原因で起こり得る場合
見積が完了した後、売上が確定するとは、入金された時ということでしょうか。
そして、入金された時に、例えば、区分で、「値引き」「追加作業代金」などなど、調節するということなのでしょうか。その分は、見積金額で修正し直すのでしょうか？
どこで、どうやって帳尻を合わせたらいいのでしょうか。

よろしくお願いします。

補足日時：2014/11/22 22:45

No.6 回答者： f_a_007 回答日時： 2014/11/22 19:31

>「見積金額＝売上金額」

このようなケースになる事例は、どんなものがあるのでしょうか？

皆無！

この回答への補足

>>「見積金額＝売上金額」
>このようなケースになる事例は、どんなものがあるのでしょうか？
>
>皆無！

大変もうしわけありません。質問を書き間違えていました。お時間をとらせてしまって。

「見積金額 <> 売上金額」となるような事例は、どんなものがあるのでしょうか？
が聞きたかったことです。

宜しくお願いします。

補足日時：2014/11/22 19:33

No.5 回答者： f_a_007 回答日時： 2014/11/22 17:39

質問2) また、マスターと他のテーブルがリンクしないのが原則とおっしゃるのは、全てのマスターで同じであるということですか。

a:言っている意味が違います。

例えば、＜商品マスター.単価=売上伝票.単価＞というような事をリンクでもって実現するのは厳禁ということです。それ以上でも、それ以下でもありませんよ。

理由１：「商品マスター.単価」の登録においてミスがないとは限らないから。
理由２：参照すれば事足りるから。

リレーショナルデータベースにおいてリンクをはるのは当たり前のこと。でも、なんで「見積金額＝売上金額」という前提でリンクを張るのか？それが解せないということ。でも、それは、そこそこの事情。貼られてもOKかと思いますよ。

この回答への補足

お忙しい中、ご説明して頂きまして大変ありがとうございます。

>例えば、＜商品マスター.単価=売上伝票.単価＞というような事をリンクでもって実現するのは厳禁
商品マスターの単価は、見積もり時に、指標となる単価として項目をセットをして、その単価から、実際の単価を入力すような作りにしようかと考えています。

>「見積金額＝売上金額」
見積金額＝売上金額としてリンクはまだしていませんが、売上は、一工事に関しては、実際の精算処理で、算出した値になると思います。その算出値は、見積の親と子のテーブルより取得しますが、見積したあとで工事の追加料金などが発生する場合がありますので、そのような場合に対応できる項目を追加しなくてはと考えています。

>「見積金額＝売上金額」
このようなケースになる事例は、どんなものがあるのでしょうか？もし、ご経験の中から何かありましたら、ご教授願います。


よろしくお願いします。

補足日時：2014/11/22 19:02

No.4 回答者： f_a_007 回答日時： 2014/11/22 15:32

【見積台帳】

ID
名前
年月日
・・・

【見積明細】

ID
見積台帳_ID
区分
件名
見積金額

この場合、

メインフォーム＝見積台帳
サブフォーム＝見積明細

＞受付テーブルに、見積明細の親の情報を項目として作成しようかと

そういう発想そのものに疑義有り。止めはしませんが・・・。

理由１：

見積＝作成主義。
受付＝発生主義。

見積は、自社の裁量で作成した時点でデータベースに登録。
受付は、顧客との契約が成立した時点でデータベースに登録。

理由２：

マスター：随意情報の入力する際の固定的な参照データ。
随意情報：マスターデータからは独立した流動的であるが確定データ。

つまり、マスターデータは参照すれどリンクせずが原則中の原則です。

この回答への補足

ご回答大変ありがとうございます。

>見積＝作成主義。
>受付＝発生主義。

ご指摘の点、とても参考になります。

>つまり、マスターデータは参照すれどリンクせずが原則中の原則です。

質問1)　マスターデータのIDは、それを使用する他のテーブルで、IDとして項目を設けています。もし、マスターデータの主キー(a)と、Bテーブルの外部キー(a')がリンクしていないのなら、Bのフォームでは、そのIDを項目として設けていると、それに対応する名称などは、フォーム上ではどのように取得したら良いのでしょうか？

例）
Aマスター
　・主キー a
　・名称AA
Bテーブル
　・主キー b
　・外部キー a'
※　a と a'は、リンクしていない

その場合
Bフォーム
　・主キーb
　・外部キー a'
　・テキストボックスで、マスターの名称AAを表示したい

質問2) また、マスターと他のテーブルがリンクしないのが原則とおっしゃるのは、全てのマスターで同じであるということですか。

質問3) マスターがテーブルとリンクしていない場合、マスター画面で選択したIDをどうやって呼出元のフォームで取得すればよいでしょうか？

以上、よろしくお願いします。

補足日時：2014/11/22 17:03

No.3 回答者： f_a_007 回答日時： 2014/11/22 13:19

うーん！

A-Bの関係がよく分かりませんが・・・。
だとしても、全く問題はないと思いますよ。

※B=親、C=子でちゃんとフォームを生成できますよ！

この回答への補足

◆AテーブルとBテーブルの関係
A: 受付情報を受付ID　1個に対して入力します。
・受付ID
B: 受付情報のID　1個に対して、見積情報を作成する場合の親テーブルを作っています。
・見積ID(1:1）
・見積の合計金額
C：見積明細テーブル
・見積明細ID
・見積ID

◆親フォームの親IDと子フォームの親IDが連動しなかった理由
BフォームとCフオームでIDキーが連動しなかった理由は、もしかすると、リレーションシップの設定で、「参照整合性」→「フィールドの連鎖更新」のチェックボックスにチェックが入れられなかったのが原因かということに気づきました。

そもそもここで、何故、参照整合性が出来なかったかというのは、おそらく、AテーブルとBテーブルが1:1の関係で各IDキーのリレーションシップを設定しようとしていたのに、IDの列に入っていた値が、AとBで違っていたからでした。
Aテーブル→IDの列に、1-10が入っていた
Bテーブル→IDの列に、1しかなかった

これでは、1:1の参照整合性のリレーションシップは作れませんよね。
大変、すみませんでした。お手数をおかけしまして。私のミスです。


◆見積の親テーブルはどれにすればよいか

受付ID(A): 見積ID(B) = 1:1
見積親テーブルの見積ID: 子テーブルの見積ID = 1:多

このようにしなくても、受付テーブルに、見積明細の親の情報を項目として作成しようかと思いましたが、しかし、見積は見積の親テーブルとして情報を持つのが良いのかと思って、わざわざ、見積親テーブルというのを作りました。

このようなIDのリレーションの仕方（テーブルの分け方）は、普通しますでしょうか？それとも、違う仕方をしていますか？

よろしくお願いします。

補足日時：2014/11/22 13:46

No.2 回答者： f_a_007 回答日時： 2014/11/21 18:17

【補足に対する答え】

１、オートナンバー型は一切使ったことがありません。

でも、書かれているような不具合については経験したことがありません。
そもそも、オートナンバー型なんて商用のソフトでは利用しないと思いますよ。
そして、自動採番ってのも商用のソフトでは当たり前のこと。
それで、不具合が出るようじゃ使えたもんじゃーありません。
ですから、何らかの二重のミス。

第一のミス・・・主キー設定ミス。
第二のミス・・・それに気づかないでリレーション設定が出来ないと思っているミス。

２、ちょっと意味が・・・。

＞保存ボタンなどを押した時に、
＞親フォームのIDを取得して、
＞サブフォームの親IDにもセットする事をしなくてはいけないでしょうか？

疑問１、なぜ、保存ボタンを押す必要があるのか？
疑問２、なぜ、親フォームのIDを取得する必要があるのか？
疑問３、なぜ、サブフォームの親IDにセットする必要があるのか？

私の経験では、メイン・サブのフォームアプルケーションを完全に非連結で書くのは不可能。膨大なクラスライブラリを書けば、関数オーバーヘッドが発生するのは必至。ですから、完全な非連結ってのはありえない。「ちょっと意味が・・・」という理由です。

この回答への補足

ご回答ありがとうございます。

1について
私の説明が不明瞭ですみませんでした。
リレーションシップが作れないというのではなくて、リレーションシップが創れるけども、参照整合性のチェックボックスにチェックが入れられないという意味です。

テーブルの主キーと、それを外部キーとして参照する別のテーブルをリレーションシップでつなごうとスル場合、片方がオートナンバーでないと、参照整合性にはチェックが入れられないのでしょうか？

2.
>疑問１、なぜ、保存ボタンを押す必要があるのか？
>疑問２、なぜ、親フォームのIDを取得する必要があるのか？
>疑問３、なぜ、サブフォームの親IDにセットする必要があるのか？

疑問１：保存ボタンを押すことで、Formの編集中のデータを保存するコードを保存ボタンのクリックイベントで記述しています。
Form_BeforeUpdateでは、Cancel=Trueにしています。
この理由は、間違った入力したものを間違って保存してしまうのを防ぐためです。

疑問２、３：
親Fm: 親ID
子Fm: 子ID
　　　親ID
この場合に、参照整合性が設定出来なかったからか、サブフォームを入れた画面で、サブフォームの親IDに自動で親フォームの親IDがセットされませんでした。これは何故でしょうか。私のリレーションシップの設定の仕方が良くないということでしょうか。

リレーションシップの貼り方は
Aテーブル
・aID
・受付情報

Bテーブル（親）
・bID

Cテーブル（子）
・cID
・bID
・名称

◆リレーション設定内容
・A(aID) - B(bID) : 1対1
・B(bID) - C(bID) : 1対多

よろしくお願いします。

補足日時：2014/11/22 11:57

No.1 回答者： f_a_007 回答日時： 2014/11/21 16:25

Q1、オートナンバー型を主キーでないとリレーションが設定できません。

A1、それは、何らかのミスを犯している。あるいは、誤解している。

のだと思いますよ。

Q2、Subフォームでの自動採番処理はどのようにすれば良いでしょうか？
A2、少なくともレコードが登録される直前までに。

【自動採番処理は一つの専用関数を使いまわす】

例えば、テーブル[ID管理表]から新しいレコード管理番号を取得するNewID()　など。

Me.ID = NewID("TableName", "FieldName")

そうすれば、この１行をしかるべき場所の書くだけですから・・・。

この回答への補足

ご回答ありがとうございます。
大変、失礼しました。私の説明の仕方が今ひとつよくありませんでした。
Q1.自前の採番処理 + 主キーは長整数型にしていると→リレーションをはろうとすると、参照整合性、フィールドの連鎖更新などが設定出来ないという意味でした。ここは、参照整合性をオフにしてリレーションをはることしか出来ないのでしょうか？
自前の場合、参照整合性をオフにして不具合とかはありますでしょうか？

Q2.A2-> ありがとうございます。
この部分、サブフォームの親IDと、親フォームの親IDは、保存ボタンなどを押した時に、親フォームのIDを取得して、サブフォームの親IDにもセットする事をしなくてはいけないでしょうか？

大変お手数をおかけして申し訳ありませんが、よろしくお願いします。

補足日時：2014/11/21 16:51