みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
サーバー：FileMaker Cloud クライアント：Windows10 FileMaker Pro Ver19.3
過去Q&Aやコミュニティでも検索にヒットせず、質問させて下さい。
グローバルフィールド主体で構成されたレイアウトに、日付でリレーションした出荷テーブルをポータル表示しています。
出荷テーブルには、商品コードや得意先コードのフィールドがあり、これらコードと別のテーブルに商品マスタや得意先マスタをリレーションしている構成です。
【簡易構成図】
[レイアウト]ー[ポータル]ー[各マスタ]
G日付 ー 出荷テーブル ー 商品マスタ
ー 得意先マスタ
※出荷テーブルのポータルには、フィルタ条件を指定しており、関連レコードに移動し、フィルタ条件のみのレコードを表示させてエクスポート（レコードをExcelとして保存）させています。
この構成で、出荷テーブルのデータをエクスポートすると、
フィールド数20（G日付、各マスタ含む）で約4000件くらいのデータでも約15分かかります。（レコードをExcelとして保存のスクリプトで）
試しに、出荷テーブルとリレーションしている、G日付、商品マスタの商品名、得意先マスタの得意先名などのフィールドをエクスポート対象から除外し、
出荷テーブルのみのデータをエクスポートすると、約10秒もかからず終了しました。
私のDB設定やスクリプト等が悪いのか、そもそもこの構成でのエクスポートは遅いのか、、、全くの思い違いをしているのか、
何か解決策をご教示頂きたく、よろしくお願い致します。
Offline
> 関連レコードに移動し、フィルタ条件のみのレコードを表示させ
これは、どのような動きになっていますか。フィルター条件を含めた移動でしょうか、それとも、リレーションだけでの移動で、さらに抽出しているのですか。
そこをデバッガーで実行すると、時間がかかっていませんか。
また、ポータルの表示は、どの程度の時間がかかっていますか。
> G日付、商品マスタの商品名、得意先マスタの得意先名などのフィールドをエクスポート対象から除外し
この一部のみの除外にしてみると、遅くなっている部分がわかると思います。
おそらく、フィルター条件かマスターテーブルの対象フィールドに索引の無い計算フィールドが入っているのでは。
Offline
Shin様 ご返信ありがとうございます。
ご質問内容を元に確認し、以下ご連絡いたします。
>関連レコードに移動し、フィルタ条件のみのレコードを表示させ
>これは、どのような動きになっていますか。フィルター条件を含めた移動でしょうか、それとも、リレーションだけでの移動で、さらに抽出しているのですか。
→関連レコードへの移動について、リレーションでの移動・抽出はしておらず、別作成のリスト形式のエクスポート用レイアウトに「出荷テーブル」を設定し、
「関連レコードのみを表示」＋「現在のレコードのみ照合」にチェックを入れて移動しております。
※「フィルタ条件を含めた移動」の意味が理解できていませんが、おそらくこの方法なのでは？と思っています。
>そこをデバッガーで実行すると、時間がかかっていませんか。
→スクリプトデバッガでは、関連レコードへの移動には時間はかかっておりません。
「レコードをExcelとして保存」スクリプトのみで時間がかかっております。
>また、ポータルの表示は、どの程度の時間がかかっていますか。
→G日付の条件を指定し、約5秒以内でポータル一覧が表示されています。ですので、フィルタ条件による遅延ではないのでは？と考えております。
念のため、出荷テーブルのポータルフィルタ条件について記載します、
レイアウトに設定している、G日付の他、グローバルフィールド得意先（以下G得意先）、G項目１ を設定しており、
G得意先、G項目１は、それぞれ値一覧で取得したリストを、チェックボックスで選択できるようにしており、チェックボックスで選択した内容を、フィルタで絞り込んで表示させています。
【ポータルフィルター設定】
Case ( IsEmpty ( レイアウト::g_得意先 ) ; 1 ;
PatternCount ( Substitute ( レイアウト::g_得意先 ; "¶" ; " ") ; 出荷テーブル::得意先CD外部キー))
and
Case ( IsEmpty ( レイアウト::g_項目１ ) ; 1 ;
PatternCount ( Substitute ( レイアウト::g_項目１ ; "¶" ; " ") ; 出荷テーブル::項目CD外部キー))
> G日付、商品マスタの商品名、得意先マスタの得意先名などのフィールドをエクスポート対象から除外し
>この一部のみの除外にしてみると、遅くなっている部分がわかると思います。
>おそらく、フィルター条件かマスターテーブルの対象フィールドに索引の無い計算フィールドが入っているのでは。
→出荷テーブルとリレーションしている、マスタテーブルの中に、リレーション条件には指定してませんが、計算フィールドが１つだけありましたので、
このマスタとのリレーションを除外しましたが遅いままでした。
その他のマスタテーブルのフィールドは、テキストや数字のみで計算や集計フィールドはありません。
※マスタには入力時の制限計算や、入力時の自動計算はあります
※出荷テーブルには、複数の計算や集計フィールドがあります。
そのほか、フィルター条件に利用しているフィールド、出荷テーブルと各マスタとのリレーション条件に利用しているフィールド全てにインデックスが設定されている事を確認しています。
次に各マスタとリレーションしているフィールド項目を、１つずつエクスポート対象から除外してそれぞれ試してみましたが、結果特定マスタを除外したら早くなるということはなく、何か１つでも出荷テーブルとのリレーションがあるマスタ項目が含まれていると遅くなるという結果になりました。
ここまでの回答で、何か原因と思われる内容はございますでしょうか？
よろしくお願いいたします。
Offline
ExcelでなくCSVでエクスポートしてみたらどうですか？
解決案ではないのですが
ポータルフィルタのSubstitute 関数は意味がないです。改行でもスペースでも1文字なのでPatternCountには影響がないです。（12345改行23456 に52345が含まれたりはしない）
>フィルター条件に利用しているフィールド、出荷テーブルと各マスタとのリレーション条件に利用しているフィールド全てにインデックスが設定されている
ポータルフィルタは関連レコードすべてについて計算式を評価するので、インデックスは無関係です。
リレーションの方は関連先フィールドにインデックスがなければそもそも機能しません。
「レコードをExcelとして保存」で書き出すフィールドの中に、非保存の計算フィールドが多数含まれているのでは。
Offline
> 出荷テーブルとリレーションしている、
> G日付、商品マスタの商品名、得意先マスタの得意先名などのフィールド
これらをルックアップとして自身のフィールドにしてみたらいかがでしょう。
Offline
皆様、ご返信ありがとうございます
himadanee様
Substitute関数及び、リレーション仕様のご指摘ありがとうございます。
おっしゃる通り、Substitute関数を取り除いても、動作に問題ありませんでした。おかげさまで余計な処理を省くことができました。ありがとうございました。
>ExcelでなくCSVでエクスポートしてみたらどうですか？
→こちらは、CSVでのエクスポートも試しましたが結果変わらずでした。
Shin様
>「レコードをExcelとして保存」で書き出すフィールドの中に、非保存の計算フィールドが多数含まれているのでは。
→書き出すフィールドの中を再度１つずつ確認しましたが、日付、数字、テキストのみで、非保存の計算フィールドは含まれていません。
関係ないと考えていましたので記載しておりませんでしたが、補足しますと、出荷テーブルのポータルには、出荷数量の合計など、複数の非保存計算フィールドを配置しております。
ただ、エクスポートの際は、関連レコードへ移動しエクスポート用のレイアウトに変更して出力しているので、関連はないと考えております。
チポ様
対応案ありがとうございます。
最終的に原因が分からない場合は、出荷テーブルにルックアップフィールドを追加し、各マスタデータを出荷テーブルに持つと良いのかな？と考えておりました。
この方法を実際に試して効果があった場合は、最終案として確保しようと思います（何となく・・もやっっとしますので）
Offline
エクスポートに、レイアウトは関係無いです。動作の確認のために、エクスポートするフィールドを全て含めたレイアウトを作り、行の移動ではなく、最後までスクロールで表示させると遅くないですか。
エクスポートするフィールドに、非保存フィールドが含まれるかなんですが。関連レコードのフィールドが含まれていませんか。
Last edited by Shin (2022-03-28 13:00:15)
Offline
Shin様
大変お世話になります。
エクスポート用レイアウトはエクスポートするフィールド全て配置していますので、このレイアウトでスクロール動作確認しました。
結果、エクスポートしたいフィールド含む状態ではスクロールは遅く、各マスタを除外すると、スクロールは早くなります。
>エクスポートするフィールドに、非保存フィールドが含まれるかなんですが。関連レコードのフィールドが含まれていませんか。
→私の認識では、非保存フィールドは計算、集計フィールドなのですが、「関連レコード」のフィールドも非保存フィールドとなるのでしょうか？
もしかして、以下構成に問題があるのでしょうか？
【簡易リレーション構成図】 －(リレーション)
[レイアウト]G日付 ー [ポータル]出荷テーブル ー 商品マスタ
ー 得意先マスタ
エクスポート用レイアウト(テーブル：出荷テーブル)に配置しているフィールド設定の一部ですが、
レイアウト::G日付、出荷テーブル::商品コード 出荷テーブル_商品マスタ::商品名、出荷テーブル::得意先コード、出荷テーブル_得意先マスタ::得意先名
ここで、「出荷テーブル_商品マスタ::商品名」や、「出荷テーブル_得意先マスタ::得意先名」が関連レコードで、非保存扱いとなるため遅くなる、、という事でしょうか？
Offline
> エクスポートしたいフィールド含む状態ではスクロールは遅く、
最終までスクロールした後、上へ戻るスクロールや、再び最終までのスクロールはどうですか。
商品や得意先の主キーは何を使っていますか。通し番号などの数値なんでしょうか、文字を含んだテキストでしょうか。
「出荷テーブル_商品マスタ::商品名」や、「出荷テーブル_得意先マスタ::得意先名」が関連レコードで、非保存扱いとなるため遅くなる、、という事のようですね。
チポさんの提案にもあるように、これをルックアップしておくと、早くなると思います。ただし、ファイルは大きくなります。
または、サーバーサイドで excel ファイルを作り、それをスクリプトを結果としてこちらに転送する、という処理をためして見られたらいかがでしょう。劇的に早くなる可能性はあります。
Cloud はテスト運用しかしていませんので詳しくはないですが、今回のように、クラウドから大量のテキストを一気にダウンロードするような処理は、結構苦手なような感じです。
Last edited by Shin (2022-03-28 15:01:03)
Offline
影響あるかどうかわかりませんが、マスタの主キーにユニーク制限がしてありますか？
（関連レコードが1つしかないことの保証）
関連レコードのフィールドをエクスポートに含める場合、エクスポートするテーブルの1レコードに対してエクスポート結果が複数行になるかどうかで、だいぶ処理の複雑さが違うと思うんですが、どうなのかな。
Shin様
早々にご返信頂きありがとうございます。
>最終までスクロールした後、上へ戻るスクロールや、再び最終までのスクロールはどうですか。
→遅い時は、最後までスクロールした後、上に戻る場合、再び最終までスクロールする場合、どのパターンも遅い状態です（データがカクカク表示されるイメージ）
>商品や得意先の主キーは何を使っていますか。通し番号などの数値なんでしょうか、文字を含んだテキストでしょうか。
→出荷テーブルでリレーションしている主キーは、通し番号数字の他、８桁の数字主キー、文字のみのテキスト主キー、検索の為に、内容は数字ですがテキストタイプにしている主キーもあります。
数字と文字を混合させての主キーはありません。
解決策として、まずチポ様案を今から試してみようと思いますが、
>サーバーサイドで excel ファイルを作り、それをスクリプトを結果としてこちらに転送する・・・
→こちらの方法は具体的にどのようなスクリプト構成になるのでしょうか？
クラウドサーバーで、サーバー側ディレクトリに保存する方法が分からず・・・
「レコードをExcelとして保存」 の保存先にオブジェクトフィールドを設定できる？
解決策を提示して頂いて申し訳ございませんが、実装スキルが追い付かず、ご教示頂けますと幸いです。
Offline
himadanee様
ご返信ありがとうございます。
なるほど～、と思い、早速、確認、試してみました。
マスタの主キーには、ユニーク制限を設定していましたので、対象マスタのユニークを全て解除。
解除後に試してみましたが・・・結果変わらず、遅いままでした。
解決案のご提示ありがとうございます。
引続き、よろしくお願い致します。
Offline
ネットワークが遅くないですか。適当なスピード側底サイトで測ってみてもいいかも。数十Mbps以上なら問題ないでしょうが。
サーバースクリプトでは、ファイルをテンポラリーフォルダーへ保存します。それをオブジェクトフィールドか変数へ取り込んで、、現在のスクリプト終了 で、結果としてファイルを添付すればいいはずです。
クライアントでは、結果を Get ( スクリプトの結果 ) で受け取り、ファイルとして書き出せばいいです。ローカルでも実験できますので、お試しください。
Excel ファイルが絶対必要ですか。csvの方がファイルが小さいですし、データファイルとして扱えますので、色々と楽ですし、処理も早いです。
例えば、
変数を設定 [ $tmp ; 値: Get ( テンポラリパス ) & "tmp.xsl" ]
レコードを Excel として保存 [ 記憶する ; ダイアログあり: オフ ; 「$tmp」 ; 対象レコード ; フォルダを作成: オフ ]
ファイルを挿入 [ ターゲット: $file ; 「$tmp」 ]
現在のスクリプト終了 [ テキスト結果: $file ]
というスクリプトを、
スクリプト実行 [ 指定: 一覧から ; 「tmp file」 ; 引数: ]
変数を設定 [ $$tmp ; 値: Get ( スクリプトの結果 ) ]
で呼出します。（ローカルでの試験）
実働は、サーバースクリプトを実行、で行います。
Last edited by Shin (2022-03-28 16:25:23)
Offline
Shin様
ご返信ありがとうございます
ネットワークは15Mbps程ですので大丈夫と思っています。
また、Excelにはこだわってませんので、csvファイルで取得するように変更致します。
サンプルのご提示ありがとうございます。大変助かります。
なるほど、Get(テンポラリパス)だと、クライアントPCのテンポラリディレクトリしか取得できないと思っておりましたが、
今更ながら今日初めて「サーバー上のスクリプト実行」というコマンドが存在する事を知りました・・・。
※ほかのテンポラリを利用した処理が色々と残念な内容に変わった気がしてます。
サンプルを参考に試してみたいと思います。
少々結果のご連絡が遅れるかもしれませんが、引続きよろしくお願い致します。
Offline
Shin様
サンプルを参考に試してみました、
結果、「サーバー上のスクリプト実行」スクリプトで、「3:コマンドが使用できません」となりました。
スクリプトワークスペースの互換性で、サーバーを選択した所、「サーバー上のスクリプト実行」は、灰色表示となりましたので、
FileMaker Cloudではサポートされていないとの判断でよろしいでしょうか？
それとも何か実装方法などに間違いがあるのでしょうか？
参考までに作成したスクリプトは以下になります。
スクリプト名：出力一覧取得
[スクリプトの内容]
変数を設定[$tmp; 値：Get(テンポラリパス) & "tmp.csv"]
レコードのエクスポート [ダイアログあり：オフ；フォルダを作成：オフ；「$tmp」； 日本語(Shift-JIS)]
ファイルを挿入[ターゲット：$file；「$tmp」]
現在のスクリプト終了[テキスト結果：$file]
呼び出しスクリプト
[内容抜粋]
（関連レコードへ移動して、出力用データ一覧が表示されている状態）
サーバー上のスクリプト実行[指定：一覧から；「出力一覧取得」；引数： ；終了するまでまつ：オン] ←ここで、3:コマンドが使用でませんのエラー
変数を設定[$$tmp；値：Get（スクリプトの結果）]
以上、よろしくお願い致します。
Offline
呼び出し用のスクリプトは、ローカルの FIleMaker pro で実行しますので、関係ないですよ。
サーバー側のスクリプトは、まっさらな状態でファイルが開かれています。エクスポートの前処理も組み込んでください。
Offline
Shin様
ご連絡ありがとうございます
>呼び出し用のスクリプトは、ローカルの FIleMaker pro で実行しますので、関係ないですよ
→なるほど、クライアント側のFileMaker Proで互換性を表示させても、クライアント側の判定になるのですね
>サーバー側のスクリプトは、まっさらな状態でファイルが開かれています。エクスポートの前処理も組み込んでください。
→あぁ～なるほど、クライアント側の処理だけでやってきたので、サーバー側処理という意識が足りてませんでした。
再度見直して出直してきます。
Offline
>呼び出し用のスクリプトは、ローカルの FIleMaker pro で実行しますので、関係ないですよ
→なるほど、クライアント側のFileMaker Proで互換性を表示させても、クライアント側の判定になるのですね
解釈が違うのでは。
エクスポートするスクリプト１をサーバ上で実行したい。
そのスクリプト１を「サーバー上のスクリプトを実行」で実行するスクリプト２は、クライアント上で実行する。
なので、スクリプト1の互換性はサーバで、2の互換性はProのを見ればいいのですが、
スクリプト2をサーバのスケジュールなどサーバ上で実行させたい場合は違ってきます。「サーバー上のスクリプトを実行」でなく「スクリプトを実行」に変える必要があります。
（Ifで環境を見て分岐させてもいいが）
スクリプトワークスペースの互換性表示の問題でなく実際にエラー3が出てるというのは、サーバ上で全体を実行したいのですか？
himadanee様
ご返信ありがとうございます。
>エクスポートするスクリプト１をサーバ上で実行したい。
>そのスクリプト１を「サーバー上のスクリプトを実行」で実行するスクリプト２は、クライアント上で実行する。
→おっしゃる通りです
>なので、スクリプト1の互換性はサーバで、2の互換性はProのを見ればいいのですが、
>スクリプト2をサーバのスケジュールなどサーバ上で実行させたい場合は違ってきます。「サーバー上のスクリプトを実行」でなく「スクリプトを実行」に変える必要があります。
→内容は理解できます。
ここで、私のFileMaker経験が、Cloudが初めてでして、FileMaker Serverを経験した事がなく、スクリプト１の互換性をCloudサーバーで見る方法を知りません。
（今更ですが、この経歴は最初に記載すべきでした、申し訳ございません）
Claris Customer Console や FileMaker Cloud Admin Console を眺めていますが、スクリプトスケジュールを設定できるメニューはありますが、
スクリプトの編集などをできるメニューを見つけきれておりません
やりたい事は、
ユーザー操作をトリガーに、データ出力（エクスポート）をしたいが、エクスポートが非常に遅かったため、
サーバー側で出力用データ作成して、作成したファイルのダウンロードに変更すると、速度が改善されると考えられるため、以下の処理を検討しております。
１．クライアントでユーザー操作トリガーにより、サーバー側でのデータ作成の指示
２．サーバー側でデータ作成
３．クライアントで、サーバー側の処理結果であるデータを取得し加工＋表示
FileMaker Cloudが原因で、私のスキル範疇を超えてきそうになったら、とりあえず修正優先で、
正規化とは・・・と、もやっっとしている、ルックアップで出荷テーブルにマスタデータを含めた方法で対応しようかとも考えている所です。
この表現でお伝えできましたら幸いですが、ご不明な点や認識違いなどございましたら連絡いただければ幸いです。
Offline
>ここで、私のFileMaker経験が、Cloudが初めてでして、FileMaker Serverを経験した事がなく、スクリプト１の互換性をCloudサーバーで見る方法を知りません。
いや、そのことを解釈が違うと言ったので、
互換性を見るのは、Proのスクリプトワークスペースで右上のドロップダウンから切り替えれば各実行環境での互換性が表示されます。
Pro以外にはスクリプトを編集する機能はありません。
himadanee様
あぁ～、、これまでの解釈違いをやっと理解できました。
ご指摘ありがとうございます。
引続き、サーバー側処理の見直しを実施し、結果をご報告いたします。
Offline
スクリプトそのものは、#14にある通りでいいのですが、レコードを書き出す前に、レコードの絞り込みが必要なはずです。
日付と得意先、項目１で絞り込みを行えばいいのでしょうが、#2 でお尋ねしていますが、関連レコードへ移動 した際の対象レコードは、ポータルフィルターに条件が加味されていますか、それとも、日付条件だけになっていますか。（関連レコードへ移動には、隠れ機能があり、普通に移動するときと、ポータルの中から移動するときでは動作が異なります）
日付と得意先、項目１の条件をスクリプト引数としてスクリプト1に渡し、明細側のテーブルで検索を行えばいいでしょう。
その処理がちょっとだけ面倒ですが、ローカルでスクリプトを動かしながら検証できるの、頑張ってみてください。
Last edited by Shin (2022-03-29 13:26:33)
Offline
別作業などで、検証、ご報告が遅くなりました。申し訳ございません。
Shin様
サーバー側処理の流れのご教示、大変ありがとうございました。助かりました。
また、関連レコードへ移動した際、表示されているレコードは、ポータルフィルタ条件で絞り込んだレコード内容のみが表示されていますので、
ポータルフィルタが有効なデータを取得できていると考えています。
下記、呼び出し側スクリプトに、関連レコードへの移動する前の処理も記載しております、
対象データがあるかの判定に利用しておりますが、この処理が意図せず、フィルター条件が加味された思い通りの結果になっているという事なのでしょうか？
途中経過ではありますが、一定の結果が出ましたのでご報告いたします。
【サーバーサイドの処理時間】
・関連レコードの得意先マスタ等を含めた状態での約1か月分エクスポート時間 → 約30秒 ファイル容量 約600KB
・ 上記＋ 約3か月分エクスポート時間→ 約1分30秒 ファイル容量 約2000KB
・関連レコードのマスタ含めず、ルックアップで出荷テーブルにまとめた場合の約1か月分エクスポート時間→ 約8秒 ファイル容量 約600KB
【ルックアップで出荷テーブルにまとめた場合のエクスポート（クライアント処理）】
約１か月分のエクスポート時間→ 約1秒 ファイル容量 約600KB
サーバーサイドの処理内容が正しいのか、という根本問題はありますが、
ルックアップで一部のマスタを出荷テーブルに追加する方法が、1番高速にエクスポートできましたので、チポ様案でいきたいと思います。
チポ様、ありがとうございます
参考までに検証したスクリプトを以下記載します（細かな入力仕様は省いてます）
---------------【サーバーサイド】スクリプト名：出力一覧取得 ----------------------------
レイアウト切替[出荷エクスポート用 （エクスポート用）；アニメーションなし]
変数を設定[$tmp; 値：Get(テンポラリパス) & "tmp.csv"]
変数を設定[$日付_前; Get(Value(Getスクリプト引数); 1 )]
変数を設定[$日付_後; Get(Value(Getスクリプト引数); 2 )]
# 検証の為、他条件である、得意先マスタや項目１の条件フィルターは入れてません、他スキルの問題で時間がかかりそう、というのが1番の理由ですが・・・。
検索モードに切り替え[一時停止：オフ]
フィールド設定[エクスポート用::日付； $日付_前 & "..." & $日付_後]
フィールド設定[エクスポート用::削除フラグ; 0]
レコード/検索条件確定[ダイアログあり:オフ]
検索実行[]
レコードのエクスポート[ダイアログあり:オフ；フォルダを作成:オフ; 「$tmp」； 日本語（Shift-JIS)]
// ファイルを挿入 [ターゲット：$file；「$tmp」]
# この「ファイルを挿入」コマンドはサーバーサイドでは未対応でした
ファイルサイズを取得[「$tmp」; ターゲット: $tmp2]
# サーバー側でエクスポートしたファイルをクライアント側に持ってくる処理を色々試していますが、
# 今の所うまくいかず、時間が空いた時に再度調査しようと思っていますが、最低限、作成したファイル容量で判断
現在のスクリプト終了[テキスト結果：$tmp2]
------------------------------------------------------------------------
※スクリプトトリガ OnFirstWindowOpen
メニューセットのインストール[「ユーザー用」；ファイルデフォルトとして使用：オン]
ツールバーの表示切替[隠す]
-----------------【呼び出し側】-------------------------------------
・・色々な前処理・・
オブジェクトへ移動[オブジェクト名：”出荷一覧ポータル”]
ポータル内の行へ移動[選択：オフ；最初の]
If [get(最終エラー)=101]
カスタムダイアログを表示[”警告”；”出力”対象がありません]
現在のスクリプト終了[テキスト結果：False]
End If
関連レコードへ移動[関連レコードのみを表示：テーブル：「エクスポート用」；使用するレイアウト：「出荷エクスポート用」（エクスポート用）]
変数を設定[$Start; 値：Get（タイムスタンプ)]
サーバー上のスクリプト実行[指定：一覧から；「出力一覧取得」；引数：レイアウト::G日付前 & "¶" & レイアウト::G日付後; 終了するまで待つ：オン]
変数を設定[$tmp; 値：Get（スクリプトの結果）]
カスタムダイアログを表示[”処理時間”; $tmp & " " & Get(タイムスタンプ) - $Start]
------------------------------------------------------------------------------------
以上になります。
Offline
[ Generated in 0.010 seconds, 10 queries executed - Memory usage: 675.74 KiB (Peak: 724.28 KiB) ]