みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
Shin様
そうなんです。FM15でつなげられるのでファイルを開いたり閉じたりしてなんとかなっています。基幹システムからのメインの取り込みは今も1台ですが、各端末の作業でも少しアクセスしたいところがありややこしいことになってしまいました。FM19から直接ODBC接続できたほうがよいので、改めてシステム部門と相談してみます。ご助言ありがとうございました。
himadanee様
同じPC内に、FM15から基幹サーバに繋ぐファイルと、FM19からFMSに繋ぐファイルを置いてデータを受け渡ししています。スクリプト！求めていたものです。ありがとうございます。相対パスも全体を変数にしても効かず、端末ごとにパスを書き換えるしかないものとあきらめておりましたが、そこを変数にするのですね。さっそく明日やってみます。ありがとうございました。
端末は電子カルテの端末に同居しており、イントラネットの中だけで運用しています。
バージョンダウンの問い合わせ、基幹システム的に無理そうと判明したら検討してみます。ありがとうございました。
ところで、このスレッドでお聞きしたかったのは以下の内容でした。難しいものでしょうか。
各端末の同じ場所（例：デスクトップ）に保存した同名ファイルを、現在起動しているFMP以外のソフトを指定して開きたい。
共通のスクリプト「EVENTを実行」またはほかの手段で実行可能か、それとも端末ごとにスクリプトを変更するしかないか。
Shin様
端末にドライバ入れれば64bitで繋がるようになりそう、とは思うのですが、そういった設定をするにはシステムの会社に問い合わせて方法を聞かないと弊社システム担当部署ではできないとのことで返答まちです。
それまでのつなぎ兼万一できなかったとき用のつもりなのですが、EVENTを実行で細かいことをするのは難しいでしょうか。
オブジェクトのサイズはテキストを書き換えるとすぐ変わってしまうものと諦めている勢です。
フォントを小さくしておいて、ボタンサイズを合わせてからフォントを大きくしたらうまく小さいままでいてくれたこともあったような気がしますが定かではありません。
泥臭い方法で恐縮ですが、ぎりぎりまで文字を表示したいとき、当方では、ボタンのテキストは空にしておいて、その上にテキストボックスを重ねています。
himadanee様
ありがとうございます。
各端末に標準で入っているのは32ビット版だけです。
64ビット版が使えるのか、できるならその設定方法を、基幹システムの会社に問い合わせ中です。
今回繋がらなくて調べただけなので詳しくないのですが、そもそもデータソースというのは、サーバ（機種は問わない）にあるデータテーブルに端末からアクセスするための道具という認識で良いのでしょうか。そうなら端末の設定でなんとかできるのではと考えているのですが……。
Shin様
ありがとうございます。
大丈夫と考えています。
FM15が永年版でひとそろいありまして、
今回は、バージョン間が空きすぎていてバージョンアップできず、サーバのハードから全部新規購入となりました。
各端末には、FM15（FMS15に接続）とFM19（FMS19に接続）が共存している状態です。
（FMPro15からFMS19、FMPro19からFMS15は認識しないのでappファイルもわけてつくりました）
お世話になっております。
Filemaker Pro15 FMサーバ15
windows7,10（端末混在）
社内イントラネットで使用しています。
基幹システムからデータをインポートして、ユーザーが検索したり中身を確認して処理済みチェックをつけたりするような仕組み（処方監査、薬歴管理）を引き続き作成しています。
この度、FMサーバが15から19へバージョンアップすることとなりました。あわせて端末環境もFMPro19、windows10となり、
現在更新作業中です。
社内の基幹システムからODBC経由でデータを取り込んでいるのですが、基幹システムの設定でwin32版のデータソースしかないためFM19でアクセスできず、一度FM15でインポートしたデータをFM19からFMS19にインポート、というスクリプトを組みました。（スクリプト構造は最後に示します）
1端末で一定時間ごとに繰り返し取り込みを行うことはできたのですが、各端末から任意のタイミング（使用者のボタン押下）で動作させる必要があり、こちらについて困っています。
「EVENTを実行」スクリプトの実行先にテキストで、FM15.exeで作業用appを開くように指定したのですが、作業用appをフルパスで指定する必要があり、かつ変数指定ができません。同内容のショートカットファイルを作ってファイル指定してみたところ、プログラムが起動しただけでappは起動しませんでした。
各端末に端末ごとのパスで作成した起動専用appを配置すれば行ける気がしますが、台数が20台を超えており躊躇しています。
なにか良い方法はありませんでしょうか。
ファイル：FM19作業用.fmp12、FM15作業用.fmp12
（１）FM19作業用スクリプト
ファイルを閉じる（FM15作業用）
EVENTを実行：ファイルを開く：テキスト（"FM15.exeフルパス" FM15作業用.fm12フルパス）
スクリプトを一時停止（FM15作業用スクリプトが完了し、作業完了フラグが立つまで）
ファイルを開く（FM15作業用）
インポート（FM15作業用→FM19サーバの保管ファイル）
ファイルを閉じる（FM15作業用）
現在のスクリプトを終了
（２）FM15作業用スクリプト（on first window open）
フィールド内容のエクスポート（フィールド指定なし・作業完了フラグファイルを消す）
作業用テーブルのレコードを全削除
インポート（SQLserver経由 基幹システムサーバ→作業用テーブル）
フィールド内容のエクスポート（作業完了フラグファイル作成）
ファイルを閉じる（現在のファイル）
Moz様、himadanee様
リレーションキーを1つにしたらとても速くなりました。
ひとまずこれでやってみようと思います。
ありがとうございました！！
チポ様
横からありがとうございます。
>テーブルCのレイアウトにある、
>テーブルD::監査状況コード
>フィールドを検索する。
>ということでしょうか？
テーブルCのレイアウトで、検索実行スクリプトから検索する、です。フィールドは置かなくても検索できると聞いたのでやってみました。
> Cが更新毎に新規レコードとなるの
>更新前のレコードはそのまま有るんでしょうか？
リレーションキーすべてを維持したレコードという意味ではそのままありますが、中身は削除された旨の表記に書き換わります。
Shin様
遅くなってしまうものなのですね……。
ありがとうございます。
関連テーブルへ移動するには一度テーブルDのレイアウトに行ってそこから、という手順になりますか？ （レイアウトを作っていないものでちょっと気になりました）
>> Cが更新毎に新規レコードとなる
>ということは、更新されれば新たに監査対象になるのでは。
そのとおりです。テーブルDのレコードも新しく作ります。…無理に変更前のと繋ぐ必要はなさそうですね。
この先挙動見て、テーブルの統合も検討してみます。
テーブルDで検索すると速いです。
監査状況コードフィールドの索引を再作成してみましたが変わりませんでした。
リレーションの、複合キーへの変更を試してみます。
リレーションに用いている他のフィールドも索引の再作成をしてみたほうがよいでしょうか。
ありがとうございます。
「監査状況コード」はどのテーブルにあるのでしょうか？
テーブルDにあり、テーブルCとリレーションしています。（説明記載に誤りがあったので直しました。すみません）
非保存の計算フィールドはパフォーマンスへの影響を配慮されることが多いのですが、
別のテーブルのフィールドをリレーション越しに検索する場合も同様に配慮が必要です。どうしても必要ならば「監査状況コード」を除いた条件で検索したのち「監査状況コード」で［対象レコードの絞り込み］を行うと良いかも知れません。
ご指摘の通り、他条件で検索後に絞り込みをしても、変わらず異常に時間かかってしまうのです。テーブル内にデータを同梱させることも考えたのですが、Cが更新毎に新規レコードとなるので、更新前後のデータと関連付けるには別テーブルの方が使い勝手が良さそうなのでなんとかできるならなんとかしたいのです。
リレーション条件数の多寡は影響するものでしょうか？
お世話になっております。
Filemaker Pro15
windows7,10（端末混在）
社内イントラネットで使用しています。
基幹システムからデータをインポートして、ユーザーが検索したり中身を確認して処理済みチェックをつけたりするような仕組み（処方監査、薬歴管理）を引き続き作成しています。
リレーションを通じた検索条件の一部が異常に遅く、原因が掴めないためご相談に参りました。
基幹システムから取り込むデータのフィールドは以下のようになっており、同名のフィールド同士で=リレーションします。
テーブルA：伝票番号 伝票作成日 診療科 伝票情報
テーブルB：伝票番号 伝票作成日 診療科 処方日 Rp番号
テーブルC：処方日 Rp番号 Rp内番号 更新番号 患者コード 薬品コード 処方量など
リレーション：テーブルA−テーブルB−テーブルC
A：B、B：Cはそれぞれ１：多
これに、患者テーブル::患者コードや、薬品テーブル::薬品コードなど他テーブルと=リレーションを組んでいます。
そこに、監査状況を記録するテーブルを新設し、
テーブルD：処方日 Rp番号 Rp内番号 更新番号 監査状況コード 担当者コード 監査日時
としてテーブルCと=リレーションさせました。
以上の条件でテーブルCの表示用レイアウトから検索する場合、「監査状況コード」（テキストデータ）をキーにして（コード=1で）検索をするととても遅く、8万件から2件探すのに数十秒かかってしまいます。（ほかの条件もあるのですが、この条件を削除するとほぼ一瞬で抽出できます）
計算は使っておらず、フィールドはタイプを揃えてすべて索引作成設定にしています。ファイルが別ファイルですが他のマスタも別ファイルのものはありますし、なぜこれだけが遅いのか、また解決策はあるのか、ご教示いただけましたら幸いです。どうぞよろしくお願いいたします。
ご説明ありがとうございます。できました。
中間テーブルのレコードは、取り込みできたものは削除するようにしました。
過去1時間に更新された差分取り込みで30秒弱。
ストレスなくさくさく回っています。
テストしてみました。たしかに同期の検索は時間かかるときがありますのでこちらさくさくで良いですね。レイアウトにフィールドを配置しないとできない操作となくてもできる操作が覚えきれておらず、そのあたりにも軽量化する余地がありそうです。ありがとうございます。
#15の意味の確認ですが、
中間テーブルレイアウトで、
キーになるフィールド「*」を検索
対象外を表示
（=合致しないレコード）
リレーションキーを挿入して運用テーブルにレコード作成
できたら他の項目も転記
エラー（他ユーザーが使っている）なら飛ばす
ということでよいでしょうか。
レコード確定後、一度キーフィールドを選択しているのは、なにか大切な動きですか？
全レコードを中間テーブルで加工してからインポートしたら10分かかったのでさすがにあきらめて、データ作成日時を頼りに差分インポートする形に戻しました。それでもフィールドなどを整理して大分すっきりしましたし、教えていただいた関連レコードでの再取り込みも組み込んだので今後の動きが楽しみです。ありがとうございました。
ところで再取り込みもインポートで組んでしまったのですが、loopを使う#15は、中間テーブルのレイアウトに、
運用テーブル（リレーションによるレコード作成可）の必要フィールドを配置して、未同期のデータについてのレコードを作成していく、という理解で良いでしょうか。件数が少ないとこちらのほうこちらの方が速そうですね。
数式とフィールドの持ち方を変えたところ、3分かかっていた処理は90秒でできました。（ルックアップの時間は別にかかります）
あらためて考えて、#13でご提案頂いたように、各テーブルをそのまま置いてデータを足して行く方が無理なく扱えるように思いました。各フィールドについて、非保存で良いか索引が必要か見直してみようと思います。
ありがとうございました。
ご指摘ありがとうございます。計算フィールドが減らせますね。リレーションとルックアップも明日やってみます。
ところで、このフィールドは、テーブルBにあるべきなのでは。
索引が必要なのは、何故ですか。
たしかに、A-B-C-Dをセットで扱う分にはテーブルBにあるべきフィールドです。あえてCに転記しようとしているのは、テーブルCのデータの一部だけ別に保存して薬歴管理に使用したいからです。
具体的に申しますと、テーブルAが伝票、BがRp、Cが処方内容（薬品用法日数の行混在で処方１行１レコード）、Dが自由入力コメントです。はじめに上げたレコード数は半月分で、当日の前後規定日数分だけ取得し、日が経てば消していきます。
消える前に、Cの薬品のレコードだけに同じRpの用法行の内容や伝票番号を合体させて単独で扱えるようにして取っておき、薬歴として半年〜１年分程度見られるように使いたいのです。
と、書いていて気づきましたが、これ索引不要ですかね。保存用のCにはd1の転記も入れるので、検索が必要ならc1やd1転記（あるいは非保存でないc2）を使って、c3は表示するとき計算すればすむような気がしてきました……
ご教示ありがとうございます。薬品監査と薬歴管理です。
ルックアップや計算値などで必要なデータを１テーブルに保存した上で扱うのが最速ということですね。フィールドの関係と設定を見直してみます。
インポートの中間ファイルについては現行の差分取り込みでも作成しているのですが、取り込み後エラーチェックせずに消して次のデータを入れていました。関連レコードへ移動はほとんど使ったことがなかったですがこういうときに使えるのですね。
基幹→中間ファイル（加工・計算）→メインへインポート→古いのを消す→メインから中間ファイルの関連レコードへ移動→対象外を表示→メインへ追加インポート
こんな流れでしょうか。早速週明けに組んでみたいと思います。ありがとうございました。
医療系の処方情報の利用です。現在、差分のみ定期的に更新インポートしていますが、取り込み漏れが生じることがあり、いっそ全て取り込み直しでと考えた次第です。やはり早く動かすのは無理ですか。差分更新の精度見直しのほうが現実的でしょうか。
更新用に1端末使ってまして、インポートと加工が終わったら更新前のデータに不使用フラグを立てて差し替えとするので、他端末では稼働率が下がらない形です。
加工には基幹システムにない別テーブルのデータも当てているので、取り出し時の加工は難しいかもです。けどそちらも検討してみますね。ありがとうございます。差し支えなければ本題の方へのご意見もよろしくお願いいたします。
確かにそうでした。理想は1分なのですが、そんなにこまかくいらないし、データインポートに1分位かかるので、取り込み+諸々の加工処理を2分位で終わらせて3分休んでまた処理開始、の5分毎くらいでいいかなと考えています。なので1処理に3分かかるのはちょっと困ったな、というところでのご相談です。よろしくおねがいします。
いつも参考にさせて頂いております。
Filemaker Pro15
windows7,10（端末混在）
社内イントラネットで使用しています。
基幹システムからデータをインポートして、ユーザーが検索したり中身を確認して処理済みチェックをつけたりするような仕組みを作ろうとしています。
インポートするデータは以下のような構成です。
テーブルA―テーブルBーテーブルCーテーブルD
AーB（１：多）
BーC（１：多）
CーD（１：１ DのないCもある）
レコード数 A：8千件、B：3万件、C：8万件、D：2千件
A〜Dの元データは定期的に（1分毎とか）全入替です。
ユーザーはAから任意のレコードを検索して選択し、Cで詳細を確認して処理します。Dは備考テキストです。
ユーザーの検索が重くならないように、データ取り込み時に、Cの内容に基づく条件を全置換でAに転記したり、計算しないと出ない条件は「テキスト（計算値置き換え）」で書き出しておいたりしようとしています。またCでも検索する場合があり、非保存でない形で条件を保存しておこうとしています。
その中で１つ時間のかかってしまう処理があるので、なにかいい方法があるかお知恵をお借りしたく、投稿いたしました。
テーブルCにあるフィールドのテキストと、そのCに関連するDがあればそのDのテキストをリストにして書き出した計算フィールド（非保存）があります。
フィールドc1：テキスト例「自由入力コメント」
フィールドd1：テキスト例「4月5日から開始」
フィールドc2：以下の非保存計算
let([
_c1=テーブルC::フィールドc1
;_d1=テーブルD::フィールドd1
];
case(
_d1="";_c1
;_c1 & ¶ & _d1))
これの、テーブルBとのリレーションが同じものを1フィールドにまとめ、Cのすべてのレコードに書き込みたいのです。
レコードC1::フィールドc2
「自由入力コメント
4月5日から開始」
レコードC2::フィールドc2
「<<青色>>」
レコードC1C2がテーブルBの同じレコードの関連レコードである場合、両方のフィールドc3
「自由入力コメント
4月5日から開始
<<青色>>」
このフィールドc3を、索引のできるフィールドにしたく、list関数でテーブルBに書き出したものを全置換したり、テーブルCを自己リレーションしてlistを全置換で書き込んだり、計算値をcsvにエクスポートしたりしてみたのですが、結局8万件分list計算しているので3分ほどかかってしまいます。
なにか良い方法はないものでしょうか。
ご教示のほど、どうぞよろしくおねがいいたします。
Pages: 1
[ Generated in 0.008 seconds, 6 queries executed - Memory usage: 707.58 KiB (Peak: 744.74 KiB) ]