14 返信 最新の回答 日時: Feb 9, 2014 8:16 AM ユーザー:Nu-nrg

    検索条件の編集、その他について

    Nu-nrg

      タイトル

      検索条件の編集、その他について

      フォーラムに投稿

           検索について、いくつか教えてください。

           1)検索条件を編集のダイアログボックスで、
           次の場合にレコードを検索する、の横の条件と演算子の挿入がありますが、
           フィールドに文字列一致のときに、演算子=や、一致させる文字列を””で囲わなくてもいいのでしょうか。
           フィールドの数値範囲の場合は、演算子>などをいれるのに。
           演算子の試用について統一されてないようで混乱しています。
           検索モードでフィールドに値を入れているとイメージすればよいのでしょうか?

           2)検索モードで検察条件を保存する便利な機能がありますが、
           スクリプトで検索実行[記憶する]の検索条件を指定で、保存された検索条件がでてきません。
           通常で検索条件を保存して行った場合の保存した検索条件を使い回しはできないのでしょうか。

           よろしくお願いいたします。

           環境:Fm pro 12 ad

        • 1. Re: 検索条件の編集、その他について
          sago350@未来Switch

               1)について

               Nu-nrgさんは他の言語から来られた方でしょうか。
               FileMakerは検索モードでフィールドに値を入れていくイメージでOKです。
               FileMakerの検索が奥が深く、思ったより色んなことができます。
               例えば、日付フィールドで「金曜日」と検索して下さい。金曜日の日付が検索されます。

               「FileMaker」というデータは「File」では検索できるが、「Maker」では検索できません。
               「*Maker」と入力する必要があります。
               しかし、「ファイルメーカー」に対して「メーカー」で検索することは出来ます。

               2)について
               そこは別管理なので、出来ません。
               ちなみに、通常検索で保存した検索条件はアカウント単位で保存されます。
               なので、アカウントを使いまわしていると別の人のが見えます(メリットと考えるかデメリットと考えるかはそれぞれですが)
                

          • 2. Re: 検索条件の編集、その他について
            Nu-nrg
                 

                      Nu-nrgさんは他の言語から来られた方でしょうか。

                 phpとかプログラミング自体に興味があり少々かじっております。
                 プログラマではありません、全く仕事はシステム管理系とかでもなく、小さな会社の営業職です(笑)
                 基本は繰り返し業務を楽して余った時間で別のことをしたい、帳票を奇麗にしたい、特別丁寧なデータというか資料を顧客に提示したい、ミスを少なくしたい、などの理由からファイルメーカーを利用しています。
                 ちなみにクラリスのころから飛び飛びでバージョンアッップし続けていますが、使いこなせていません(デザイン含めてかっちり作り込めなく、いつも作成中のような未完成なデータベースを利用してます)。
                 データベースというもの自体が好きなんでしょうね(笑)

                 
                      FileMakerは検索モードでフィールドに値を入れていくイメージでOKです。
                 
                      FileMakerの検索が奥が深く、思ったより色んなことができます。
                 
                      例えば、日付フィールドで「金曜日」と検索して下さい。金曜日の日付が検索されます。
                 少々癖がありますが、慣れていきたいと思います。
                 金曜日などと検索できるのは便利ですね。
                      
                           そこは別管理なので、出来ません。
                      
                           ちなみに、通常検索で保存した検索条件はアカウント単位で保存されます。
                      
                           なので、アカウントを使いまわしていると別の人のが見えます(メリットと考えるかデメリットと考えるかはそれぞれですが)
                 
                      なるほど、別管理ですか。
                      少々残念ですが、仕方ないですね。
                       
                      けっこう調べたり弄くったりで時間がかかるもんで、sago35さんいつもプラスアルファのアドバイスいただき助かります、ありがとうございます!
                  
            • 3. Re: 検索条件の編集、その他について
              Shin
                   

                        フィールドに文字列一致のときに、演算子=や、一致させる文字列を””で囲わなくてもいいのでしょうか。

                   = の演算子は、省略可能、という解釈でいいと思います。また、文字列を囲むのも、省略可能、と思われていいでしょう。

                   場合に依っては、その書き方をしないと検索ができないことがあります。

                   

                        スクリプトで検索実行[記憶する]の検索条件を指定で、保存された検索条件がでてきません。

                   スクリプトを書きだした場合には、その検索条件が印刷されてきます。また、スクリプトの検索条件は、ステップの指定ボタンをクリックすると一覧で表示され、その1行ごとに詳細の変更も可能ですが、そういう意味では無いですか。

                   

                        通常で検索条件を保存して行った場合の保存した検索条件を使い回しはできないのでしょうか。

                   検索条件を保存、で一旦検索して、そのままの状態で新たに検索のステップを追加設定すると、その時点での検索条件を読み取っています。ただし、その前に検索条件が設定されていたステップでは、読み取らないようです。直接取り込めるわけではないですが、同様の操作は可能です。

              • 4. Re: 検索条件の編集、その他について
                Nu-nrg

                     Shinさん、いつもありがとうございます。

                     
                          = の演算子は、省略可能、という解釈でいいと思います。また、文字列を囲むのも、省略可能、と思われていいでしょう。
                     
                           
                     
                          場合に依っては、その書き方をしないと検索ができないことがあります。
                     なるほど、では省略しない書き方を自分はデフォルトにします!
                     スクリプトを書きだした場合には、その検索条件が印刷されてきます。また、スクリプトの検索条件は、ステップの指定ボタンをクリックすると一覧で表示され、その1行ごとに詳細の変更も可能ですが、そういう意味では無いですか。

                     いいえ、メニューから、レコード>保存済み検索>現在の検索を保存
                     というのが、スクリプトの、検索実行[]のところに貯金されて出てこないという意味です。

                     

                          検索条件を保存、で一旦検索して、そのままの状態で新たに検索のステップを追加設定すると、その時点での検索条件を読み取っています。ただし、その前に検索条件が設定されていたステップでは、読み取らないようです。直接取り込めるわけではないですが、同様の操作は可能です。

                     あれま、レコード>保存済み検索を実行し、スクリプトを編集し、
                     既存の検索実行[]を指定した場合はだめでしたが、
                     新たに検索実行ステップを追加すると、中に検索条件がでてきました。
                     印刷設定の記憶みたいな感じなんですね、勉強になりました!
                     、レコード>保存済み検索>現在の検索を保存が、スクリプトステップの検索実行の条件指定中では蓄積されていかないようですが、これは仕様ですね、大目に見ましょう(笑、生意気な!)

                • 5. Re: 検索条件の編集、その他について
                  sago350@未来Switch

                       昔話をすると、かつてファイルメーカーは最後にした検索とかソートとかエクスポートを覚えるという仕組みがデフォだったので、その名残で最後に検索した条件が出てきます。
                       印刷設定の記憶も同じですね。

                       コレ、逆手に取ってエクスポート条件なんかは手動でエクスポートしておいて、スクリプト開いて予め入っているのを登録するってことが出来ます。

                       で、余談なんですが検索をスクリプトで実行する時は私は
                   検索モードに切り替え
                        フィールド設定
                        検索実行

                       というステップで実行させます。
                       何故かと言うと、後から見た時にどういう検索条件で実行しているかが一目で判るからです。
                       これが、検索実行ステップだけで書かれていると、いちいちそのスクリプトステップを開かないと分かりません。
                       それが、上記のように書くと一目でどういう検索条件というのが解ります。
                       (印刷すれば表示されるので、そっちで確認する場合はそれでOK)
                       ま、一人で作っている場合は検索実行でも構わないのですが、複数人数や「1年後の自分」を考える場合はスクリプトの可視性というのも考えてもいいかなと思います。

                        

                  • 6. Re: 検索条件の編集、その他について
                    Nu-nrg
                         
                              昔話をすると、かつてファイルメーカーは最後にした検索とかソートとかエクスポートを覚えるという仕組みがデフォだったので、その名残で最後に検索した条件が出てきます。
                         
                              印刷設定の記憶も同じですね。
                         
                               
                         
                              コレ、逆手に取ってエクスポート条件なんかは手動でエクスポートしておいて、スクリプト開いて予め入っているのを登録するってことが出来ます。
                         エクスポートも記憶できるんですね、最初は記憶という機能(設定ではなくアクション後の記憶)うっとおしい昨日だと思っていましたが、なんだか便利な機能に思えてきました。
                         ファイルメーカーマジックでしょうか(笑)
                          
                         
                                   余談なんですが検索をスクリプトで実行する時は私は
                                    検索モードに切り替え
                                    フィールド設定
                                    検索実行
                                   というステップで実行させます。
                                   何故かと言うと、後から見た時にどういう検索条件で実行しているかが一目で判るからです。
                                   これが、検索実行ステップだけで書かれていると、いちいちそのスクリプトステップを開かないと分かりません。
                                   それが、上記のように書くと一目でどういう検索条件というのが解ります。
                                   (印刷すれば表示されるので、そっちで確認する場合はそれでOK)
                                   ま、一人で作っている場合は検索実行でも構わないのですが、複数人数や「1年後の自分」を考える場合はスクリプトの可視性というのも考えてもいいかなと思います。

                         検索モードのフィールド設定で、検索条件を入力するようにされてるんですね。
                         わたしなんか1人開発、利用者数名なのに、わざわざウィンドウの固定なんかしちゃってます、意味ないですね(笑)
                         ウィンドウの固定ってなんだろうって調べて、あまり良く考えずに、なるほどでそのまま使っちゃってますorz。
                         フィールドを使った条件検索って、なかなか慣れなかったり覚えれないので、検索の場合だけ、利用者にスクリプトの動きを見せたほうが良いのかもしれません。
                         とても参考になるTipをありがとうございました。

                          

                    • 7. Re: 検索条件の編集、その他について
                      Shin

                           FM6以前では、検索条件を記憶させた場合には、スクリプトの中でその条件を見ることが出来ず、スクリプトを印刷するか、検索させてみる、という方法しかなかったため、仕方なく、検索モードへ切り替え、条件設定、検索実行、という書き方をしていたことがあります。

                           FM7以降では、スクリプトステップのボタンから、条件の確認、編集が可能で、その書き方はレガシーな物だと思いますが。

                           私は、FM7以降では、その書き方は可能な限りしないようにしていますし、新しい検索条件設定方法、例えば、変数へ設定した値を検索条件値にする、などが使えませんね。(混在させると、却ってみにくくなる)

                      • 8. Re: 検索条件の編集、その他について
                        Nu-nrg
                             

                                  FM6以前では、検索条件を記憶させた場合には、スクリプトの中でその条件を見ることが出来ず、スクリプトを印刷するか、検索させてみる、という方法しかなかったため、仕方なく、検索モードへ切り替え、条件設定、検索実行、という書き方をしていたことがあります。

                             なるほど、そうでしたね。あまり凝った検索条件を作っていなかったので忘れてました。
                             確かに、記憶させるためにうんぬんの作業が多く、またその内容を確認できなく不便でした。
                             今は大変便利です。

                             
                                  M7以降では、スクリプトステップのボタンから、条件の確認、編集が可能で、その書き方はレガシーな物だと思いますが。
                             
                                   
                             
                                  私は、FM7以降では、その書き方は可能な限りしないようにしていますし、新しい検索条件設定方法、例えば、変数へ設定した値を検索条件値にする、などが使えませんね。(混在させると、却ってみにくくなる)
                             レガシーではない検索スクリプト、つまり検索条件を指定した検索実行[記憶する]の一発検索では、変数が使えるのでしょうか(試してませんので)。
                              
                             話はそれますが、カスタムダイアログの入力フォームも検索には使いにくいのですが、検索を強くするのであれば、テーブルやレコード、実データとは全く関係ないフォーム(フィールド)を自由に作れるような機能がファイルメーカーに欲しいところです。
                             これができると、分離モデルに進みそうな気もしますが。
                              
                        • 9. Re: 検索条件の編集、その他について
                          Shin
                               

                                    レガシーではない検索スクリプト、つまり検索条件を指定した検索実行[記憶する]の一発検索では、変数が使えるのでしょうか

                               http://www.filemaker.com/12help/jp/html/non_toc.46.46.html#1077793

                               が参考になるでしょう。

                               

                                    テーブルやレコード、実データとは全く関係ないフォーム(フィールド)を自由に作れるような機能がファイルメーカーに欲しいところです。

                               適当なテーブル上にグローバルフィールドを作り込んでおくと、そのフィールドはどのテーブルからでもアクセスでき、検索時にも参照できます。

                               または、適当なテーブルを作り、通常のフィールドを作ります。そのテーブルと目的のテーブルをXリレーション(デカルト積といいます)しておくと、そのフィールドを参照できる様になります。

                               これらの方法で、実現できるでしょう。

                               ただ、分離モデルとは直接関係無いかと思います。テーブルそのものが手元のファイルに存在せず、別のファイルに保存してあり、ファイル構造のなかでそれを参照できる、というだけの事です。実験は簡単に出来ます。例えば、適当なファイルを作り、そのコピーを作ります。外部データソースにコピー元ファイルを設定しておきます。コピー側のテーブルオカレンスを、全て外部データソースを通してコピー元のファイルへ定義し直します。コピー側のファイルのテーブルを全て全て削除してみましょう。それでも、コピー側で同じ様に動きますね。

                          • 10. Re: 検索条件の編集、その他について
                            Nu-nrg
                                       
                                       
                                 
                                      が参考になるでしょう。
                                 変数、グローバル変数ともに使えますね!
                                 ファイルメーカーヘルプって、なんか表現が硬くて、例の記述も変で、文字列ばかりで、読んでいると頭痛くなります(笑)
                                 wikiみたいなマニュアルどっかにあるといいですね。
                                  
                                 
                                           適当なテーブル上にグローバルフィールドを作り込んでおくと、そのフィールドはどのテーブルからでもアクセスでき、検索時にも参照できます。
                                            
                                           または、適当なテーブルを作り、通常のフィールドを作ります。そのテーブルと目的のテーブルをXリレーション(デカルト積といいます)しておくと、そのフィールドを参照できる様になります。
                                            
                                           これらの方法で、実現できるでしょう。
                                            

                                 グローバルフィールドは便利ですよね。紛らわしいので、グローバルフィールド専用のテーブルに纏めるようにしています。
                                 話はずれますが、値一覧もテーブルを利用するように、ファイル含め分離しておいたほうが良いらしいですね。
                                 デカルト積は聞いたことがありましたが、初めて弄ってみました。
                                 ちょっと使いどころのイメージがわかないのですが、色々と調べてみようと思います。

                                 

                                      ただ、分離モデルとは直接関係無いかと思います。テーブルそのものが手元のファイルに存在せず、別のファイルに保存してあり、ファイル構造のなかでそれを参照できる、というだけの事です。実験は簡単に出来ます。例えば、適当なファイルを作り、そのコピーを作ります。外部データソースにコピー元ファイルを設定しておきます。コピー側のテーブルオカレンスを、全て外部データソースを通してコピー元のファイルへ定義し直します。コピー側のファイルのテーブルを全て全て削除してみましょう。それでも、コピー側で同じ様に動きますね。

                                 分離モデル試したことがあります。便利そうですが、フィールド定義のバリデーションだけ、参照元に依存するのでしょうか。
                                 参照先、参照元、どちらが依存(利用)するかしっかり整理できていないと、混乱しそうですね。

                                 データベースそのものを全部MySQLにしている強者もいますね、外部データベースを参照するあたりをちょっと遊んで勉強してみたいなと思ってます。

                            • 11. Re: 検索条件の編集、その他について
                              Shin
                                   

                                        グローバルフィールドは便利ですよね。紛らわしいので、グローバルフィールド専用のテーブルに纏めるようにしています。
                                        話はずれますが、値一覧もテーブルを利用するように、ファイル含め分離しておいたほうが良いらしいですね。

                                   命名規則を使って区分しておきましょう。私は、グローバルフィールドは g_ で始めます。多用する時には、gT_ gN_ gD_ gI_ 等を使います。ちなみに、集計フィールドは  s_ を使っています。

                                   

                                        データベースそのものを全部MySQLにしている強者もいますね、外部データベースを参照するあたりをちょっと遊んで勉強してみたいなと思ってます。

                                   例えば、SQLserverなどのデータを、AccessやExcelで利用するのと同じ感覚でしょう。

                                   ただ、FM側からDB構造の編集はできません。

                              • 12. Re: 検索条件の編集、その他について
                                Nu-nrg
                                     

                                          命名規則を使って区分しておきましょう。私は、グローバルフィールドは g_ で始めます。多用する時には、gT_ gN_ gD_ gI_ 等を使います。ちなみに、集計フィールドは  s_ を使っています。

                                     アドバイスありがとうございます。最近フィールド名、スクリプト名、レイアウト名、テーブルオカレンス名に接頭辞、接尾辞をつけ始めました!
                                     webinar色々と見ると、それぞれ開発者さん命名規則まちまちですが、なんとなく共通のルールが見えてきます。
                                     定石みたいなものが纏められるといいですよね、wikiとかあったら便利。

                                     
                                          例えば、SQLserverなどのデータを、AccessやExcelで利用するのと同じ感覚でしょう。
                                     
                                          ただ、FM側からDB構造の編集はできません。
                                     DB構造を簡単に変更できるのがFMのいいところですよね。
                                     wordpressのエントリにFMからアクセス投稿するWebinar見ましたが、トランザクションというかリクエストの衝突とか接続ドライバーで管理してくれるんでしょうか。
                                     WebサイトのCMSにFMから投稿することができれば、情報登録の2度手間防げるので興味ありです。
                                     fm13ではhttpのメゾットpostが出来るみたいですが、DBを参照しなくてもリクエストとレスポンス処理をうまく活用出来るんでしょうかね。
                                • 13. Re: 検索条件の編集、その他について
                                  sago350@未来Switch

                                       >wordpressのエントリにFMからアクセス投稿するWebinar見ましたが、トランザクションというかリクエストの衝突とか接続ドライバーで管理してくれるんでしょうか。

                                       FileMakerは自動的に色々やってしまう所があるので、背後にSQLがあるということを意識した上でFileMakerの作りを考えなければなりません。SQLサーバー側から一方的にデータを貰うパターンはそんなに問題にはならないんですが、
                                       双方向になると、データを取得したタイミングやら修正したタイミングやらを意識した作りにしなければならなくなります。
                                       要はFileMakerで一般的なシステムっぽいシステムな作りを作らないとならなくなります。

                                  • 14. Re: 検索条件の編集、その他について
                                    Nu-nrg

                                         一方的に貰うだけよりも逆の方が必要そうです。もう少しファイルメーカー本体で管理できるといいですね。フォーラムタイトルから脱線しすぎました。(笑)