みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
こんばんは、FileMaker初心者です。
会社にて使用中のシステムを作り直すプロジェクトにかかわることになりました。
タイトルのように、統合をすることになりまして、困っております。
問題点は「昔のファイルメーカーで作ってあるため、たくさんのファイルに分かれてしまっている」
それを「一つに統合したい」です。
かなり昔に作られたといわれているシステムなのですが、拡張子は.fmp12です。
詳しく尋ねると、コンバートしたのであろうという事でした。
こちらの掲示板やGoogleで検索をし、「以前のバージョン（fmp7など）からfmp12へコンバートしてみる」というものがありましたが、fmp12からfmp12へのコンバートは言わずもがな出来ませんよね…？
一つ一つインポートし、新規テーブルを作っていくしか方法がないのでしょうか？
使用できるFilmaker:12 pro advance, 16
問題のファイル:.fmp12が連なっている。(下記フォルダ構造、■はフォルダです。フォルダ名等は仮称です)
■220124
└■Databases
├■RC_Cache_FMS
│└■34033E.....(空)
├■RC_Data_FMS
│├■マスタ(空)
│├■顧客(空)
│└■...その他98個のフォルダ(空)
├■Sample
├マスタ.fmp12
├顧客.fmp12
└...その他98個のfmp12ファイル
----------------------------------------------------------------------------※下記最終回答です。（一番下のコメントです。）----------------------------------------------------------------------------
今回の主題である
Q「FM6以前で作ったであろうコンバート済みのfmp12ファイルを統合するにはどうしたらいいか」についての答えは下記になります
A「fmp12→fmp12に再度コンバートはできない。立ち上がるだけ」
A「FM19の機能である、［名前をつけてアドオンパッケージとして保存］機能がファイルの統合に使えそう」
→使えるのがFM12,FM16のみなので現状は使えない。試してみることもできないため、不明
A「FM7以降のものであれば、全体のリレーション構造を把握する→全ファイルのリレーションマップを書き出し、1個のマップにまとめる。→そのマップを、メインのファイルの中に外部データソースを使って作り込む。→各ファイルのスクリプトを確認。（スクリプトを持っていないファイルは、そのままで別のファイルへインポートできる）→ファイルに、同じTO名でのリレーションを持たせておくと、パートを設定した空のレイアウトへ、オブジェクトのコピペで移動できる可能性があります。→スクリプトをインポートしていく。これも同じTOがあると簡単にいく可能性があります。」
→多分FM6以前に作られたフォルダだと思われるので、この方法は使えないと思われる。ただ、流れは同じように最初から再構築できるはず。
A「最初から作り直す」
→結局最適解はこれになりました。
解析から始まるのでとても長い時間がかかると思われますが、少しずつ頑張ります。
みなさん、本当にありがとうございました！:)
これからもまた質問させていただくことがあると思いますのでその際はぜひよろしくお願いいたします！
Last edited by Yup88 (2022-01-26 15:13:12)
Offline
fmp12からfmp12へのコンバート動作をするとただファイルが起動するだけですね。
このプロジェクトは大変大掛かりな作業になりそうですね。
様々なアプローチがあるにしてもテーブル単位でのインポート作業は免れないでしょう。
テーブルオカレンス、リレーションなどの再構築が大変です。
最初に致命的な問題点は、開発するためのFileMakerが最新ではない事ですね。
次にServerで運用しているみたいですが、Server環境がはっきりしていない事。
一つに統合と言っても、サーバーに複数ファイルをアップロードして使うものなのか、複数ファイルを単一のファイルにまとめて統合したいものなのか、色々と分かりません。
フォルダそのままに複数ファイルで運用するのかな…？そうだとしてもホスト出来るのは最大125ファイルまでなので注意が必要です。
統合モデルを採用するのか、分離モデルを採用するのか、そのあたりも判断が必要ですね。
以前作ったであろうファイルを参考にしながら作り直していくと思ったほうが良いかもしれません。
Offline
■RC_Cache_FMS
■RC_Data_FMS
の中身は、無視していいです。
もし、FM6 以前からコンバートされたものでしたら、リレーション関係やアクセス権を整理する手間が半端でないので、一から作り直すことをお勧めします。
FM7以降からのものでしたら、ファイル統合は、まず、全体のリレーション構造を把握する事です。全ファイルのリレーションマップを書き出し、1個のマップにまとめていきます。それが、新しいシステムの基礎の設計図になります。（これが、じつは経験者でも相当難しくて、やりなおしになる事も多いと思います。初心者を名乗られているのでしたら、かなり困難でしょう）このマップを、メインのファイルの中に外部データソースを使って作り込んでいきます。
次に、各ファイルのスクリプトを確認します。スクリプトを持っていないファイルは、そのままで別のファイルへインポートできますので、それをまとめていきます。
レイアウトをまとめていきます。ファイルに、同じTO名でのリレーションを持たせておくと、パートを設定した空のレイアウトへ、オブジェクトのコピペで移動できる可能性があります。
次にスクリプトをインポートしていきます。これも同じTOがあると簡単にいく可能性があります。
そこまでできれば、ほぼ完成です。
10年ほど前に私がもう少し大きい規模での同じ作業をしたさいには、準備に半年、運用するまでの移行作業に数週間、最終的な整理とブラッシュアップに数カ月かかっています。ただし、そのファイルの7割以上が自分で構築したものですから、その内容は完全に把握していたのでこの程度で作業できましたが、内容の把握から始めると、その倍以上の時間はかかるのでは。
Last edited by Shin (2022-01-25 20:50:08)
Offline
＞＞ウィン 様
コメントありがとうございます
fmp12→fmp12へのコンバートはやはりできないですよね…おっしゃられた通り起動してしまうだけなので、私もそう感じておりました。
かなり大変な作業になるかなと思っております。
情報不足、失礼いたしました。現在このフォルダ群を社内サーバー上に配置し、運用しているようです。今後Cloudに移行していきたいとの要望も出ています。
住所や駅のための社内コード検索システムや、銀行コード検索システムなど、このCRM以外でも共有して使える(かつ今後の変更もあまりない)ものに関しては別ファイルに。
それ以外の顧客管理については1つのファイルにまとめていきたいと考えております。(98個中90個ほどは1つのメインファイルに統合したい←メンテナンスのし易さと、起動時間や読み込み時間の短縮のため)
コンバートをできたら…と考えておりましたが、やはり非保存の計算フィールドを持つレコードもたくさんあるので、どちらにせよ構造を分解、分析して、再構築しなければいけないだろうなと思っております。
上記されている「分離型」とは、データベースを分離するという認識でお間違いないでしょうか？またその場合、DBを分けるメリットは何かあるのでしょうか？
インターフェースファイルとDBファイルを分離する作り方であれば、今後そちらも視野にいれた方が新機能開発からメンテナンスまでがスムーズかなとも思っているのですが…
Offline
＞＞Shin 様
コメントありがとうございます
■RC_Cache_FMS と ■RC_Data_FMS
の中身は、無視していいのですね、空ファイルなので何のために存在しているかわからず…。
隠しファイルを探したり色々しておりました。
FM6以前かFM7以降か…、これがまた把握できていないようなのです。(当時の開発者はもう退職しており、当時のバージョン等細かい引継ぎがされていなかったため)
何かで調べたりできるのでしょうか…？
只今分析を進めておりますが、スクリプトに細かくコメントを残しておくような方でもなかったので、どこかに判断できる要素があれば教えていただけると幸いです。
ただ、かなり前から使っているファイルらしいので、FM6以前だと想定して再構築を進めていく必要があるかなと感じております。
やはり最初から構築しなおす必要がありそうですね…
全ファイルのリレーションを書き出し、どういったフィールドがあるかなど解析していきたいと思います。
スクリプトも多岐に分かれてしまっているので、大変かと思いますが…頑張ります。
＞10年ほど前に私がもう少し大きい規模での同じ作業をしたさいには、準備に半年、運用するまでの移行作業に数週間、最終的な整理とブラッシュアップに数カ月かかっています。ただし、そのファイルの7割以上が自分で構築したものですから、その内容は完全に把握していたのでこの程度で作業できましたが、内容の把握から始めると、その倍以上の時間はかかるのでは。
準備から最終的なブラッシュアップまで約1年かかっているということですね…
内容の把握と、私が初心者ということで3年かかってしまうのではないかと恐怖を感じております。
ただ、挑戦する価値はあるのではないかと感じておりますので、まずは地道に解析から始めていきたいと思います。
Offline
ファイル数が大量にある点で、FM6以前からの変換ファイルだと思います。1つのファイルに複数のテーブルを入れられるようになったのはFM7からです。
ファイルの分割は、アクセス権セットを考えられるのがいいと思います。例えば、業務用のファイルでしたら、所属部署、役職によってアクセス範囲が変わりますね。別に、社内のクラブ活動用のファイルがあったとすると、全く別のアクセス範囲になります。このような区分にされると、アクセス管理が楽になります。
また、デベロッパプレビューですが、コマンドラインからバッチファイルで FileMaker のカスタム App をアップデートする "Claris FileMaker Custom App Upgrade Tool" がリリースされています。これを使うと、メンテナンスしやすくする という目的での分離モデルの利用は意味がなくなるでしょう。
Offline
ファイル数が大量にある点で、FM6以前からの変換ファイルだと思います。1つのファイルに複数のテーブルを入れられるようになったのはFM7からです。
「名前をつけてアドオンパッケージとして保存」機能がファイルの統合に使えそう、という話は、なくなったのかな？
このスクリプトステップは1年以上たってもプレビューのまま正式公開になりませんね...
https://support.claris.com/s/article/Fi … anguage=ja
あれ？さっき1回「refused」という見慣れないエラー画面になったので投稿失敗したのかと思ったら、投稿自体は完了してたようです。
＞＞himadanee 様
コメントありがとうございます
＞ファイル数が大量にある点で、FM6以前からの変換ファイルだと思います。1つのファイルに複数のテーブルを入れられるようになったのはFM7からです。
そうなのですね、となるとやはり大変そうですね…
＞「名前をつけてアドオンパッケージとして保存」機能がファイルの統合に使えそう
こんなものがあったのですね！ありがとうございます。
ただ社内で使用しているものが FM12 pro advance と FM16 しかないようでして…、FM19(FM17以降)の機能は使用できないですね…
ライセンスについて同僚に詳しく調べてもらっていますが、たぶんこのバージョンしか使えないだろうし、ライセンス数もギリギリかもしれないとのことです。
あとはFMServerを使用するライセンス形態だったり、Cloudだったりそういった形態に変更していければ問題は解決するかもしれませんが、会社の都合上すぐに変更のために動くことはできないと思われます…。
ただ、現在ファイルを使用している社員数分のライセンス数はあるようです。(今回携わっているシステムはFM16ベースで作れば良さそうです。)
たまにエラー画面が出てきたりすると驚きますよね。
「投稿失敗したかもしれないけどまあいいや」と思わず、再度投稿してくださってありがとうございます。
とても助かります！
Last edited by Yup88 (2022-01-26 11:40:17)
Offline
＞＞Shin 様
＞ファイルの分割は、アクセス権セットを考えられるのがいいと思います。例えば、業務用のファイルでしたら、所属部署、役職によってアクセス範囲が変わりますね。別に、社内のクラブ活動用のファイルがあったとすると、全く別のアクセス範囲になります。このような区分にされると、アクセス管理が楽になります。
外部の方に端末を貸出し、一部のレイアウトのみ入力してもらえるようにもしておきたいと思っていたので、アクセス権セットは割と細かく設定しておくつもりでおりました。
＞また、デベロッパプレビューですが、コマンドラインからバッチファイルで FileMaker のカスタム App をアップデートする "Claris FileMaker Custom App Upgrade Tool" がリリースされています。これを使うと、メンテナンスしやすくする という目的での分離モデルの利用は意味がなくなるでしょう。
そういった機能もあるのですね…
「メンテナンスしやすい、視認性がよく理解がしやすい」を目標に開発を始める予定です。
大雑把な質問で誠に申し訳ないのですが、Shin様は「自分以外の他の方が将来メンテナンスをするファイルを作る」となったときにどういったことを心掛けていらっしゃいますでしょうか？
また、先ほどのShin様のコメントをまとめると、現在分離型を作成するメリットはあまりないということでしょうか？
Offline
分離モデルについて否定しているのではなく、最初から分離モデルありき、という開発を行わなくてもいいのでは、という考えです、
分離モデルの初期によく言われていた、運用に合わせたファイルの変更、改良が容易なので、という状況が無くなっていくと思います。というのは、フィールド定義などは、どうしてもデータファイル側で行わなくてはならず、データ参照を行うさいには、データファイル側でリレーションマップを作っておく必要がある、という2点で、純粋にデータだけを持たせたデータファイルという完全な分離モデルを構築することは無理なのです。
それとは考え方の異なる、例えば、端末を貸し出して特定の業務を行わせる、という運用を考える場合などでは、必要なデータソースのみへのアクセスだけで済ませられ、本体も小さくなり、ひいては開発が早くなりますので、お勧めできると思います。
メンテナンス性については、様々なところで言われているように、コメントをつけておく、特に、引数や返数についてのコメントはきっちりしておくことでしょう。ただ、他社のメンテナンスを考慮するようなことは現時点では考えていませんので、全般的なドキュメントなどについては手を抜いています。
Offline
＞＞Shin様
沢山コメントを返していただき、誠にありがとうございます！
そうですね…色々調べていると、
「インターフェースとDBと両方ともの変更が必要になってしまって、きちんと管理ができなかったせいでごちゃごちゃになり、逆にメンテナンス性が悪化した」
というものも見つかりました。
もちろんそこをしっかりすればいいのかもしれませんが、今回はそこのハードルを上げすぎず、メインの機能は一つのファイルにまとめて頑張ってみたいと思います。
こういった分離型を作りたければ、そもそもFMではなくSQLとPHPなどで開発しなさいということでしょうね…
「端末を貸し出して特定の業務を行わせる」についても、多少重くてもアクセス権とオープンスクリプトで読み込み時間を軽減できないかやってみます。
現在はまだ試作品も作っていないので、それをする必要があるかすらわかりませんが…
非保存の計算フィールドがたくさんあったりで起動が遅い、画面推移が起こる際も動きが鈍い、といったことが起きているのでそこを解消できる構造を目指してみます。
＞コメントをつけておく、特に、引数や返数についてのコメントはきっちりしておくことでしょう
コメントをしっかり残す事やグローバル変数の定義の仕方など、ガイドラインをまずはざっくり決めてから作っていこうかと思います。
とりあえずは現在のファイルの解析と分析から始めてみたいと思います。。
コツコツ頑張ります！ありがとうございました！
Offline
今回の主題である
Q「FM6以前で作ったであろうコンバート済みのfmp12ファイルを統合するにはどうしたらいいか」についての答えは下記になります
A「fmp12→fmp12に再度コンバートはできない。立ち上がるだけ」
A「FM19の機能である、［名前をつけてアドオンパッケージとして保存］機能がファイルの統合に使えそう」
→使えるのがFM12,FM16のみなので現状は使えない。試してみることもできないため、不明
A「FM7以降のものであれば、全体のリレーション構造を把握する→全ファイルのリレーションマップを書き出し、1個のマップにまとめる。→そのマップを、メインのファイルの中に外部データソースを使って作り込む。→各ファイルのスクリプトを確認。（スクリプトを持っていないファイルは、そのままで別のファイルへインポートできる）→ファイルに、同じTO名でのリレーションを持たせておくと、パートを設定した空のレイアウトへ、オブジェクトのコピペで移動できる可能性があります。→スクリプトをインポートしていく。これも同じTOがあると簡単にいく可能性があります。」
→多分FM6以前に作られたフォルダだと思われるので、この方法は使えないと思われる。ただ、流れは同じように最初から再構築できるはず。
A「最初から作り直す」
→結局最適解はこれになりました。
解析から始まるのでとても長い時間がかかると思われますが、少しずつ頑張ります。
みなさん、本当にありがとうございました！:)
これからもまた質問させていただくことがあると思いますのでその際はぜひよろしくお願いいたします！
Offline
Pages: 1
[ Generated in 0.010 seconds, 9 queries executed - Memory usage: 624.3 KiB (Peak: 657.21 KiB) ]