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

25300	結合表で新規入力は可能ですか？	しぼうかん	2004/03/07-19:05
またお知恵をお貸し下さい。 得意先.tbl(主キー=[得意先CD])と請求部署.tbl(主キー=[請求先CD],外部キー=得意先.tblの[得意先CD])が有ります。 データ入力済みの2つの表を[得意先CD]を使い結合した請求先一覧.viwを作り、 そして請求先一覧.viwを編集対象表とする請求先一覧.wfmを作りました。 そして行挿入終了前イベントで[得意先]の値により[得意先CD]を自動入力し [請求部署]の値から[請求先CD]を自動入力するようにコマンドを書きました。 この請求先一覧.wfmで新規入力を完了後、表示状態にしようとしたり、 次のレコードへ移動しようとすると"主キー項目値が重複しています。"と エラーが出てしまいます。 しかしこの表をフォーム編集状態から表編集状態に変えてみると入力済みの [得意先CD]のデータは重複しています。 結合をする時には[得意先CD]データの重複が許されているのだから、 請求先一覧.wfmで[得意先CD]を新規入力をする時にも重複を許してもらいたいのですが、 何か方法がありますでしょうか？ ファイルをUPして置きました。 "元ファイル"フォルダの中の"元得意先一覧.wfm"で"カンリコ社"の"北米支店" を入力すると[得意先CD]と[請求先CD]が両方ともうまく入力出来るのですが、 同じ事を"変更中"フォルダの中の請求先一覧.wfmで出来ないかなと思っています。 しかし"変更中"フォルダの中の請求先一覧.wfmで[得意先]に"カンリコ社"を [請求部署]に"北米支店"を入力して終了しようとすると"主キー項目値が重複しています。"とエラーが出てしまいます。 桐v8sp6又は桐v9sp1です。
25303	結合表の作り方に問題があります	佐田　守弘	2004/03/07-19:55
記事番号25300へのコメント しぼうかんさん アップされたデータを詳細に見たわけではなく、おそらくと思う場所をピンポイントで 確認しただけなので、あるいはそれ以外にも原因がないとは限りませんが。 ●結合の定義に問題あります 結合表で得意先の[得意先CD]を抽出項目とし、フォームの方でもこの項目を編集しようとしています。 得意先.tblの得意先CDは当然ながら重複禁止ですよね。ですからこのエラーがでているのだと思います。 追加や修正するのは、得意先.tblではなくて、請求部署.tblの方の[得意先CD]である事が必要です。 こちらの項目は、同じ客に納戸も売るわけですから、重複ありのはずです。 結合表の定義に請求部署.tblの方の[得意先CD]を追加し、（得意先の[得意先CD]は抽出しない） これをフォームのソースに指定し直してみて下さい。 佐田守弘(KS-00119)
25313	Re:結合表の作り方に問題があります	しぼうかん	2004/03/08-18:58
記事番号25303へのコメント 佐田　守弘さん、お返事ありがとうございます。 請求先一覧.viwに請求部署.tblの[得意先CD]を追加して、 得意先.tblの[得意先CD]を削除して見ました。 そうすると今度は行挿入しようとすると編集モードへ 移行出来なくなりました。 うーん、わかりません。
25317	Re:結合表の作り方に問題があります	佐田　守弘	2004/03/08-21:11
記事番号25313へのコメント しぼうかんさん >得意先.tblの[得意先CD]を削除して見ました。 削除するのでなくて、「抽出する」のチェックマークを外してみては どうですか？ 佐田守弘(KS-00119)
25320	Re:結合表の作り方に問題があります	しぼうかん	2004/03/08-21:55
記事番号25317へのコメント 佐田　守弘さん、たびたびありがとうございます。 得意先.tblの[得意先CD]のチェックをはずす事も 試して見ましたがダメでした。
25322	Re:結合表の作り方に問題があります	佐田　守弘	2004/03/08-22:59
記事番号25320へのコメント しぼうかんさん アップされていた結合表を開いてみると、更新不可になっているんですね。 結合表の段階で更新禁止になっているので、編集ができないと思います。 原因を調べてみましたが、すぐに見つかりそうもなかったので、 ひとまずは私の方でほとんど同じ結合表を作ってアップしておきました。 そちらの方でどこがどの様に違っているか調べてみて下さい。 佐田守弘(KS-00119) 追伸： 少し前から補完BBSにアップロードでなくなり、その原因が不明だったのですが、 ようやく原因が解りました。 障害状況：「リンク元が不正です」が表示されて投稿を拒否される。 原因：パーソナルファイアーウォールが投稿をブロックしていました。 ファイアーウォールを無効にすれば投稿できる事が解りました。 （他の人はファイアーウォールは使ってないの？）
25324	結合表を使えれば便利そうなんですが	しぼうかん	2004/03/09-00:50
記事番号25322へのコメント 佐田　守弘さん、たびたびすいません。 ありがとうございます。 >アップされていた結合表を開いてみると、更新不可になっているんですね。 宿題が１つ増えました。結合表の定義画面では更新禁止にはチェックが入っていなかったのですが、 どこかに"更新不可"を設定する場所があるんですね。 "変更中フォルダ"の中の"請求先一覧.viw"を削除して、替わりにUPして頂いた "請求先.viw"の名前を"請求先一覧.viw"に変更後コピーし、"請求先一覧.wfm を使って入力して見ました。 すると入力が出来るようになっています。 しかし、行挿入終了後に"主キー項目値は未定義に出来ません"とエラーが出て 入力を完了させる事が出来ません。 行挿入終了前イベントで請求部署一覧.tblの[得意先CD]と[請求先CD]には値が 入力出来ているようですが、得意先一覧.tblの主キーで有る[得意先CD]に値が 入力出来て居ない事が原因の様です。 しかしどうすれば良いのかはいまだわかりません。 > >（他の人はファイアーウォールは使ってないの？） > 私はWinXP Proでファイアーウォールを使っていますがBBSにUP出来ています。 自分の設定がおかしいのかもしれませんが・・・
25329	Re:結合表の作り方に問題があります	hidetake	2004/03/09-12:22
記事番号25322へのコメント >障害状況：「リンク元が不正です」が表示されて投稿を拒否される。 >原因：パーソナルファイアーウォールが投稿をブロックしていました。 桐とは関係ない話ですが， これは HTTPレファラー(Referer)の関係だと思います。 http://www.studyinghttp.net/rfc_ja/2616/sec14.html#sec14.36 掲示板など外部からの不正投稿を防ぐために，外部からの直接のリクエストを拒否し， 自分のページからのリクエストでないと受け付けないようにしてあるものがあります。 Referer は，どこから来たのかをサーバに知らせるために HTTPリクエストヘッダに ブラウザがリンク元 URI を書き込みます。だから偽装も簡単なので， それだけでは不正アクセスは防げないのですが，セキュリティ上そう言った 制限を付ける事はあります。 パーソナルファイヤーウォールによってはこの Referer をブロックするものもあり， そう言うパーソナルファイヤーウォールを通した場合は 掲示板などへの投稿ができない場合もあります。 あるいは，アクセスカウンタなどでもReferer を見ているものもありますが， Referer をブロックされるとカウンタが正常に見えないものも出てきます。 これらの障害を回避するには，パーソナルファイヤーウォールの Referer ブロック禁止を しないように設定する必要があります。 なお，Referer はどこから来たかをサーバに知らせるため，もし秘密も場所にリンクが貼ってあり， そこのリンクをクリックし対象のサイトにアクセスした場合， サーバの管理者は Referer からリンク元を探る事ができるので その秘密の場所は，相手のサーバ管理者には秘密でなくなると言う面も出てきます。 もし，その秘密のサイトが Webメールで，誰からかここを見ろ！ とメールが来たとして，その Webメールに認証などを通さず URI だけで アクセスできるセキュリティホールがあれば，相手先のサーバ管理者が， こいつはどこから来たのか？って，リンク元を探られたら，そのリンク元である Webメールを見られたりする可能性が出てきます。 そう言ったセキュリティ的に好ましくない Webメールを使っていたりする場合に， リンク元を探られないようにして，セキュリティを守るために， パーソナルファイヤーウォールはお節介にも Referer をブロックしていると思われます。 インターネットにはそう言った仕組みや危険性もあると言う事です。 お気をつけあれ？
25345	Re:結合表を使えれば便利そうなんですが	佐田　守弘	2004/03/09-23:10
記事番号25324へのコメント しぼうかんさん まず結合表だけで入力ができるかどうかを確認してみて下さい。 操作方法が間違っているのかも知れませが、私が操作した限りでは アップした結合表での入力は可能でした。 もし結合表では入力できて、フォームでは入力できないとすると、 フォームの方も直す必要があるかと思います。 佐田守弘(KS-00119)
25382	二歩進んで二歩戻った感じです。	しぼうかん	2004/03/10-22:49
記事番号25345へのコメント 佐田　守弘さん、お世話になっています。 教えて頂いた様に結合表からの入力をためしてみるとやはり "主キー項目値は未定義に出来ません。"とエラーが出ました。 そして色々やってみて理屈は不明ですが、原因はわかりました。 自分が予想していた解決方法とは逆に、請求先.viwのうち 得意先一覧.tblから結合している項目([得意先]と[得意先ふりがな])を入力しない事でうまく行きました。 なお、この時に得意先.tblの[得意先CD]を抽出するにチェックを入れていてもうまく行きました。 どうも結合項目である[得意先CD]を入力する事で請求先.viwの 得意先.tblを対象とする[得意先]と[得意先ふりがな]に値が 自動的に(入力される？表示される？)様です。 しかし、請求先.viwに新規に"ジャスト社"のデータを入力しようとすると 今度は"参照制約に違反するレコードです"というエラーが出てしまいます。 結合表の得意先.tbl部分には直接入力していないのだから 当然の様にも思えるので、今度は逆に"得意先.tblで抽出した [得意先]や[得意先CD]や[得意先ふりがな]に入力してみました。 すると今度はうまく行きました。 と言うことは"得意先.tbl"に無い新規のデータを入力する場合は 請求先.viwの"得意先.tbl"の[得意先CD]と[得意先]に入力をして、"得意先.tbl"に有る 既存の[得意先CD]を使った新規の[請求部署]を入力する時は"得意先.tbl"の[得意先]と [得意先CD]と[得意先ふりがな]を入力しない方法を考える必要がある様です。 この方法は結合表直接の入力では無理そうなので、 この様な事をフォーム上で自動化するイベントでの処理をもう少し調べて見ます。
25430	別の道を行くことにします。	しぼうかん	2004/03/13-01:00
記事番号25382へのコメント 最初の投稿での質問の結合表を使っての行挿入？行追加？は 請求部署.tblに作業項目の様な項目を作る事でフォームでの 入力が可能になりました。 しかし今度は別件ですが思ったような行削除が出来ない事に気が付きました。 例えば得意先.tblの[得意先]に"ファイル社"を持ち、請求部署.tblの[請求部署]に"東京支店"と"大阪支店"を持つ 会社データがあり、ファイル社の大阪支店が父さんした時には 請求部署.tblの"大阪支店"のデータのみを削除して、さらに東京支店が 父さんした時は得意先.tblの"ファイル社"のデータと請求部署.tblの"東京支店"のデータ両方が 削除される様な削除がしたかったのです。 しかし過去ログ http://www.fuku3.com/~habata/kbbs/kakov8/10630.htm でこの様な削除についての質問を見つけ桐の結合表の機能上 無理そうな事がわかりました。 せっかく入力が出来るようになったのですが削除が思うように 出来ないので残念ながらこの方法は諦める事にします。 次回の桐では是非結合表の機能UPお願いします。>Ｋ３様
25436	これは結合表の問題ではないですね。	佐田　守弘	2004/03/13-23:10
記事番号25430へのコメント しぼうかん どうやら結合表とフォームまではうまくできた様ですね。 さて、 >ファイル社の大阪支店が父さんした時には請求部署.tblの"大阪支店"のデータのみを >削除して、さらに東京支店が父さんした時は得意先.tblの"ファイル社"のデータと >請求部署.tblの"東京支店"のデータ両方が削除される様な削除がしたかったのです。 について、桐から少し離れて現実の問題から考えてみます。 上記で「父さん」は、「倒産」の誤記と思いますが、「ァイル社の大阪支店」の倒産というのは、 現実問題としてあり得ないと思います。 倒産するのはファイル社であって、仮にこの大阪支店が営業不振になれば、大阪支店だけでなくて、 ファイル社全体が倒産するはずです。 但し倒産ではなくて、大阪支店の閉店ならあり得ます。 ここで桐の問題に戻ります。ファイル社が倒産した事により、マスタファイルから ファイル社を削除すれば、大阪支店だけではなくて東京支店のデータも削除しなければ整合性が取れません。 もし大阪支店はなくなっても東京支店とか本社は残るようなケースでは、 マスタファイルから削除するような操作ではなくて、東京支店と大阪支店を別会社として登録しなおし、 一方の未削除するとか、あるいは削除するのではなくて、単に使わないだけにするといった、 「現実問題としてどうするのか？」に即した扱い方を考える事が必要かと思います。 佐田守弘(KS-00119)
25442	いつも例のあげ方で失敗します。	しぼうかん	2004/03/15-01:05
記事番号25436へのコメント まだ見て頂きまして有り難うございます。 おっしゃる通り大阪支店だけが倒産するという例は間違っていました。 実際は支店の倒産では無く請求部署の統廃合で部署が消えた場合を想定していました。 それは取引先に部署別に請求書を発行し入金は会社別に振り込まれるという会社がある為です。 そこで請求書管理の為、部署別のコード([請求先CD])が必要になります。 また売掛台帳(作成予定)で入金と売上(請求金額合計)を合算させる為に それぞれの部署が同じ会社で有ることを証明する為に[得意先CD]も必要になります。 そして補完BBSの88番にUPした現在使用中の形式である"元ファイル"フォルダでは 佐田さんがおっしゃる通り部署ごとに別々のデータとして登録して使っています。 しかしある時ふと1つのテーブルに2つのコードを持たせ管理する為に [得意先CD]が重複する"元ファイル"の形式より、得意先のコードと 請求部署のコードを２つの正規化されたファイルで管理して それを結合して使ったほうがデータベースっぽいかなと思い、 何とかならないかと投稿した次第です。 多分、自分が形にこだわり過ぎていたのかもしれません。
25466	結局はシステム分析と業務フローの問題と思います	佐田　守弘	2004/03/16-00:36
記事番号25442へのコメント しぼうかんさん この問題は、結局の所、業務フローとそれを作り上げるためのシステム分析の問題と思います。 要するに、支店の統廃合が起きたら、どの様に処理するのか？ また、倒産の場合も含めて、債券が他社に移転する様な場合に、 どの様に処理するのか？といった問題です。 どこの会社でもこういった「その時どうすべきか？」が文書化されている事が大切です。 システムを組む場合に、この部分をないがしろにしてしまうと、 途中で最初に戻って作り直しになってしまったりします。 そういう意味で、キッチリとシステム分析を行い、 ・なんのためにその様な仕事をしているのか？ ・その仕事は省略できないのか？他の方法に置き換えられないのか。 ・その仕事はどの様に処理する事が必要なのか。 その様な事を洗い出して行き、最終的に何をどの様にするという様な 流れ図、つまり業務フローを作ります。 そういう中で、データベースはどの様な形で持つのが良いのかの設計もして行きます。 ですから、今回の件は、桐の結合表の問題ではなくて、 もっと上位にあるしぼうかんさんの会社でどの様に仕事を処理するのかといった問題だと思います。 この件でのご相談にのることはやぶさかではありませんが、 そこまでの話になると、桐を離れて業務改善の課題になりますし、 架空例では済まされず実データと実例で扱わなければならなくなって、 BBSの様な公開の場には馴染まなくなります。 佐田守弘(KS-00119)
25469	Re:結局はシステム分析と業務フローの問題と思います	しぼうかん	2004/03/16-19:43
記事番号25466へのコメント >今回の件は、桐の結合表の問題ではなくて、 >もっと上位にあるしぼうかんさんの会社でどの様に >仕事を処理するのか >といった問題だと思います。 桐の機能(特に結合表)の問題だと思っていました。 >この件でのご相談にのることはやぶさかではありま>せんが、 実務上現状でも問題が発生しているわけでは無いのでとりあえず 今回は今まで通りの方法でやることにしました。 お世話をお掛けしました。m(_ _)m PS. 桐を会話処理だけを使っていた頃はシステムの設計とか考えずに とりあえず作ってみて不都合が見つかってから直接変更して見る様な事をしていました。 しかし、イベントで書くコマンドの行数が次第に増えてくるとバグの作り直しに時間がかかる様になって来た為 メモなどにフローチャートを書いて検討してから始める様になって来ました。 この検討には鈍い頭では時間がかかり大変ですが、パズルを解く様な楽しみも有りますね。

戻る