みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
現在制作中のカスタムAppでまたまた不具合が出たので、またまたお知恵
をお貸し下さい。
とある別々のテーブルに同じ内容のポータルを表示させたいのですが、何
故かうまく動作しません。症状としては、テーブルがABCと三つあり、Aと
BにCテーブルのポータルを表示させています。テーブルA上のポータルで
入力した場合、テーブルBには表示されず、逆にテーブルB上のポータルで
に入力した場合はテーブルAに表示されます。テーブルAのポータルで入力
したレコードを削除してもテーブルBのポータル内のレコードは削除され
ず、逆にテーブルBで削除したレコードはテーブルAでも削除されます。
通常、リレーションを繋げているので両方同じような動作になるはずと思
うのですがどういう事なんでしょうか？
言葉足らずかと思いますので、以下に分りやすく書いてみました。
テーブルがA、B、Cの3つあります。テーブルCにのみフィールドCを作成し、
AとBそれぞれのポータル内にフィールドCを配置します。ポータルレコー
ドの削除は許可しています。
リレーションは主キーでA←=→B←=→Cと繋いでおり、テーブルBとCを繋
ぐリレーションにはテーブルCに対してレコードの作成許可と削除を許可
しています。
試しに新規でファイルを作ってみましたが、思ったように動作をしてくれ
ています。
さて、何が原因と考えられますか？
Offline
新規ファイルで作成して同じように動くならファイル固有の問題でしょう。
不具合はアプリケーションではなくファイルの不具合です。
新規ファイルと完全に同一でも動かないなら索引の破損が疑われますから、
照合フィールドの索引を作成し直します。
同一でないなら相異部分をなくしていけば原因が分かるでしょう。
レコード固有の番号を表示させるなどで双方のポータルに同じレコードが表示されているか確認されましたか？
「同じ動作になるはず」というのは飽くまで推論なので事実を確認しましょう。
Offline
その構成だとAから直接Cにリレーションしてないので、Bのポータルと「同じ内容」にはなりせんよね？
ポータルを使うからにはBとCは1対多なんだと思いますが、
AとBが1対1のリレーションなんですか？
Mozさん
コメントありがとうございます。
新規ファイルと完全に同一でも動かないなら索引の破損が疑われますから、
照合フィールドの索引を作成し直します。
こちらの方法ですが、一旦チェックを外して閉じる、そして再度チェックを付けるだけで作り直せるんでしょうか？
同一でないなら相異部分をなくしていけば原因が分かるでしょう。
そうですよね。それを調べる為に新規ファイルで作ってみたんですから・・・。
レコード固有の番号を表示させるなどで双方のポータルに同じレコードが表示されているか確認されましたか？
同じレコードが表示されずに困っております。ただ、AもBもCには同じレコードが表示されます。
「同じ動作になるはず」というのは飽くまで推論なので事実を確認しましょう。
おっしゃる通りですね。新規ファイルではしっかりと動作しているので、新規ファイルとの違いを1つ1つ確認出来れば分るはずですよね。
ありがとうございます。
Offline
himadaneeさん
コメントありがとうございます。
その構成だとAから直接Cにリレーションしてないので、Bのポータルと「同じ内容」にはなりせんよね？
同じように動作しております。逆におかしいんでしょうか？
ポータルを使うからにはBとCは1対多なんだと思いますが、
AとBが1対1のリレーションなんですか？
全て1対1になっていますね。
Offline
>こちらの方法ですが、一旦チェックを外して閉じる、そして再度チェックを付けるだけで作り直せるんでしょうか？
索引をなしにしてデータベースの管理を閉じ、再度データベースの管理からありにすればOKです。
事象の確認はどのように行っていますか？
例えばAとBを異なるウインドウで開いていてAを表示しているウインドウで変更したものがBのウインドウに反映されないとか
異なるユーザがAとBをそれぞれ開いていて変更が双方の画面に反映されないとか。
ウインドウ内容の再表示で更新されるのか、逆に削除してファイルを閉じて開いても削除されていないとか（あり得ないですが......）
また、1対1にするための照合フィールドはユニークの制限などで重複できないように設定されていますか？
Offline
> 全て1対1になっていますね
ならば、テーブルを分ける意味がないですよ。
Offline
んん？
1対1なら、ポータルは1行のみ表示されますよね？？
直接リレーションされていないテーブルのポータルはやめるべきでしょう。
思い通りの動きにならないと思いますよ。
Offline
Mozさん
コメントありがとうございます。
索引をなしにしてデータベースの管理を閉じ、再度データベースの管理からありにすればOKです。
なるほど、思っていた通りのやり方でした。ありがとうございます。
例えばAとBを異なるウインドウで開いていてAを表示しているウインドウで変更したものがBのウインドウに反映されないとか
異なるユーザがAとBをそれぞれ開いていて変更が双方の画面に反映されないとか。
まさしく、異なるウインドウを横に並べて行っています。異なるユーザでAとBをそれぞれ開いてはいないので、そちらも試して見ます。
ウインドウ内容の再表示で更新されるのか、逆に削除してファイルを閉じて開いても削除されていないとか（あり得ないですが......）
ファイルを閉じてまで確認はしてなかったですが、いろんな方法で確認しても削除されてなかったですね・・・。
また、1対1にするための照合フィールドはユニークの制限などで重複できないように設定されていますか？
はい、テーブルCだけユニークの制限がかかってなかったようでしたので設定しました。
ただ、そのタイミングで、
> 「値を必要とするように定義されていますが、このレイアウトでは利用出来ません。」
> というエラーが出てしまって、入力出来なくなりました・・・。
こちらは直りましたが、やはりBからの入力や削除は出来るのですが、Aからは出来ないですね・・・。
Last edited by げっさん (2021-09-17 13:26:53)
Offline
単に、ウインドウが更新されていないだけなのでは。とくに、ウインドウを並べて表示させているのでしたら、リレーション先のファイルが更新されたとしても、明示的にウインドウ表示を更新しないと、ポータルの内容が反映しないことがあります。特に、直接のリレーションでないテーブルの更新は、ウインドウが再表示されるまでは変化ないでしょうね。
Last edited by Shin (2021-09-17 13:14:37)
Offline
チポさん
コメントありがとうございます。
1対1なら、ポータルは1行のみ表示されますよね？？
いいえ、2行目も表示されますね。
直接リレーションされていないテーブルのポータルはやめるべきでしょう。
思い通りの動きにならないと思いますよ。
逆に言えば、直接リレーションをしてやれば良いんでしょうか？
要はテーブルAとテーブルBに同じポータルを設定したく、その内容がテーブルCという訳なんです。
Offline
Shinさん
コメントありがとうございます。
単に、ウインドウが更新されていないだけなのでは。とくに、ウインドウを並べて表示させているのでしたら、リレーション先のファイルが更新されたとしても、明示的にウインドウ表示を更新しないと、ポータルの内容が反映しないことがあります。特に、直接のリレーションでないテーブルの更新は、ウインドウが再表示されるまでは変化ないでしょうね。
なるほど、確かに挙動は不安定でした・・・。
ちなみに、ウインドウを並べずに確認してみましたが、やはりテーブルAの入力はテーブルBには届かず、テーブルBからの入力はテーブルAにしっかり入力されています。
ただ、テーブルCは両方からの入力でしっかりとレコードが作成されています。
Offline
> 2行目も表示されますね
なら、対多ということでしょう。
> 逆に言えば、直接リレーションをしてやれば良いんでしょうか
そうなんですが、、
できる構造なんでしょうか？
もう少し詳しくテーブル構成等書かれたらいかがでしょうか。
Offline
> ウインドウを並べずに確認してみましたが、やはりテーブルAの入力はテーブルBには届かず、テーブルBからの入力はテーブルAにしっかり入力されています。
テーブルA のレイアウトでポータルに入力した後で、テーブルB の［ウインドウを再表示］を行ってみてください。（スクリプトで行うか、そのウインドウで別のレイアウトか別のレコードへ移動して戻る）
リレーションが A←=→B←=→C ならば、A から C のテーブルを触ると、B 経由で動きますので、B のウインドウも再表示されます。B からさわると、A のテーブルのどのフィールドにも影響しませんので、A のウインドウが再表示されないかもしれません。
Last edited by Shin (2021-09-17 16:02:22)
Offline
そういえば、［ウインドウを再表示］は
https://help.claris.com/ja/pro-help/con … indow.html
[キャッシュ結合結果を書き込む] を選択すると、関連レコードのクエリーの結果が削除され、関連レコードが更新されます。
ということなので、このオプションを選択して再表示しないと、他のレイアウトやユーザでの関連レコードの追加削除が自動的に反映されないことがあっても不思議はありません。（常に自動的に表示が最新になるなら、そもそもこのスクリプトステップが必要ない）
>やはりテーブルAの入力はテーブルBには届かず、テーブルBからの入力はテーブルAにしっかり入力されています
こういう書き方だと、根本的な理解ができてない感じがしてしまいます。（テーブルとレイアウトの区別がついてない）
入力するのはテーブルC（のフィールド）にであって、AとBをソースにしたレイアウトのポータルから、ですよね。
Shinさん
コメントありがとうございます。
単に、ウインドウが更新されていないだけなのでは。とくに、ウインドウを並べて表示させているのでしたら、リレーション先のファイルが更新されたとしても、明示的にウインドウ表示を更新しないと、ポータルの内容が反映しないことがあります。特に、直接のリレーションでないテーブルの更新は、ウインドウが再表示されるまでは変化ないでしょうね。
他の方がコメント下さっているように、ウインドウの再表示のスクリプト
も組み込みましたが、どうも思ったような動作になりません。
テストで作ったファイルはしっかりと動作しているので考え方には問題な
いかと思いますが、どうもテストで作ったファイルと実際のファイルの内
容が違うという事になりますので、再度ファイル同士を比較してみました
が、どうも上手く行きません・・・。ですので、こちらは解決済とさせて
頂きます。
なお、元々やりたかった事を別の質問としてアップしております。
色々とアドバイスありがとうございます。
Offline
チポさん
もう少し詳しくテーブル構成等書かれたらいかがでしょうか。
テーブル校正は新規ファイルを作り、自分自身で確認しながら分りやすく
説明はしたつもりだったんですが・・・。
なお、こちらに関してはどう頑張っても上手く動作しませんので、本当に
やりたかった事を別の質問として投稿させて頂きます。
ですので、この投稿は解決済とさせて頂きます。
色々とアドバイスありがとうございます。
Offline
himadaneeさん
コメントありがとうございます。
ウインドウのを再表示のスクリプトを組み込んでみましたが、どうも上手
く動作しません・・・。新規ファイルで動作確認をした時はちゃんと動作
しているので、現状のファイルでは何か私自身が見落としているモノがあ
ると推測されますが、見比べて見ても分らない状況です。
ですので、こちらの質問は解決済とし、本来やりたかった事を別の質問と
してアップさせて頂きました。
こういう書き方だと、根本的な理解ができてない感じがしてしまいます。（テーブルとレイアウトの区別がついてない）
言葉足らずで申し訳ないです。
入力するのはテーブルC（のフィールド）にであって、AとBをソースにしたレイアウトのポータルから、ですよね。
おっしゃる通りです。
色々とアドバイスありがとうございます。
Offline
ウインドウを再表示は、どのウインドウに対して行なっていますか。また、キャッシュの扱いはどうしましたか？
どうもきになるのが、別の新しいファイルでは狙った動作ができている、ということは、根本的には正しく作れているのでしょうね。それが動かないのでしたら、ファイルそのものに問題があるか、動作が遅くなって追随してきていいないのどちらかでしょう。再表示は後者を補うものですが、対象のウインドウで変わります。それがうまく動かないのでしたら、ファイルの損傷が疑われますが。
ちなみに、そのファイルの容量はどのくらいですか。大きいものでしたら、一度、最小化保存してみると改善する可能性もあります。
Offline
Shinさん
コメントありがとうございます。
このShinさんからのコメントを頂かなければ絶対に解決出来てなかった事
が解決しました！！
実はリレーションシップグラフを見直してみると、元々あったリレーショ
ンに不具合があった事が発覚しました。すなわち、元々あったリレーショ
ンに気付かず、新たにリレーションを追加したので、新たに追加したリレ
ーション通りの動きにはいくら頑張ってもなからなったようです・・・。
改めて元々あったリレーションの不具合を解消し、リレーションも以下の
ように繋ぎ直したところ、見事に思ったような挙動になりました。
変更前:A←=→B←=→C
変更後:A←=→CとB←=→C
こちらの投稿に携わって頂いた皆さん、大変お騒がせしました。本当に解
決しました。本当にありがとうございます！！
Offline
Pages: 1
[ Generated in 0.010 seconds, 9 queries executed - Memory usage: 629.4 KiB (Peak: 662.3 KiB) ]