2がFileMakerHacksで公開されましたのでご紹介します。Tricksのパート2にようこそ。今日紹介するものの中にはパート1の内容を前提にしているものがいくつかあります。見ていないのであれば、そちらをチェックしてから続きを読むことをお勧めします。最初は、ExecuteSQLのチップスを2つ紹介します。COALESCEを知るSQLのCOALESCE関数は、複数の引数をとり、ヌルでない最初の結果を返します。)たとえば、以下の内容の顧客情報テーブルがあります。zipの項目を持ったリストをテキスト形式で作成するよう依頼を受けました。nameを挿入します。21014もちろんSQLを使わないFileMaker流のアプローチもいくつかあります。実装の手軽さという点ではこの方法がもっとも簡単ではないでしょうか。FM/SQLの日付データ再考パート1で紹介したとおり、日付データはSELECT文では以下の形式で返されます。YYYY-MM-DDこのデータをSQLの世界の中で引き続き操作するのであれば問題ないのですが、FileMakerにはこのままでは理解できません。変換するという方法でした。Sabauさんからのコメントで、COALESCE関数を使ってFileMakerが理解できる形式に強制的に変換する方法を紹介いただきました。)結果は次のようになります。COALESCE句の2つ目の引数は、シングルクオートのペアです。「date」はSQLの予約後なのでエスケープ処理(ダブルクオーテーションの前のバックスラッシュ)が必要です。Coding」を参照してください。Edoshinから教わったチップスです。あるレイアウトオブジェクトを、特定のレイアウトでだけ表示したいという場合です。20当然この計算式をそのまま「次の場合にオブジェクトを隠す」の条件に適用したいと思うでしょう。20しかしそれは、解決したい現実世界の問題を特定した後に、改めてそのまったく逆の場合を定義し直すことになります。)もちろん条件式が単純であればどちらにしても大した違いはないかも知れませんが、条件式が複雑になればなるほど、このアプローチは効果が出るでしょう。代わりに””を使うデザイン関数の多くは1つ目の引数にファイル名をとります。これは非常に良い方法ですが、代わりにダブルクオーテーションのペアを使うこともできます。次のいずれも同じ結果を返します。上のチップスへの追記なお、空のダブルクオーテーションのトリックは、レイアウト名が引数の場合は、一見動作するように見えても、ファイル名の場合と同じように動作するわけではないので注意してください。FieldNames関数とFieldIDs関数はどちらも以下の2つの引数をとります。(つまりファイル内のもっとも古いテーブル)上のすべてのフィールドが返されます。言い換えると、表面上正しく見えるものが、(たまたまその最初のテーブルに基づくレイアウトにいる場合を除いて)実際にはそうではないということになります。)の代わりに””を使用した場合、何も返されません。上のチップスへの追記2この話題を終わる前に、FieldNames関数とFieldIDs関数に触れないわけにはいかないでしょう。レイアウト名の引数の部分にテーブルオカレンス名を指定して、かつファイルにそのテーブルオカレンス名と同じ名前のレイアウトが存在しない場合、これらの関数は、特定のレイアウトではなく、元となるテーブルのすべてのフィールドを参照します。あるソリューションにSettingsという名前のテーブルオカレンスが存在し、Settingsというレイアウトが存在しない場合、テーブルのすべてのフィールド名を返します。Settingsという名前のレイアウトを作成し、いくつかフィールドをレイアウト上に配置すると、当然ですがレイアウトの方が優先されます。12,13のソリューションで使用する未だにFM12または13を使いながら、FM14のチェックマークオプションが羨ましいと感じている方へ。ファイルをFM14で開いて、チェックボックスの設定でチェックマークを表示するよう定義すると、なんとチェックマークがFM12でも利用できます。コピースクリプトステップをコピーするとコンピュータのクリップボードの内容が上書きされてしまうという点は除いて、既存の「レコードのインポート」スクリプトステップをコピー&ペーストするよりも複製する方がいい理由はあるでしょうか?答えは、何をしたいか・何を期待するかによって「YES」でも「NO」でもあります。2行目のオリジナルのステップを詳しく見てみましょう。「照合名順」が指定されていることに注目してください。次に5行目の複製されたバージョンを見てみましょう。予想どおり、内容は2行目のオリジナルと同じです。移動の途中で「照合名順」の情報は失われました。理由は以下のとおりです。スクリプトステップをペーストしたとき、実際に裏でペーストしているのはXMLコードであり、「レコードのインポート」のXML表現には「配置順」の設定は含まれていません。基本的に「レコードのインポート」スクリプトステップをペーストした場合、配置順は常に「最後に使用した順序」になります。スクリプトステップを複製した場合、FileMakerは別の内部機構を利用して配置順の情報も保持されます。(データベースデザインレポート)を生成した場合に、オリジナルの「レコードのインポート」スクリプトステップがどう表示されるかを示したものです。ソースフィールドは作成順で(名前順ではなく)並び、配置順の情報はありません。コンテキストメニューからの検索/絞り込み/拡大フィールドを右クリックして「一致するレコードを検索」、「対象レコードの絞り込み」、「対象レコードの拡大」を選択できることはすでにご存知かと思います。結果として、クリックしたフィールドに一致するレコードを検索できます。私はつい最近(しかも偶然に)見つけたので、もしかしたら初めて知ったという方もいるかも知れません。結果は以下のようになります。理由はこの後に述べていますが、このチップスを自分で試す場合は必ずバックアップ・コピーに対して行ってください。]次のような、データ整理の手順を自動化したスクリプトがあるとします。次の処理に進む前に、それが安全かどうかを確認してください。エラー処理の手順は複雑になる場合もあり、この記事ですべてカバーすることはできませんが、少なくとも以下のような処理を入れることができます。ちなみにレイアウトが存在しない場合のエラーコードは105です。FileMakerのエラーコードの全リストは次のリンクから参照できます。文字の「?」はブール値ではtrueと評価されるなぜこれがチップスになるのかというと、以下のようなコードをよく目にするからです。If変数の$theBooleanVarが“?”になることは絶対にないと保証できればこのままで問題ないですが、If文に少し追加して以下のようにするのは大した手間ではないはずです。If“?”がTRUEに評価されるという根拠を以下に示します。