ミラーシンクの使い方応用編

このドキュメントの最新バージョンは http://docs.360works.com/index.php/MirrorSync_advanced_topics （英語）でご覧いただけます。

ミラーシンクを使った同期で「やりたいこと」に合わせてカスタマイズするための文書です。また、さまざまな状況に対応するための詳しい解説を記載しています。このソフトウェアの基本的なことは、「ミラーシンクの使い方基本編」を先にお読みください。

展開に関する質問

ミラーシンクをアンインストールするにはどうすればいいですか？

OS Xはミラーシンクに付属の「Mac Uninstaller.pkg」を実行
Windowsは「C:￥Program Files￥360Works￥Uninstall」を実行

どちらのプラットフォームでも「360Works Admin.jar」アプリケーション（/Applications/360Works Admin.jarまたはC:￥Program Files￥360Works Admin.jar）を実行して、ミラーシンクのインスタンスを削除することができます。ただしこの場合、360worksのサービスは削除されません。360worksのサービスを完全に削除するには、アンインストーラを使用する必要があります。

目次へ

ホスティングプロバイダ向けインストール方法

原題： Installation for hosting providers

FileMakerの管理者でないアカウントを使う

原題：Using a FileMaker sub-admin account

残念ながら、ミラーシンクがダウンロードリンクのリクエストのサービスに使用しているfmsadminコマンドラインツールは、管理者でないアカウントでは動作しません。これについて、360WorksはバグとしてFileMaker社にレポートしています。当面については、この問題の解決策があります。360Works/Applications/conf/Catalina/localhost/MirrorSync.xmlファイルで、fmsAdminUsernameとfmsAdminPassword のプロパティをカスタマイズすることです。完全な管理者権限を持つユーザアカウントの情報をここに挿入すると、ミラーシンクはファイルのダウンロードやダウンロードのリンクの生成の際に、ユーザに情報の入力を求めることなくこの情報を使用します。この方法により、ミラーシンクのユーザはFileMaker Serverの完全な管理者な認証情報を入力することなく、ファイルをダウンロードできます。

目次へ

サーバを分けて展開する

原題：Split server deployments

FileMakerの展開が複数のマシンに分かれている場合、以下の3種類の構成のうちいずれかを使用することができます。

ミラーシンクを、Web公開エンジンではなくFileMaker Server上で実行する。
ミラーシンクを、Web公開エンジンで実行する。この方法を選択する場合は、FileMaker Serverにもミラーシンクをインストールすることを推奨します。これにより、ダウンロードのリンクを動作させることができます。FileMaker Serverで動作させるために追加でインストールするミラーシンクには、ライセンスキーを入力する必要はありません。
ミラーシンクを、Web公開エンジンやFileMaker Server以外のコンピュータ上で実行する。これは、ミラーシンクをLinux上で展開したい場合には良い方法です。この方法を選択する場合は、FileMaker Serverにもミラーシンクをインストールすることを推奨します。これにより、ダウンロードのリンクを動作させることができます。FileMaker Serverで動作させるために追加でインストールするミラーシンクには、ライセンスキーを入力する必要はありません。

インストールするコンピュータの種類に関わらず、ミラーシンクの構成をするときにはWeb公開とデータベースサーバが別のコンピュータ上になるように指定します。このオプションは、構成のプロセスの最初の画面に表示されます。

目次へ

Linux上にミラーシンクをインストールするには、どのようにしますか？

原題：How do I install MirrorSync on Linux?

ミラーシンクはLinux上で申し分なく動作します。ライブデモのファイルはこの方法で展開しています。FileMaker Serverと同期する場合は、FileMaker Serverが動作するMacまたはWindowsコンピュータが別途必要となることに注意してください。

Linuxに慣れていて、すでにJavaとTomcat（バージョン6.0.35以降またはバージョン7.0.50以降）がインストールされているものとして解説します。セットアップのプロセスは以下の通りです。

/var/lib/360worksのディレクトリを作ります。Tomcatユーザに対し、読み書きを許可します。
「MirrorSync.war」ファイルを、webappsのディレクトリにコピーします。
展開のために数秒間待ってから、${TOMCAT_HOME}/conf/Catalina/localhost/MirrorSync.xmlのファイルを変更します。
adminUsernameのプロパティと、adminPasswordまたは必要に応じてadminPasswordHashのいずれかを設定します。その他のプロパティをカスタマイズしたい場合には、このファイルを扱っている間に確認します。

ProxyPassディレクティブを使って、80番ポートのリクエストをTomcatにフォワードするようにApacheを構成することもできます。そのようにしない場合は、8080番ポートでミラーシンクにアクセスします。

推奨：Apacheの構成でタイムアウトが60秒に設定されていたら、コメントアウトするか秒数を増やします。扱うデータ量によりますが、ミラーシンクを実行するのに5〜20分かかるのはめずらしいことではありません。

目次へ

ミラーシンクは、FileMaker Proのランタイムバージョンで動作しますか？

原題：Does MirrorSync work with runtime versions of FileMaker Pro?

ミラーシンクは、この構成での使用をテストしておらず、サポートしていません。さらに、FileMakerのランタイムバージョンを作成する法的なライセンス契約では、ランタイムバージョンとFileMaker Serverの間でデータを自動で転送することが明確に禁止されています。この制限は、他社製のものであるか自作の自動化プロセスであるかにかかわらず、ランタイムエディションとFileMaker Serverの間でデータを転送するために合法的に使用できる同期のプロセスは一切ないということを意味しています。FileMaker Proのボリュームライセンスの価格については、ファイルメーカー社のビジネスアカウントマネージャーにお問い合わせください。

目次へ

FileMaker Serverの展開をやり直す必要がある場合にはどうすればいいですか？

原題：What if I need to redeploy FileMaker Server?

Macを使っている場合は、追加のステップは必要ありません。一方、Windowsを使っている場合は、FileMaker Serverの再展開後にミラーシンクのインストーラを再度実行します。

目次へ

ミラーシンク2からミラーシンク3へアップグレードするには

原題：I am running MirrorSync 2. What do I need to do to upgrade to 3?

記事「ミラーシンクのバージョンアップ」をご参照ください

目次へ

ネットワークに接続しないでインストールする

原題：Installing without a network connection

ミラーシンクのインストーラは、通常、インストールのプロセス中にネットワーク接続を必要とします。ネットワーク接続を利用してApacheのWebサイトからApache Tomcat 6をダウンロードし、ネットワーク経由でのライセンスのチェックによってライセンスキーが確認されます。外部へのネットワーク接続ができない環境の場合、ミラーシンクをインストールすることはできますが、以下の手順が追加で必要となります。

support@360works.com にメールで、ライセンスのチェックにネットワーク接続を必要としないミラーシンクのビルドを請求してください。
メールには、お持ちのライセンスキーと登録情報を必ず記載してください。（ライセンスキーをお持ちでない場合、無料版を取得してください）
リクエストメールの文例（Splash追記）

Dear 360works,
Could you provide custom-built installer for offline install?
----
360Works MirrorSync バージョン番号 / Server License License Key: ライセンスキー
Registered To: ライセンシー名
手動で/Library/360Works（Mac）またはC:￥Program Files￥360Works（Windows）に新規フォルダを作ります。
http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.55/bin/apache-tomcat-7.0.55.zip からApache Tomcat 7をダウンロードし、360worksのディレクトリに解凍します。これで、ネットワークにまったく接続していなくてもインストーラを実行できます。

サポートについて

ネットワークに接続しないインストールについては、現在日本語によるサポートはしていません。

エラーなどの際には、開発元と直接やりとりしていただく必要があります。

目次へ

あるサーバから別のサーバへミラーシンクを移行するにはどうしますか？

原題：How do I migrate MirrorSync from one server to another?

C:￥Program Files￥360Works￥SyncData2_MirrorSyncまたは/Library/360Works/SyncData2_MirrorSyncのフォルダを、新しいコンピュータにコピーします。
ファイルのアクセス権を、これまでに使っていたコンピュータと同じにしてください。
ミラーシンクを新しいコンピュータにインストールします。
ミラーシンクの管理ツールを実行します。
構成を編集して、サーバのIPアドレスを必要に応じて変更します。
スクリプトステップを「MirrorSync」スクリプトにコピー＆ペーストするプロセスの最後のステップで、まず外部データソースのリストから「MirrorSync_internal」と「MirrorSync_external」の項目を削除するのを忘れないようにしてください。これらの項目は、スクリプトステップをペーストするときに、新しい値で再作成されます。

目次へ

ネットワークに関する質問

原題：Networking questions

ミラーシンクで暗号化されたデータを送信することはできますか？　SSLを有効にしたFileMaker Serverではどうなりますか？

原題：Can MirrorSync send encrypted data? What about SSL enabled FMS?

送信できます。データを暗号化するために、ミラーシンクが動作しているWebサーバに有効なSSL証明書がインストールされている必要があります。これにより、プレーンテキストのデータが送信され、SSLで暗号化されたデータが受信されます。SSLを使ってオブジェクトデータを同期するには、まずFileMaker ServerでSSLを有効にします（このドキュメントの20ページを参照してください）。その後、またはすでにFileMaker ServerでSSLが有効になっていれば、ミラーシンクを構成するときにSSLのチェックボックスにチェックを付けます。

自己署名証明書を使用しているというエラーが表示された場合は、「Custom SSL Certificate setup instructions」の手順に従う必要があります。

目次へ

HIPAA への準拠（米国）

原題： I need my database to be HIPPA compliant, what should I do with MirrorSync?

ミラーシンクにはどのポートが必要ですか？　ポートは変更できますか？

原題：What ports are required for MirrorSync? Can I change them?

ミラーシンクの同期設定の作成時に必要なのは80番ポートのみです。とはいえ、全てのポートが空いていれば、より高速に接続することができます。

ミラーシンクサーバとデータベースサーバとの接続に必要なポートは、どのデータベースを使用しているかによって異なります。

FileMaker Server with XML: 80 and 443 (if using SSL)
FileMaker Server with JDBC: 2399
MySQL: 3306
MS SQL: 1433
Oracle: 1521

ミラーシンクと、FileMaker Pro / Go 上のオフラインデータベースとの接続では、オブジェクトフィールド以外のデータ（テキスト、数字、日付、時刻、タイムスタンプ）はすべて標準のHTTPの80番ポートまたは443番ポート（SSL暗号化を使用している場合）で転送します。

1）ミラーシンク2.1以降2）FileMaker Pro 13またはFileMaker Go 13を使用し、3）オブジェクトデータが10MB以下の場合、オブジェクトデータも標準のHTTPのポートで転送されます。この10MBの制限は、「MirrorSync」スクリプト中にある「$$base64Limit」グローバル変数の設定で調整できます。この設定に関する詳しい情報は、 support@360works.com にお問い合わせください。

前述の3つの条件を満たしている場合、ミラーシンクは標準の80番または443番ポートのみを使用します。これはほとんどのファイアウォールでデフォルトで許可されているポートです。

前述の3つの条件が満たされない場合、ミラーシンクはFileMaker Serverのゲストとして5003番ポートで接続します。これは、FileMaker ProとFileMaker Serverの間の通信に使用する通常のポートです。この場合、企業で設定しているファイアウォールがあると、おそらくカスタムの構成が必要になるでしょう。

目次へ

ミラーシンクはVPNで動作しますか？

原題：Will MirrorSync work on a VPN?

はい。ミラーシンクは、オブジェクト以外のデータは（VPNと互換の）標準のHTTPプロトコルで動作し、オブジェクトデータは（これもVPN互換の）標準のFileMakerのプロトコルで動作します。

目次へ

ミラーシンクはNAT（Network Address Translation）と互換性がありますか？

原題：Is MirrorSync compatible with Network Address Translation (NAT)?

はい。ミラーシンクを構成するときに、「内部/外部 IPアドレス」のオプションは「異なる」を選択します。これにより、ミラーシンクと同一のLAN上で動作していることが検知された場合には内部のIPアドレスを使用し、ミラーシンクのLANの外で動作している場合は自動で外部のIPアドレスに切り替えるように、同期のスクリプトが作成されます。

まれに、ミラーシンクの同期スクリプトにおいて、ミラーシンクサーバと同一のLAN上で動作しているかどうか判断できない場合があります。
例えば、ミラーシンクがIPアドレス192.168.1.5 で動作していて、ミラーシンクと同じネットワーク上で設定を行ったとします。そして、ユーザが別のネットワークから同じIPアドレスの範囲で同期を行おうとしました。(192.168.x.x や10.1.1.x が一般的なIPアドレスの範囲です)　この場合、ミラーシンクのスクリプトは、これらは同一のLANであると判断し、内部のIPアドレスを使用してしまい、同期が失敗してしまうでしょう。
このような場合には、60秒間試行を行い、その後自動的に外部のネットワークに切り替えます。もし、外部のネットワークで成功したら、そのファイルを閉じるまでは、これを記憶しています。このあとの同期処理では、まず外部ネットワークを先に試します。

もし、ユーザがすでに外部ネットワークから接続していることがあらかじめわかっている場合、（例えば、カスタムダイアログを使って、ユーザがLANの内部にいるかどうか、尋ねるなど）ミラーシンクを強制的に最初に外部ネットワークを試すように固定することができます。逆もしかりです。これを行ないたい場合は、ミラーシンクのスクリプトを実行する前に、グローバル変数　$$MIRRORSYNC_CONNECTION　の値を”internal” もしくは "external" に設定しておいてください。これで通常の探索ルールを上書きすることができます。

目次へ

プライマリキー／シリアル番号

原題：Primary key / serial numbers

「ミラーシンクが管理している」プライマリキーと「開発者が管理している」プライマリキーの違いは何ですか？　自分のプライマリキーの動作を変更する必要はありますか？　どちらを選ぶべきでしょうか？

原題：What is the difference between 'MirrorSync-managed' and 'Developer-managed' primary keys? Do I need to change how I do my primary keys? Which one should I pick?

この質問に答える前に、同期においてなぜプライマリキーが複雑な問題であるかを、まず説明する必要があります。従来型の増分のプライマリキーで、あるデータベースには1から10の番号が付けられたレコードがあり、別のデータベースには1から50のレコードがあるとします。前者のデータベースで新規レコードを作成すると、順番通りに次の番号（11）が割り当てられます。しかしこのレコードを後者のデータベースに書き込もうとすると、書き込み先にはすでに11のレコードが存在するのでコンフリクトしてしまいます。この問題を解決するには、いくつかの方法があります。

プライマリキーとしてUUID（Universally Unique Identifier）を使います。
これは通常、「D2EF9F69-5DEA-4FE3-9095-162C77F76FBF」のような36文字の長い文字列です。UUIDは、統計的に見て値が重複する可能性を排除できるランダムな値です。これは、データベースを同期するには理想的です。あるデータベースからあるデータベースへ、IDのコンフリクトを心配することなく安全にレコードを書き込めます。ミラーシンクは（そして他の同期のフレームワークのほとんどは）、UUIDをサポートしています。
従来型のシリアル番号と何らかの条件を組み合わせます。
何らかの条件とは、ユーザのイニシャルやファイルIDのようなものです。この方法では、ユーザ1のプライマリキーは「1.1」、「1.2」、「1.3」のようになります。ユーザ2のプライマリキーは「2.1」、「2.2」、「2.3」のようになります。この方法は、UUIDよりも短くて読みやすいという利点がありますが、各ユーザに固有の識別子を割り当てるための管理方法を検討する必要があります。ミラーシンクでは、後述の方法でこの問題を管理することができます。
2つめの解決策のバリエーションとして、各ユーザに特定の番号帯を割り当てる方法もあります。
ユーザ1は1〜10,000のプライマリキーを生成し、ユーザ2は10,001〜20,000のプライマリキーを生成するというような方法です。この方法の利点は（テキストではなく）純粋な数値を使えることですが、欠点はユーザのレコードが予定されていた数を超えた場合にコンフリクトするおそれがあるということです。ミラーシンクは、この方法も管理することができます。
まったく異なる方法で、それぞれのデータベースに存在するプライマリキーのコンフリクトを解決することもできます。
プライマリキーを他方のデータベースに書き込まない方法です。先ほどの例で言うと、11番のレコードを1つめのデータベースから2つめのデータベースに書き込むときに、11のプライマリキーを書き込むのではなく、51のプライマリキー（2つめのデータベースで、次の順番にあたる番号）を書き込みます。この方法には、できる限り短い、純粋な数値のプライマリキーにできるという利点があります。コンフリクトのおそれもありません。既存のデータベースの多くは、このように設計されています。ミラーシンクはこの方法をサポートしています（そしてミラーシンクは、私たちの知る限り、この方法をサポートしている唯一の同期のフレームワークです）。この方法では、内部テーブルを作成して同期しているすべてのデータベースのプライマリキーを調整します。そのため11番のレコードがあとから更新されると、ミラーシンクは2つめのデータベースの51番のレコードを変更することを認識します。ミラーシンクは、あるデータベースから別のデータベースに書き込むときに、外部キーも書き直します。そのため、1つめのデータベースで「11」を含む外部キーは、2つめのデータベースでは「51」に書き直されます。

1、2、3は「開発者が管理する」方法と考えられます。ミラーシンクは同期されるデータベース間でプライマリキーを変更せずに書き込むからです。何らかのスキームを採用して別のデータベースの別のレコードに同じプライマリキーがまったく使われないようにするのは、開発者の責任です。同じような考え方でさまざまなバリエーションがありますが（たとえば一方のデータベースは奇数、もう一方は偶数を使うなど）、ミラーシンクから見ればすべて同じことです。開発者が管理するキーには、「データ入力時の値変更の禁止」オプションを設定することはできません。ミラーシンクがこのフィールドに書き込む必要があるからです（レコードがもともと作成されたデバイスに一致させるためです）。

4つめは、「ミラーシンクが管理する」方法と考えられます。開発者は、異なるデータベース間でプライマリキーがユニークであることに責任を負いません。ミラーシンクが代わりに責任を持ちます。ミラーシンクが管理するキーには「データ入力時の値変更の禁止」のオプションを有効にできます。ミラーリンクはこのフィールドから読み出すだけで、書き込みはしないからです。

どの方法を選ぶのがよいのかについては、答えは常にこうです。FileMakerのデータベースで、現在、シンプルな自動で増分するシリアル番号のフィールドを1つだけプライマリキーとして使っているなら、ミラーシンクが管理する方法にするとよいでしょう。その他の場合は（UUID、派生キー、ユーザの入力に基づくキーなど）、開発者が管理するキーを使いましょう。ただし、送り状番号、業務番号、請求書番号など「ユーザフレンドリー」な番号を使う必要がある場合は、決定を下す前に、この後のFAQでユーザフレンドリーなシリアル番号に関する解説をお読みください。

プライマリキーには意味のあるデータを「使わない」ことを強く推奨します。これはミラーシンクに限らず、データモデリング全般に関して言えることです。つまり、プライマリキーは誰かの名前、イニシャル、社会保障番号、勤務地、企業名、ユーザ名などに基づくものにすべきではないということです。ただし、このようなスキーマを使わなくてはならない場合は、必ず「開発者が管理する」プライマリキーを選択してください。開発者が管理するキーを使うときは、複数のデバイス上の同一のテーブルには同じプライマリキーが決して作成されないように、あなたが責任を持たなくてはなりません。

これから新しいデータベースを作ろうとしていてどちらのアプローチでも選択できる場合の、それぞれの利点を以下に挙げます。

シリアル番号は比較的データが小さいため、バンド幅をとらず高速に同期できます。これに関する詳しい説明は、このドキュメントのパフォーマンスのセクションをお読みください。
UUIDは、ミラーシンクを使わずに手動で同期したりインポートしたりする場合や、（UUIDだけをサポートしている）他の同期ツールに乗り換える場合でも、簡単に使える方法です。

同期をする際の、プライマリキーに関するよくある誤りをいくつか挙げます。

自分のデータベースがプライマリキーとしてシリアル番号を使うように設計されている場合、単にUUIDのフィールドを新たに作り、それをプライマリキーとしてミラーシンクに認識させて楽をしようとは思わないでください。ミラーシンクは、外部キーの数字を振り直すことはしません。したがって、レコードをサーバと同期するときに、誤った子レコードが誤った親レコードをポイントしてしまいます。

プライマリキーとして計算値を使用している場合、たとえば複数のフィールドを組み合わせたり接頭辞を付加したりしている場合は、ミラーシンクの構成で「開発者が管理する」プライマリキーを選択してください。この場合、すべてのデバイスにわたってプライマリキーがユニークになるように、開発者が責任を持つことになります。シリアル番号のような単一のテキストフィールドまたは数字フィールドの場合は、「ミラーシンクが管理する」プライマリキーを使用します。

目次へ

ユーザーフレンドリーなシリアル番号をレコードに割り当て、同期しても変わらないようにする必要がある場合はどうしますか？　たとえば、送り状番号のようなものです。

原題：What if I need to assign a user-friendly serial number to my records that stays the same when it is synced? For example, an invoice number?

ミラーシンクが管理するシリアル番号の問題点は、送り状番号のようなユーザーから見える番号には適していないということです。プライマリキーがデバイスによって変わるからです。シリアル番号のプライマリキーを送り状番号として使用している場合に、ノートマシンとサーバとで送り状番号が違ってしまったら、明らかに困りますね！
この問題の解決策は、いくつかあります。まず確認すべきことのひとつは、データベースで1つのフィールドをプライマリキーとユーザから見える値（この例では送り状番号）の両方の用途で使っているかどうかです。どんな場合でも（同期しないとしても）、この2つの用途は別のフィールドにするのが望ましいことです。送り状番号／業務番号／ユーザから見える番号を、データベースのプライマリキーとして使用すべきではありません。プライマリキーはデータベース内部の識別子であり、ユーザから読める値の役割を兼ねることは避けるべきです。

別々のフィールドになっていれば、問題の解決は簡単です。リレーションシップを壊すことなく、送り状番号の値を柔軟に変更できるからです。推奨されるアプローチについては、後述の「値を書き戻す」のセクションを参照してください。

1つのフィールドをプライマリキーと送り状番号として使っていて、これを2つのフィールドに分けることができる場合は（1つはリレーションシップ用、もう1つは表示／検索用）、そのようにしてください。これはたいへんな大仕事になってしまうかもしれません。新規フィールドを作るのは簡単ですが、その後、元のフィールドがユーザインタフェースに使われているすべての場所を見つけて、新たに作った送り状番号フィールドにポイントしなくてはなりません。あるいは、元のフィールドがリレーションシップグラフ中で使われている箇所をすべて見つけて、新たに作ったプライマリキーのフィールドにポイントし直さなくてはなりません。これを避けたい場合は、推奨される方法として、後述の「MIRRORSYNC_CLIENTID」のセクションを参照してください。

目次へ

ユーザから見える数字の値を書き戻す

原題：Write-back values for user-visible numbers

UUIDをプライマリキーのフィールドとして使用していて、送り状番号フィールドもあると仮定します。書き戻す方法を使うと、オフラインのファイルでレコードを作成したときには送り状番号フィールドは空欄になります。送り状のレコードをサーバと同期するときに、次の送り状番号が割り当てられ、その番号がオフラインのファイルの送り状番号フィールドに書き戻されます。この方法は、送り状番号フィールドがプライマリキーとは別のフィールドである場合のみ動作します。

この方法の利点

送り状番号は、同期を意識させないような、シンプルで短い数字の並びです。

この方法の欠点

レコードをいったん同期するまで、オフラインのファイルには送り状番号がありません。

この方法を使用するには、以下の手順で設定します。

テーブルにシリアル番号のフィールドがなければ、作成します。プライマリキーとして使用されているシリアル番号がある場合、それを使うことができます。
ここでは、そのフィールドの名前を「serialNumber」とします。
テキストまたは数字の「invoiceNumber」（送り状番号）フィールドに、この自動入力の計算式を定義します：
```
If ( Get ( ファイル共有状態 ) = 2 ; serialNumber ; "" )
```
これにより、オフラインで作業をしているときには送り状番号が空欄になり、サーバに直接接続したとき自動入力されます。
ミラーシンクのプライマリキーを選択する画面で、「invoiceNumber」を書き戻しのフィールドとして選択します。このようにすると、ミラーシンクはレコードを初めて同期するときに、「invoiceNumber」をサーバからオフラインのファイルに書き戻します。

ミラーシンクが管理するか開発者が管理するか、どちらを選択してもこの設定には影響を及ぼしません。プライマリキーとしてシリアル番号を使っているかUUIDを使っているかに応じて、適切な方を選択します。

MIRRORSYNC_DATABASEIDをユーザから見える番号として使う

原題：MIRRORSYNC_DATABASEID for user-visible numbers

単一のシリアル番号をプライマリキーとして使っていて、これが送り状番号フィールドも兼ねているとします。「$MIRRORSYNC_CLIENTID」グローバル変数を使うと便利です。この方法を使うと、ミラーシンクは同期される各ファイルに、1から始まるユニークな連番を割り当てます。この番号を、それまで使っていたシリアル番号と組み合わせてユニークな番号を作り、ユーザから見える番号としてもプライマリキーとしても使うことができます。シリアル番号はテキスト（「1.1」、「1.2」、「1.3」……）または数字（ユーザ1は10001、ユーザ2は20001、ユーザ3は30001……）になります。

この方法の利点

妥当な短さの、ユーザから見える番号を使えます。
レコードを作成すると、IDが即座に割り当てられます。同期するまで待つ必要はありません。

この方法の欠点

オフラインのユーザは、レコードを作成する前にいったん同期しなくてはなりません。
スタートアップスクリプトを実行する必要があります。したがって、カスタムのWeb公開アプリケーションでは動作しません。
IDはシーケンシャルではないため、IDの数値が大きいからといって別のIDよりも先に作られたか後に作られたかはわかりません。
数字を使っている場合、コンフリクトが発生しないように、ユーザは作成するレコードの数を制限されます。
テキストを使っている場合、プライマリキーと外部フィールドのタイプをすべて「数字」から「テキスト」に変更する必要があります。
フィールドの書き戻しよりも、セットアップがやや複雑です。

この方法を使用するには、以下の手順で設定します。

「MirrorSync setup」スクリプトをスタートアップスクリプトに設定します。
すでにスタートアップスクリプトがある場合は、既存のスクリプトから「MirrorSync setup」スクリプトをコールします。
これにより「$$MIRRORSYNC_DATABASEID」グローバル変数がセットされます。
このクライアントIDのフィールドは「MirrorSync」テーブルに保管され、ユーザが初回の同期をしたときに割り当てられます。
同期されるデータベースにはそれぞれ、ユニークでシーケンシャルなクライアントIDが付与されます。この時点で手動でスクリプトを実行し、先へ進む前にグローバル変数をセットします。
「serialField」という名前のシリアルのフィールドがあり、リレーションシップグラフでこのフィールドがキーフィールドとして使われていると仮定します。まずこのフィールドを複製して「serialField コピー」という名前の新しいフィールドを作ります。「serialField コピー」をこのテーブルの同期のレイアウトには配置しないでください。
「serialField」を自動入力の計算値に変更します。「フィールドに既存の値が存在する場合は置き換えない」のチェックをはずします。「データ入力時の値変更の禁止」もチェックをはずします。以下のいずれかの計算式を設定します。

テキストのキーでは、この計算式を使用します。この計算式の結果は、デバイス1からは「1.1」「1.2」「1.3」、デバイス2からは「2.1」「2.2」「2.3」のようなプライマリキーになります。必要に応じて変更してかまいません。フィールドタイプを数字からテキストに必ず変更してください。このフィールドと関連する外部キーもすべて、テキストに変更します。

$$MIRRORSYNC_DATABASEID & "." & serialField コピー

数字のキーでは、この計算式を使用します。この計算式の結果は、デバイス1からは「10001」「10002」「10003」、デバイス2からは「20001」「20002」「20003」のようなプライマリキーになります。「10000」の部分は、数字の範囲を広げたり狭めたりするために任意の数字に置き換えてください。

$$MIRRORSYNC_DATABASEID * 10000 + serialField コピー

ミラーシンクの「主キーの照合」で、「デベロッパが管理」を選択し、「serialField」をプライマリキーとして設定します。

2つの外部キーをプライマリキーとして構成し使うにはどのようにすればいいですか？

原題：How do I configure and use two foreign keys as a primary key?

多対多のリレーションシップの結合テーブルでは、これが一般的な構成です。プライマリキーの構成の画面で、ドロップダウンメニューから2つの外部キーを選択します。

プライマリキーはユニークでなくてはならないということに気をつけてください。2つの外部キーを使用する場合、ノードIDの重複に関するエラーが発生するインスタントがあるかもしれません。FileMakerはフィールドをまとめて検証せず、テーブル内で常にユニークであることを確認しないからです。これを避けるには、以下のようにします。

2つの外部キーの組み合わせが、データベース中で１回だけ発生するようにします。
同じ外部キーで結合テーブルの複数のレコードを持つ必要がある場合は、外部キーの組み合わせではなく、通常のシリアル番号のフィールドを結合テーブルに追加し、プライマリキーとして使用します。
該当するフィールドのプルダウンメニューに表示させるために、2つの外部キーのフィールドには「空欄不可」の制限が有効になっていなくてはなりません。結合テーブルに空欄の可能性がある外部キーが必要な場合は、外部キーの組み合わせをミラーシンクの識別子として使用する代わりに、テーブルに従来型の単一のプライマリキーを追加する必要があります。

ミラーシンクが外部キーを知っていなくてはならないのはなぜですか？

原題：Why does MirrorSync need to know about foreign keys?

ミラーシンクは、外部キーを2つの目的で使用しています。ミラーシンクが管理するプライマリキーを使用する場合に、外部キーを知っていなくてはなりません。データベース間で書き込みをするときに再書き込みをする必要があるからです（前述のプライマリキーのセクションを参照してください）。

また、開発者が管理するプライマリキーを使用する場合でも、ミラーシンクにリレーションシップを認識させる必要があります。子テーブルよりも前に親テーブルを同期できるようにするためです。これにより、関係の完全性をチェックする確認規則が正しく動作します。

FileMaker 12以降を使用している場合、ミラーシンクは自動で外部キーを検知します。そのため、構成のプロセスでこのステップを実行することはありません。FileMaker 11を使っていて、かつ開発者が管理するプライマリキーを使っていて、かつ外部キーが有効な親レコードをポイントしているかどうかを確認するための関係の完全性のチェックをしていない場合には、このプロセスをスキップしても安全です。

構成に関する質問

原題：Configuration questions

ミラーシンクでは、同期するデータベースは同一でなくてはいけませんか？

原題：What type of sync configurations are supported by MirrorSync?

いいえ。まったく異なるテーブルやフィールドのデータベース間で同期できます。さらに、レコード、フィールド、テーブルのサブセットだけでも同期できます。たとえばモバイル専用のファイルとそれよりも大規模なサーバのデータベースというように異なるデータベースを同期する場合は、「別のモバイル用ファイルと同期★」（FileMaker Go向け）または「他のサーバのファイルと同期」（サーバー間同期向け）のオプションを選択します。このオプションを選択すると、シンプルなドラッグ＆ドロップのインターフェイスで、レイアウトとフィールド名を合わせていくことができます。

FileMaker Serverと同期するためにJDBCまたはXMLを使用する必要がありますか？

原題：Should I use JDBC or XML to sync with FileMaker Server?

Does MirrorSync support FileMaker Cloud?

Does MirrorSync need the databases being synced to be identical?

データベースを選択するボタンから、自分のデータベースが見えません。どうしてでしょうか？

原題：I'm not seeing my databases from the Choose database button. What's happening?

ミラーシンクで使用するアカウントで、XML公開が有効になっていることを確認してください。ミラーシンクをインストールしているマシンからデータベースにアクセスできるかどうかも確認します。

XML Web公開エンジンをテストするには、http://yourServer/fmi/xml/FMPXMLRESULT.xml?-dbnames のURLにアクセスしてみます。FileMaker Serverのデータベースが列挙されたXMLのドキュメントが表示されるはずです。表示されない場合、または404か401のエラーが表示される場合は、XML Web公開エンジンが正しく構成されていないおそれがあります。ファイルメーカー社の技術サポートに相談して、XML Web公開エンジンを動作させてください。

前述のテスト用のURLで認証が求められる場合は、IIS認証を無効にしてみてください。FileMaker Serverはパスワードで保護されたデータベースを認証します。ただしこの方法をとるとIIS認証のレイヤーが無効になります。サーバ上でIISを使用している他のWebサイトの認証も無効になります。

コントロールパネルで、「管理ツール」＞「インターネットインフォメーションサービス（IIS）マネージャ」を開きます。
IISでWebサイトを選択し、「操作」＞「プロパティ」を選びます。
「ディレクトリセキュリティ」パネルを開き、認証の「編集」を選択します。このボタンは、Windowsのバージョンにより異なります。
認証方法のポップアップメニューで、
- 「匿名認証」を有効にします。
- 認証されたアクセスで、認証方法を無効にします。
「OK」をクリックします。

FileMaker Pro Advancedを使わない構成

原題：Configuration without FileMaker Pro Advanced

FileMaker Proにはテーブルをコピー＆ペーストする機能がないため、以下の手順に従って「MirrorSync」テーブルを作る必要があります。

ミラーシンクのダウンロードに含まれている「XML schema」フォルダを見つけます。

FileMaker Proを開き、「ファイル」＞「レコードのインポート」＞「XMLデータソース」を選択します。
「XMLとXSLオプションの指定」ダイアログで、「ファイル」のラジオボタンを選択してから「指定」をクリックします。
ミラーシンクのダウンロードフォルダに移動し、「XML Schema」フォルダから「MirrorSync.xml」ファイルを選択します。
「続行」をクリックすると、「フィールドデータのインポート順」ダイアログが開きます。
「インポート先」ドロップダウンメニューで「新規テーブル（「MirrorSync」）」を選択します。
インポート元とインポート先のフィールドが正しく合っていることを確認します。
「インポート」をクリックします。

テーブルを作成した後、いくつかのフィールドを変更する必要があります。

「ファイル」＞「管理」＞「データベース」を開きます。
「フィールド」タブを開き、「id」フィールドを選択して「オプション」ボタンをクリックします。
「シリアル番号」にチェックを付けます。「作成時」に設定します。
「データ入力時の値変更の禁止」にチェックを付けます。
「入力時の制限」タブを開き、「空欄不可」と「ユニークな値」にチェックを付けます。そして「OK」をクリックします。「modstamp」フィールドを選択して「オプション」ボタンをクリックします。
「修正情報」にチェックを付け、ドロップダウンメニューが「タイムスタンプ（日付と時刻）」となっていることを確認します。
「データ入力時の値変更の禁止」にチェックを付けます。
「入力時の制限」タブを開き、「空欄不可」にチェックを付けます。そして「OK」をクリックします。
「lastErrorMessage」フィールドを選択して「オプション」ボタンをクリックします。
「データの格納」タブを開き、「グローバル格納」にチェックを付けます。そして「OK」をクリックします。
最後の2ステップを「webServerResponse」「_gSync1」「_gSync2」「_gSync3」「_gSync4」「_gLastInsertTable」「_gLastInsertResult」にも適用して、すべてグローバルフィールドにします。
最後に、「container」フィールドを選択し、「オプション」ボタンの隣にある「タイプ」ドロップダウンメニューから「オブジェクト」を選択します。

これで「MirrorSync」テーブルの手動での構成は完了です。「OK」をクリックして「データベースの管理」ダイアログを閉じ、ミラーシンクの構成に戻ります（変更を保存するのを忘れないでください！）。

分離モデル／複数ファイルのソリューション

ミラーシンクは、複数のファイルのソリューションでも問題なく動作します。ソリューションのうちの1つのファイルに、同期したいすべてのテーブルへの参照が設定されていることが必要です。ミラーシンクのダウンロード機能を使うときに、複数ファイルのオプションを選択して、オフラインのユーザがソリューションのファイルをすべてダウンロードできるようにしてください。

UIとデータのファイルを持つ分離モデルの場合、UIのファイルを使うようにミラーシンクを構成します。セットアップの完了後、「MirrorSync」テーブルをUIのファイルからデータのファイルへコピーし、リレーションシップグラフに「MirrorSync」テーブルオカレンスを更新します。その後、UIファイルからテーブルを削除します。このようにすると、スクリプトとレイアウトはすべてUIのファイルにあり、一方ミラーシンクの内部のメタデータはデータのファイルに保管されます。

外部SQLソース（ESS）はどのようにして構成しますか？

ミラーシンクはESSのテーブルをサポートしています。しかしミラーシンクを使って外部SQLデータベースからFileMaker Serverに単純にデータベースを同期するのと比べると、相当遅くなります。このため、同期する方法が何らかの理由で他にないという場合を除いては、ESSは推奨しません。ESSテーブルを使用したい場合には、以下のステップが追加で必要となります。

まず、同期のレイアウトと、プライマリキー、修正情報のタイムスタンプ、作成情報のタイムスタンプをセットアップします。

次に、ファイルの複製を作成し、FileMaker Serverでホストします。複製したファイルにのみ、以下の変更を加えます。ESSの参照を削除し、シャドウテーブルを通常のテーブルに変更してユーザがオフラインでデータにアクセスできるようにする必要があります。

まず、データソースを削除します。レコードの重複や、ESSを使うことによるその他の不適切な結果を避けるために、これは不可欠です。「ファイル」＞「管理」＞「外部データソース」を選択して、ODBCデータソースを削除します。

「ファイル」＞「管理」＞「データベース」を選択し、「テーブル」タブを開きます。ESSのテーブルをすべてコピーしてから、削除します。テーブルオカレンスは削除しないでください。イタリック体で書かれたテーブルがすべてなくなってから、テーブルをペーストして戻します。こうすることで、外部データの参照ではなく、ローカルのFileMakerのファイルになります。

プライマリキー、修正情報のタイムスタンプ、作成情報のタイムスタンプが適切であることを確認します。プライマリキーは、自動入力のシリアル番号、または生成されるUUIDでなくてはなりません。

「ファイル」＞「管理」＞「データベース」の「リレーションシップ」タブを開き、失われたテーブルをリンクし直します。

これでミラーシンクを構成する準備が整いました！　構成のプロセスを開始し、3番目の画面で「別のモバイル用ファイルと同期★」を選択します。複製して変更したファイルを選択し、通常のファイルと同じように構成を続けます。

FileMaker 11でファイルを構成し、何も問題なく動作していました。FileMaker 12に変換したらまったく同期しなくなってしまいました。どうしてでしょうか？

ファイルを変換した後で、構成を変更して「MirrorSync」のスクリプトステップをFileMaker 12のファイル用に生成されたものに置き換える必要があります。これは、FileMaker Pro 11には「URLから挿入」スクリプトステップが存在しないという事情によるものです。

1つのデータベースを、サーバー間同期でも、同時にサーバ - クライアント間でも同期することはできますか？

これはご要望の多い使い方です。同期したいサーバが2か所にあり、それぞれの街にiPadやノートマシンを使っているユーザがいてオフラインで作業をしなくてはならないとします。現時点では、ミラーシンクは1つのデータベースファイルに対して複数の同期を構成することはサポートしていません。しかし、対応策はあります。サーバー間で同期するためにメインファイル中のテーブルにリンクしている外部テーブルオカレンスを持つ別の「シェル」データベースを作り、その別データベースをサーバー間同期に使用する方法です。たとえば、「プロジェクト」という名前のデータベースを同期したいとします。以下のステップで設定します。

「プロジェクト」データベースを、通常のサーバ - クライアント間で同期するようにセットアップします。

サーバ - クライアント間の同期が動作するようになったら、新規データベースを1つ作ります。新規データベースの名前は何でもかまいません。ここでは例として「プロジェクト同期」とします。

「プロジェクト同期」データベースのリレーションシップグラフに、同期するテーブルにそれぞれ対応した外部テーブルオカレンスを追加します「プロジェクト」ファイルから「MirrorSync」テーブルを追加しないでください。「プロジェクト同期」ファイルには、このテーブルの別のコピーが必要です。

リレーションシップグラフを構成します。外部 - プライマリキーのリレーションシップを構成するだけです。ユーザインターフェイスにのみ使用されるグローバル／計算のリレーションシップはすべてスキップしてかまいません。厳密に言うと、これは必須のステップではありません。しかしこうすることにより、ミラーシンクはリレーションシップを自動で検知します。これは、シェルファイルで関連テーブルを参照しているルックアップや計算を正しく動作させることのできる良い方法です。

ミラーシンクで「プロジェクト同期」ファイルの新しい構成をセットアップします。これが完了したら、ミラーシンクの管理ツールを使って「プロジェクト同期」ファイルでサーバー間同期が正しく実行されるはずです。

同期の問題が発生したときに通知を受けることはできますか？

はい、できます。これに関する設定は2種類あります。

ひとつは、ミラーシンクのセットアッププロセスで構成する管理者のメールアドレスです。ここでメールアドレスを入力し、プルダウンメニューから重大性を指定すると、該当するイベントが発生したときにメールメッセージを受信することができます。同期が実行されるたびに受信する、警告が発生したときだけ受信する、重大なエラーが発生したときだけ受信する、のいずれかを選択できます。また、影響のあるプライマリキーに関する詳しい情報を受信するかどうかも指定できます。

もうひとつの設定は、「MirrorSync.xml」ファイルの中にあります。このファイルをテキストエディタで変更して、「supportEmailAddress」フィールドを設定できますこのフィールドをセットすると、ユーザが報告したバグがこのメールアドレスにCCで送信されます。360Worksからのテクニカルサポートの回答は、ユーザではなくこのメールアドレスに送信されます。これにより、ユーザは自分が遭遇した問題点を報告し、あなた（開発者）は必要に応じて調整をすることができます。構成ファイルは以下の場所にあります。

Mac: /Library/360Works/Applications/conf/Catalina/localhost/MirrorSync.xml
Win: C:\Program Files\360Works\Applications\conf\Catalina\localhost\MirrorSync.xml

同期に関する質問

ミラーシンクは異なる時間帯で動作しますか？

Yesでもあり、Noでもあります。

オフラインのユーザが同期するなら、Yesです。ミラーシンクはすべての変更箇所のリストを取得し、自動でオフラインのユーザの時間帯を検知して、それに応じて時刻を調整します。

サーバー間同期でも、Yesです。ミラーシンクは、FileMaker Serverの現在の時刻を検知してそれに応じて調整します。オフラインのユーザの場合と同様です。

FileMaker Serverに直接接続している、同期しないユーザの場合は、Noです。自動では対応しません。このケースで動作させるには、対応が必要です。少し複雑なので、例を示して解説しましょう。FileMaker Serverがニューヨークでホストされているとします。ニューヨークにいるユーザが、東部標準時の午後12:30に同期を実行します。30分後の、東部標準時では午後1時、太平洋標準時の午前10時に、サンフランシスコにいるユーザがサーバ上のレコードを変更します。FileMaker Serverの動作からすると、ニューヨークにあるサーバ上の修正情報のタイムスタンプは午前10時になります。東部標準時には変換されません。また、FileMaker Serverはユーザの時間帯の情報を保存しないので、それが太平洋標準時なのかどうかはわかりません。基本的には、不正確な値になってしまいます。次回の同期を実行するときに、ミラーシンクは最後の同期である午後12:30以降に変更されたレコードをリクエストします。するとサンフランシスコのユーザが加えた変更は、最後の同期よりも後のものであるにもかかわらず抜けてしまいます。

この問題を解決するのは、とても簡単です。この説明を読むよりも短い時間で解決できてしまいます！

テーブルに、「Modification timestamp」という名前の、通常の修正情報のタイプスタンプがあるとします。

「Host modification timestamp」（あるいは任意の名前）の新規フィールドを作り、以下の計算値が自動入力されるように設定します（「Modification timestamp」の部分は自分のファイルのフィールド名に置き換えてください）。

Let ( x = Modification timestamp ; Get ( ホストのタイムスタンプ ) )

「フィールドに既存の値が存在する場合は置き換えない」のチェックを、必ずはずします。

このフィールドを同期のレイアウトに追加し、通常の修正情報のタイムスタンプは同期のレイアウトから削除するのを忘れないようにしてください！

通常の修正情報のタイムスタンプの代わりに、このフィールドをミラーシンクの構成のプロセスで修正情報のタイムスタンプとして使用します。

これは、修正情報のタイムスタンプとしてユーザの時刻ではなくFileMaker Serverの時刻を使用して動作します。このようにすると、サンフランシスコのユーザが太平洋標準時の午前10時にレコードを変更すれば、FileMaker Serverは「Host modification timestamp」フィールドに午後1時（変更されたときのサーバの現地時間）と保存します。これで、ミラーシンクは異なる時間帯で正常に動作します。

同期した後で自分のデータベースを他のコンピュータに転送できないのはなぜですか？

ミラーシンクのサーバには、同期している各デバイスの情報が保管されています。これには、プライマリキーと、そのデバイス上でそのレコードが変更されたカウントが含まれます。このファイルが2つの異なるデバイスから同期されると、この情報がコンフリクトして問題が発生します。別のデバイスにデータベースを送信して同期しようとすると、エラーメッセージが表示され同期は実行されません。

1台のデバイスを複数のユーザで共有することはできますか？

できます。ただし……

そのデバイスを使うユーザ全員が同じユーザ名でログインするなら、おそらく問題はないでしょう。オフラインのデバイスでレコードレベルのアクセス権を使用していなければ、異なるレコードへのアクセスは複数のユーザに許可されます。

1台のデバイスを共有する各ユーザが異なるユーザ名でログインする場合の解決策は、ユーザごとに1つずつ、ファイルのコピーをデバイスに入れることです。各ユーザは自分に割り当てられたファイルにのみログインできることに注意してください。

ミラーシンクは、異なるユーザ名を持つ複数のユーザが同一のオフラインファイルを共有することを禁止しています。レコードレベルのアクセス権またはスクリプトのフィルタがユーザごとに異なる場合、同期のプロセスが正常に動作せずにサーバ上の誤ったレコードを削除してしまうおそれがあり、これはきわめて危険であるためです。

ミラーシンクは、オブジェクトフィールドを同期しますか？

はい、ミラーシンクはFileMakerのオブジェクトフィールドに対して動作します。オブジェクトフィールドは、他のタイプのフィールドよりも同期に時間がかかります。そのため、同期する必要がなければオブジェクトフィールドを同期のレイアウトから削除してください。

ミラーシンクは、通常の（外部ではない）オブジェクトフィールドに加え、外部保存のオブジェクトフィールド（セキュア格納とオープン格納の両方）をサポートしています。参照されたオブジェクトフィールド（ファイルを挿入するときにユーザが「ファイルの参照データのみ保存」にチェックを付けたフィールド）はサポートしていません。

スーパーコンテナーはミラーシンクで使えますか？

はい、使えます。ただし、スーパーコンテナーの場合は、アプローチがまったく異なります。実ファイルではなくURLのみが同期します。実ファイルはスーパーコンテナーのサーバにそのまま置かれます。この場合の利点は、同期がきわめて高速であることです。バイナリのデータが一切転送されないからです。欠点は、コンピュータまたはiOSデバイスからネットワークにアクセスできるときしか、スーパーコンテナーに保存されているファイルにアクセスできないことです。

ミラーシンクは、外部保存のオブジェクトフィールドを同期しますか？

はい、ミラーシンクは外部保存のオブジェクトフィールドでも動作します。FileMaker ProまたはFileMaker Serverと同期するための、追加のステップは必要ありません。iOSデバイスで外部保存のオブジェクトフィールドを使っていて、かつ（空のクローンではなく）データベース全体を同期する場合、構成した後でいくつかのステップが必要です。

    ミラーシンクまたはFileMaker Adminからデータベースをダウンロードします。

    コンピュータ上でダウンロードしたファイルを開き、「ファイル」＞「名前を付けて保存」を選択します。

    「タイプ」ドロップダウンメニューで「すべてを含むコピー（単一ファイル）」を選択します。

これで、ファイルにオブジェクトが埋め込まれ、FileMaker Goやオフラインで簡単に使えるようになります。

注意してください：このプロセス中に実行されるFileMakerの挙動には、都合の悪い点があります。すべてを含むコピーを保存するときに、FileMakerは外部に保存されているオブジェクトフィールドを持つ全レコードの修正情報のタイムスタンプを更新するということです。これは通常は問題になりませんが、ミラーシンクを使うときには初回の同期に相当な時間がかかります。時間がかかる理由は、これらのレコードがすべてクライアント上で変更されたとミラーシンクが認識し、（オブジェクトデータも含めて）サーバのデータをすべてクライアントに書き込むからです。

この問題の回避策は、すべてを含むコピーを保存する前に修正情報のタイムスタンプの自動入力を解除し、コピーを保存した後に再度有効にするということです。修正情報のタイムスタンプのこの挙動は、FileMaker社にすでに報告済みです。近いうちに解決されることを願っています。

iOS 7でダウンロードのリンクをタップしたときにプログレスバーが表示されないのはどうしてでしょうか？

ユーザと共有するためのダウンロードのリンクを作成した場合、通常、ユーザがリンクをタップすると状況がわかるようにダウンロードのウインドウが表示されます。iOS 6では、ファイルのダウンロードが完了するまでの間、タブに小さいプログレスバーが表示されていました。残念ながらiOS 7ではダウンロードの進行状況を示すインジケータがなくなったため、ダウンロードのリンクをタップしても何も実行されていないかのように見えます。これは良くないと思うのであれば、Appleに直接 フィードバックを送る ことを推奨します。とはいえ、ミラーシンクは見えないところでいくつかの処理を実行しています。リンクがタップされると、「データなしのコピー」を選択した場合でも、FileMaker Serverでホストされているファイルのコピーを保存し、すべてのデータのバックアップを作成します。それからファイルをデバイスにダウンロードします。ファイルのサイズによっては、バックアップを作成してコピーを保存するのに時間がかかることがあります。ミラーシンクは、所要時間をログに記録しています。

 ミラーシンクでは、同期するユーザに完全アクセスのアカウントが必要ですか？

いいえ。ミラーシンクが完全アクセスのアカウントを必要とするのは、テーブル、スクリプト、レイアウトをペーストするときの1回だけです。ユーザが同期を実行するときは、ユーザ自身のアカウントのアクセス権を使用します。どのようなアクセス権になっているかは問いません。ユーザアカウントの制限に関するヒントは、後述する「ミラーシンクをカスタマイズする」のセクションを参照してください。

フィールドレベルのアクセスを設定している場合、たとえばあるフィールドを「表示のみ」または「アクセスなし」にしていると、同期中に問題が発生します。オフラインのデバイスで実行される「MirrorSync」スクリプトは、オフラインのファイル上の「表示のみ」のフィールドに書き込むことはできません。オフラインのユーザと同じアクセス権で実行されるからです。この問題を解決するには、「MirrorSync」スクリプトの「スクリプトを完全アクセス権で実行」にチェックを付けます。これを、サーバのファイルにもオフラインのコピーにも設定します。これによりミラーシンクは、ユーザ自身は表示や書き込みが制限されているフィールドにも、読み書きができるようになります。このようにする場合、レコードレベルのアクセス権を使って、オフラインのコピーのどのレコードを同期するかを制限することはできません。代わりに、「MirrorSync customization」スクリプトを使ってください。

ミラーシンクは、コンフリクトを解決する動作をしますか？

はい、ミラーシンクには強力なコンフリクト検知機能と、フィールドレベルのマージ機能があります。この機能により、同一のレコードに対して両方のデータベースが変更されたことを検知し、対応します。この動作を制御するクライアントの構成には、2つの設定があります。

変更をまとめてマージする

データベースに対する変更がすべて別のフィールドに関するものであることをミラーシンクが確認すると（たとえばサーバでは名、クライアントでは姓が変更されているとすると）、自動でその変更をマージします。コンフリクトが発生したことは、ユーザには知らせません。マージしたレコードをサーバとクライアントの両方に書き込むだけです。同一のフィールドに対して変更が加えられていると、これはコンフリクトであると判断し、マージはしません。

コンフリクトとしてフラグを立てる

同一のレコードに対する変更をすべてコンフリクトとして扱います。同一のフィールドの変更か異なるフィールドの変更かは問いません。

コンフリクトが発生すると、以下の構成のオプションに基づいてミラーシンクはコンフリクトを解決します。

ユーザが選択する

ミラーシンクはユーザに対してWebベースのインターフェイスを表示し、コンフリクト全体の概要と、両方のデータベースのどのフィールドが変更されたかを提示します。変更された部分のテキストには色が付けられ、経験の浅いユーザにも簡単に最適な選択ができるようになっています。ユーザは、レコード全体を選択したり、レコードごとに個々のフィールドを選択したりすることができます。さらに両方のレコードの変更を組み合わせて手動で編集することもできます。自動で最も新しい変更を選択するように設定することもできます（次のオプションを参照してください）。

最も新しい変更を使用する

最後に変更されたレコードを選択してコンフリクトを解決します。ジョーがiPadで午後3:00にあるレコードを変更し、ケイトはその同じレコードをiPhoneで午後3:30に変更し、トムはサーバ上でそのレコードを午後4:00に変更したとすると、ジョーやケイトがデータベースを同期するときには、同期をいつ実行するかにかかわらず、トムのレコードが使用されます。

常にHubのデータを使用する

Hub（通常はFileMaker Server）上にある値を常に使用してコンフリクトを解決します。その他の状況は考慮されません。これは一般的には推奨されません。基本的に、最初の同期が優先されるからです。同一のレコードを変更して同期する他のオフラインユーザに対し、最初にHubに同期した人のデータが優先されます。この設定は、直接接続しているユーザの変更が、オフラインで同期するユーザの変更より優先順位が高い場合に便利です。

管理者にメールで通知する

「ユーザが選択する」とよく似ていますが、同期を実行するユーザが決めるのではなく、構成時に指定した管理者のメールアドレスにメールが送信されます。管理者は、上述のWebベースのユーザインターフェイスを使ってコンフリクトを解決することができます。その後、ユーザは通常の同期をすることができます。

ミラーシンクはトランザクション処理をしていますか？　同期中に接続が失われたらどうなりますか？

ミラーシンクは、厳密には「トランザクション処理」はしていません。同期中に接続が失われると、あるテーブルのレコードはサーバに書き込まれるかもしれませんが、別の関連テーブルのレコードは書き込まれないかもしれません。ただしミラーシンクはどのレコードが書き込まれたか、どのレコードがまだ書き込まれていないかを管理しています。そして次回の同期のときにそこから再開し、前回の同期が完全に終了したのと同じ状態にします。サーバ上のレコードが（編集中であるために）ロックされていて書き込めない場合、オフラインのユーザにはそのことを伝える警告のメッセージが表示されます。ミラーシンクは、同期のスクリプトを実行するたびに、その編集を処理する再試行を続けます。

ミラーシンクで、外部認証を使うことはできますか？

はい、ミラーシンクは外部認証のアカウントをサポートしており、変更の必要はありません。ローカルのコピーのユーザ名とサーバ上のユーザ名が同じであれば、ローカルのアクセスとサーバの外部認証に同じパスワードをセットアップできます。パスワードは、ローカルのファイルとホストされたファイルで同じにする必要はありません。

ミラーシンクは、FileMakerの入力値の制限の設定を使用しますか？

制限が「常時」に設定されていれば、使用します（これに対し、デフォルトは「データの入力時のみ」です）。「データの入力時にユーザによる上書きを許可する」は、ミラーシンクが制限を使用するかどうかには影響がありません。プライマリキーとしてUUIDを使用している場合は、「常時」を選択するとともに「ユニークな値」の制限を設定することを推奨します。これにより、ミラーシンクの構成が誤っている場合に発生するおそれのあるレコードの重複を防ぎます。

サーバー間同期

サーバー間同期のセットアップは、どのようにしますか？

サーバー間の同期でも、セットアップのプロセスの大半はサーバ - クライアント間の同期と同じです。ひとつだけ、知っておくべき相違点があります。

Spokeの構成で、「空のクローンファイル、あるいはHubのメインファイルと同期」か「他のサーバのファイルと同期」を選択します。「空のクローンファイル、あるいはHubのメインファイルと同期」を選択すると、実際にはセットアップのプロセス中にファイルを別のサーバへ送信しません。セットアップのプロセスを進め、完了したときに、ミラーシンクのダウンロード機能を使ってHubとなるサーバからコピーまたはクローンが保存され、Spokeのサーバにアップロードされます。「他のサーバのファイルと同期」を選択すると、構成中にファイルをSpokeのサーバにアップロードして使用する必要があります。

サーバー間同期はどのように実行しますか？

クライアント - サーバ間の同期のようにFileMakerから「MirrorSync」スクリプトを使用することはありません。代わりに、ミラーシンクの管理ツールにある「同期」ボタンを使用します。同期を実行し問題なく動作が完了したら、「自動同期」にチェックを付け、同期を実行する間隔を指定して、自動同期を有効にすることができます。

サーバー間同期中に問題が発生した場合、どのようにしてその問題を知ることができますか？

ミラーシンクの構成中に、管理者のメールアドレスを設定することができます。設定すると、同期が失敗したときにメールで通知を受けられます（あるいは、設定によっては成功したときにも通知を受けられます）。通知のメールは、アマゾンウェブサービスから送信されます。そのためSMTPサーバを自分で構成する必要はありません。

パフォーマンスに関する質問

サーバー間同期のパフォーマンスは、どのような感じですか？

実際に動作しているサンプルは、360Worksのオンラインストアのデータベースです。バージニアにあるデータセンターに置かれているライブのMySQLデータベースから、ジョージア州アトランタにある弊社オフィスのFileMaker Server 12に一方向で同期するように、ミラーシンクをセットアップしています。このデータベースには、20のテーブルにわたって、320,707件のレコードがあります。

初回の同期では、MySQLのデータをFileMakerの空のデータベースにすべて同期するので、約2時間（7,180秒）かかりました。1秒あたり平均45レコードです。

差分の同期は5分おきに実行し、約18秒かかっています。

ネットワークが低速な場合のミラーシンクの動作はどうなるでしょうか？

ミラーシンクは低速のネットワークでもきわめて効率よく動作します。送信されるデータは実際のレコードの変更よりもずっと少なく、しかも効率のよい大きいチャンクで転送されるからです。同期を始めるときにはHTTPリクエストを2つ使用し、終了するときには1つ使用します。通常は、変更を含むテーブル1つにつき、1つのHTTPリクエストを使用します。たとえば、ソリューションにテーブルが20個あり、そのうちの5つのテーブルに変更が加えられたとすると、通常、同期を完了させるために使用されるHTTPリクエストは8（2＋5＋1）です。比較のために例を挙げると、FileMaker社のホームページをWebブラウザに読み込むには、65のHTTPリクエストを使用しています。

同期のスピードを上げるにはどうすればいいですか？

特に調整をしなくてもミラーシンクはかなり高速ですが、速いに越したことはありません。ミラーシンクからの同期のスピードをできるだけ上げるためのヒントをいくつか紹介します。

SSDドライブ

ミラーシンクは、多くのレコードの同期を一括処理するときには細かい読み書きのオペレーションを大量に処理しています。このような使い方の場合、レイテンシーがきわめて低いSSDドライブは大いにメリットがあります。SSDドライブにミラーシンクをインストールすると、同期が目に見えて速くなるでしょう。ハードディスク全体の代わりにSSDを使用する必要はありません。OS Xのシンボリックリンクを使ったりWindowsでインストール場所を変更したりすれば、ミラーシンクだけをSSDに置くことができます。SSDのパフォーマンスの高さにより同期の処理全般が速くなりますが、変更がごくわずか、またはまったくないような少しだけの同期を実行するときや、何十万件ものレコードがあるような大規模のデータベースの初回の同期のときには、特にめざましい効果が現れます。

ミラーシンクは変更されたレコードをFileMaker Serverから取得するときに、前回の同期の10分前以降の変更をすべてリクエストします。この10分間の重複は、時計が遅れているユーザに対しては補正されます。前述の時間帯のセクションで紹介した「Host modification timestamp」の方法を使っている場合は、ユーザの時刻は問題にはならず、この10分間の重複は必要ありません。「MirrorSync.xml」ファイルを編集して「fmServerOverlapSeconds」のパラメータを「600」（10分間）から「5」（5秒間）の間で変更することができます。このファイルは以下の場所にあります。

Mac: /Library/360Works/Applications/conf/Catalina/localhost/MirrorSync.xml
Win: C:\Program Files\360Works\Applications\conf\Catalina\localhost\MirrorSync.xml

小さいテーブルに多くのレコードセットがある場合には特に、UUIDではなくシリアル番号を使います。5文字のシリアル番号と36文字のUUIDでは差が出ます。結合テーブルのように、ほとんどが外部キーで構成されている多数のレコードを転送するときには、特にそうです。UUIDを使う妥当な理由がある場合には、この変更はしないでください。

オブジェクトフィールドはデータ量が多く、オブジェクト以外のデータが一括処理されるのとは違って、個々に送信されます。同期する必要のないオブジェクトがある場合は、同期のレイアウトから削除します。

オブジェクトフィールドは、オブジェクトは変更されていないとしても、そのレコード上のいずれかのフィールドが変更されると転送されます。必要のないオブジェクトが同期されることを避けるために、オブジェクトフィールドをそれ自体のテーブルに移動します。こうすることで、オブジェクトが変更されたときのみ転送されます。

データベース全体ではなくレコードのサブセットだけを同期したい場合は、レコードレベルのアクセス権やスクリプト化されたフィルタを使うことができます（詳しくは後述のカスタマイズのセクションを参照してください）。スクリプト化されたフィルタを使うと、レコードレベルのアクセス権の制限に比べて、大幅に高速になります。

FileMaker Server 10または11を使用している場合は、12以降に変更します。ミラーシンクとFileMaker Serverの通信はすべて、XML Web公開エンジンを経由しています。これは、FileMaker Server 11ではあまり速くありません。FileMaker Serverの最新バージョンでは、この通信が大幅に向上しています。

XML Web公開エンジンに関しては、構成によってFileMaker Server 13と同期するときにかなりのスローダウンを引き起こすことがあります（FileMaker Server 10、11、12では発生しません）。これによりXMLリクエストごとに1秒長くなるので、通常は約20ミリ秒のリクエストが、1,100〜1,200ミリ秒かかることになります。この問題を解決するには「FileMaker Server/Web Publishing/publishing engine/jwpc-tomcat/conf/server.xml」のファイルを開きます。この部分を見つけます。

<Connector URIEncoding="UTF-8" acceptCount="100" 
address="127.0.0.1" 
compressableMimeType="text/html,text/css,text/plain,application/javascript,application/json" 
compression="on" compressionMinSize="2048" connectionTimeout="20000" 
disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" 
maxSpareThreads="75" maxThreads="150" minSpareThreads="5" port="16020" 
protocol="HTTP/1.1" redirectPort="8443"/>

「address="127.0.0.1」の部分を削除します。するとこのようになります。

<Connector URIEncoding="UTF-8" acceptCount="100" 
compressableMimeType="text/html,text/css,text/plain,application/javascript,application/json" 
compression="on" compressionMinSize="2048" connectionTimeout="20000" 
disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" 
maxSpareThreads="75" maxThreads="150" minSpareThreads="5" port="16020" 
protocol="HTTP/1.1" redirectPort="8443"/>

この変更を保存し、Web公開エンジンを再起動します。http://yourServer/fmi/xml/FMPXMLRESULT.xml?-dbnames のURLでWeb公開エンジンの動作を確かめます。データベース名のXMLのリストが表示されるはずです。表示されない場合は、コンピュータを再起動する必要があるかもしれません。動作する状態に戻ったら、同期は明らかに速くなっているはずです。変更されたレコードが100件未満の場合や、変更箇所のない同期の場合には、特に速くなります。

レコードを削除するのではなくフラグを立てる

ミラーシンクは、削除されたレコードを高速に検知します。しかし削除を調べるよりは、編集や挿入を同期する方が高速です。レコード数が10万件を超えるような大きなテーブルの場合は特にそうです。パフォーマンスを最適化したい場合は、レコードを実際に削除するのではなくフラグを立てるようにするとおそらく効果が見られるでしょう。これは編集の処理となり、テーブル内のレコードの件数には影響しません。

最初が空のクローンで初回の同期にとても長い時間がかかる場合に、空のクローンのテーブルをあらかじめ作っておくことができます。次の「オフラインのデータベースをあらかじめ作って初回の同期を速くすることはできますか？」の質問を参照してください。

オフラインのデータベースをあらかじめ作って初回の同期を速くすることはできますか？

はい。これにはいくつかの方法があります。

オフラインのユーザにFileMaker Serverからファイルの完全なコピーを取得してもらい、フィルタリングの条件に基づいて特定のレコードを削除する場合

管理者がしなくてはならないことは特にありません。ミラーシンクの構成でSpokeのデータベースを選択するときに、Spokeのデータベースのオプションで「メインファイルの空のクローンまたは完全なコピーと同期」を選択するだけです。データベースをダウンロードするかダウンロードのリンクを作成するときに、全体のコピーのオプションを指定します。この構成では、初回の同期はすぐに実行され、フィルタリングの条件に基づいてユーザがアクセスしないレコードが削除されます。

サーバのファイルのコピーと同期するが、ファイルサイズの理由でデータベースの完全なコピーをダウンロードしたくない場合

以下のステップを実行します。

メインのデータベースを複製し、オフラインのユーザが使用しないレコードをすべて削除します。

この複製したファイルを、メインファイルと同じFileMaker Serverでホストします。

管理ツールで、「別のモバイル用ファイルと同期★」のオプションを選択してから、モバイル用のファイルとして先ほどの複製したファイルを選択します。

このステップが完了すると、ユーザがミラーシンクのダウンロードのリンク機能を使用するときに、メインファイルのコピーではなく、複製してレコードを減らしたファイルがダウンロードされます。

ファイルのコピーをダウンロードをする前に特定のレコードを選択的に削除するが、これをユーザごとにカスタマイズする必要がある場合

これはシンプルです。ユーザ用のオフラインのコピーを作り、そのユーザが使用しないデータを削除し、ユーザに送ります。ユーザがすべてのデータに対してレコードレベルのアクセス権を持っていて、「MirrorSync customization」スクリプトでフィルタをまったく設定していない場合、初回の同期で削除したレコードがオフラインのファイルに書き戻されます。そのため、ユーザが同期中に取得しないレコードだけを削除してください。

あらかじめ作成した別のモバイル用ファイルを同期する場合

以下のステップを実行します。

使用したいレコードを、メインファイルからモバイル用のファイルにインポートします。

「インポート中、入力値の自動化オプションを実行」のチェックを必ずはずしてください。

プライマリキー、修正情報のタイムスタンプ、作成情報のタイムスタンプが、モバイル用のファイルとサーバのファイルの間で一致する必要があります。

同期中にユーザがアクセスするすべて、または大半のレコードををインポートするようにしてください。

ミラーシンクでは、ごくわずかの特定のレコードが保存されているテーブルよりも、空のテーブルを同期する方が高速です。

オフラインのユーザがデータベースに変更を加える前に同期を実行するようにしてください。

ユーザがモバイル用のファイルに作成する新規レコードはすべて、初回の同期中に削除されます。通常は初回の同期が成功した後に新規レコードを追加するので問題はありません。

セキュリティ

同期にSSL暗号化を有効にするにはどうすればよいですか？（未翻訳）

原題：How do I enable SSL encryption for syncing?

全ユーザーを同一ユーザー名／パスワードでHUBデータベースにログインさせるにはどうすればよいですか？（未翻訳）

原題：How do I make all of my users log in with the same username and password to the hub database?

ミラーシンクをカスタマイズする

MirrorSyncカスタマイズスクリプトとは何ですか？（未翻訳）

原題：What is the MirrorSync customization script?

オフラインのユーザには、データベース全体を同期させたくありません。特定のテーブル、フィールド、レコードだけを同期することはできますか？

この質問には3つの内容が含まれていて、答えも3つの内容に分かれます。

特定のテーブルを同期するのは、とても簡単です。ミラーシンクの管理ツールを使って同期の構成をするときに、同期したいテーブルに関連づけられているレイアウトだけを含めます。

特定のフィールドを同期するのもとても簡単です。同期したいフィールドだけを、同期のレイアウトに含めます。

特定のレコードを同期するのは、少しだけ複雑です。

「MirrorSync customization」スクリプトを編集します。

「Hub」のセクションへ移動します（「Spoke」ではありません。Spokeを変更することはほとんどありません）。

ここにあるFindChangesの記述の手順に従って、対象レコードを現在のユーザに同期させたいレコードだけに制限します。

このスクリプトはユーザが同期を実行したときに動作します。したがって、Get ( アカウント名 ) 関数を使ってどのレコードが使われるかを指定することができます。

$$globalVariables の使用には十分注意してください。$$globalVariables はカスタマイズのスクリプトの複数のコールにわたってずっと有効であるわけではありません（$$MIRRORSYNC_USERTOKEN は例外です。次の質問を参照してください）。

検索条件により除外されたレコードは、ユーザに対して同期されなくなります。さらに、除外されたレコードが以前に同期されていた場合、レコードはユーザのデバイスから削除されます。これにより、チェックイン／チェックアウトのワークフローをミラーシンクで簡単に作成できます。業務をiPadに同期し、業務が完了したらデバイスから削除できます。

カスタマイズのスクリプトをテストするには、テストしたい同期のレイアウトへ移動し、すべてのレコードを表示してから、「MirrorSync customization」スクリプトを実行します。期待した結果にならない場合は、スクリプトデバッガを使って調整してください。

レコードのアクセスを制限するためのもうひとつの方法は、FileMakerのレコードレベルのアクセス制限を使う方法です。ユーザのアクセス権セットの制限はすべてミラーシンクで有効になります。同期する際、ユーザはアクセスできるレコードだけを受信します。以前は表示されていて後から非表示に変更したレコードは、次回の同期で削除されます。スクリプト化されたレコードのフィルタは、レコードレベルのアクセス権を使用するよりも高速で構成しやすいことを覚えておいてください。

同期するレコードを制限する場合、データベースの完全なコピーではなく空のクローンをユーザに配付することができます。このようにすると、初回の同期ではデータベースにアクセスしているオフラインファイルにレコードを入れるだけです。多数のレコードにアクセスできるケースでは、すでにレコードのデータがすべて含まれている完全なデータベースのコピーを配付し初回の同期で余分なレコードを削除する場合と比べて、初回の同期は遅くなります。

全員がFileMakerの同じアカウントでログインする場合、ユーザごとにレコードをフィルタリングするにはどうすればいいですか？

$$MIRRORSYNC_USERTOKEN を使うと、そのようにできます。これは、同期を実行するときにミラーシンクがクライアントからサーバに渡す、特殊なグローバル変数です。このグローバル変数をクライアントに応じてセットすると、サーバにセットされ、「MirrorSync customization」スクリプトはレコードの検索の際にこれを使用できます。このグローバル変数は、サーバサイドのフィルタリングには「グローバル変数がない」というルールの唯一の例外です。好きなように利用できます。これをセットする「MirrorSync customization」スクリプトでは、条件がネスト化されていることに気づくでしょう。この「If」文は、サーバにセットされることを防ぎます。これは重要です。クライアントによって送信された値を上書きするからです。

SQLを使用してレコードをフィルタリングする方法（未翻訳）

原題：How can I filter records using SQL?

FileMaker Goで作成されたレコードがサーバとすでに同期されたことを、どうすれば確認できますか？

構成中に、いずれかのレコードを書き戻しの値として選択します（前述の「プライマリキー」のセクションの書き戻しの値を参照してください）。「Get ( ファイル共有状態 ) = 2」をチェックすることによって、サーバに値を自動入力するように設定します。このフィールドが空欄の場合は、レコードはまだ同期されていません。このフィールドに値が入力されている場合は、このレコードはサーバ上で作成されたか、またはFileMaker Goで作成されてサーバと同期したものです。

「MirrorSync customization」スクリプトの「didInsert」のセクションを変更する方法もあります（次の質問を参照してください）。ただし同期の際は、書き戻しの方法のほうが明らかに高速です。

レコードが同期されるときにサーバ上でスクリプトを実行するにはどうすればいいですか？

おそらく、ユーザが配送を完了した、見積のリクエストが作成された、製造に関する業務が削除されたなどの場合に、管理者にメールを送信したいということでしょう。このような処理をするには、「MirrorSync customization」スクリプトを変更します。スクリプト中に「DidUpdate」、「DidInsert」、「WillDelete」のセクションがあります。「Hub」のセクションでこれらを変更してください。Spokeで変更することは、まずありません。スクリプトの中の関連するセクションで、現在のレイアウトをチェックし、動作を実行させたいレイアウトになっていれば先へ進んでこのセクションで動作を実行します。開始したのと同じレイアウト、同じレコード上でスクリプトが終了するまでは、他のレイアウトへの移動、検索／挿入／更新／削除の実行、メールの送信、その他のあらゆる動作を実行できます。

「DidInsert」や「DidUpdate」スクリプトの結果としてレコードが変更されたことをミラーシンクが検知すると、クライアントの検索を再度実行し、「FindChanges」セクションに指定されているスクリプト化されたレコードの制限を検討します。たとえば、「業務の同期」レイアウト上のレコードのステータスが「完了」に変更されたときにユーザのiPadから業務を削除したいとしたら、以下のように設定します。

「FindChanges」セクションを変更して、「Get ( レイアウト名 ) = "業務の同期"」であるときにステータスが「完了」になったレコードを除外するようにします（FileMakerでこのような検索をするには、検索モードにして、ステータスのフィールドに「完了」と入力し、現在のレコード／リクエストを除外してから、対象レコードの絞り込みをします）。

「DidInsert」セクションを変更して、「Get ( レイアウト名 ) = "業務の同期"」であるときに修正情報のタイムスタンプを空欄にします。

「DidUpdate」セクションも同じようにします。

これで、オフラインのユーザが「業務の同期」テーブルのレコードを更新したり挿入したりすると、スクリプトによって修正情報のタイムスタンプが空欄になります。これが変更のトリガーとなって、ミラーシンクは検索を再実行し、検索結果から完了した業務を除外します。するとiPadから自動で削除されます。

なぜ修正情報のタイムスタンプを空欄にするのかと疑問に思うかもしれません。その答えは、あなたがレコードに変更を加える場合に、何を変更したかは重要ではないということです。修正情報のタイムスタンプを空欄にするのは、悪影響を及ぼさない変更です。空欄は、FileMakerによって即座に新しいタイムスタンプに置き換えられるからです。レコード上の任意のフィールドを現在の値にセットしたり、日付のフィールドに業務が完了したというデータを入力するなど、何か意味のある変更をしたりすることもできます。

同期を実行するときに、ユーザにダイアログを見せたくありません。表示しないようにすることはできますか？

はい。「MirrorSync customization」スクリプトで、「$$SILENT_MODE」グローバル変数を「1」にセットします。これにより、エラーが発生した場合と、ログインやコンフリクトの解決など情報が必要な場合を除いて、ミラーシンクのダイアログが表示されなくなります。

ログインのダイアログもスキップしたい場合で、かつあなたがユーザのパスワードを知っているか（たとえばユーザのテーブルにパスワードが保存されている場合）、または全員が同じアカウントで同期している場合は、「MirrorSync customization」スクリプトで「$$MIRRORSYNC_USERNAME」と「$$MIRRORSYNC_PASSWORD」の値をハードコードすることができます。両方の値が空でない場合、ミラーシンクはユーザにパスワードの入力を求めません。

コンフリクトを解決するダイアログを表示したくない場合は、ミラーシンクの構成のプロセスのうちコンフリクトの解決のセクションで、「ユーザが選択する」以外のオプションを選択します。

同期を実行するときに、ユーザにミラーシンクのウインドウを見せたくありません。表示しないようにすることはできますか？

ミラーシンクをFileMaker Proで実行しているなら、できます。「MirrorSync customization」スクリプトで、「$$MIRRORSYNC_HIDE_WINDOW」変数を「1」にセットします。これにより、ミラーシンクのウインドウが画面の外へ移動し、ユーザからは見えなくなります。これは、同期に数秒以上かかるような大がかりな処理には推奨しません。ステータスを表示しないと、コンピュータがフリーズしたとユーザが思ってしまうおそれがあるからです。

iOSでミラーシンクを実行している場合は、非表示にすることはできません。現在の選択を解除せずに対象レコードを操作するには新規ウインドウを開く必要があり、iOSデバイスではウインドウを画面の外に移動して隠すことができないからです。「$$MIRRORSYNC_HIDE_WINDOW」変数は、iOSでは無視されます。

その他のミラーシンクのダイアログをユーザに見せないようにしたり、文言を変更したりすることはできますか？

はい。「MirrorSync customization」スクリプトを使うと、ダイアログやエラーメッセージを抑制したり変更したりすることができます。「MirrorSync customization」スクリプトの最後の方を見ると、通常の同期中にユーザに対して表示されるメッセージについて、タイプごとのダイアログを設定しているセクションがあります。ユーザに対して表示されるメッセージやボタンのタイトルをカスタマイズできます（ただしボタンの並び順ごとに同じ意味になるようにしてください）。ダイアログを表示したくない場合は、ダイアログを表示するスクリプトステップを無効にします。ただし、どのオプションを選択するかを決め、そのボタンの番号を使ってスクリプトを抜ける必要があります。このテクニックを使って、表示されるメッセージをユーザの使いやすい言語にすることもできます。

ユーザが業務／送り状／ウィジェットを完了したときにミラーシンクを自動で実行することはできますか？　スタートアップ時に実行することはできますか？

もちろん、できます。まず、「MirrorSync setup」スクリプトをスタートアップスクリプトに設定するか、またはスタートアップスクリプトからコールすることを推奨します。これにより、ファイルがオフラインで使われているかどうか、これまでに同期したことがあるかどうかがチェックされます。同期されていなければ、初回の同期を実行するようにユーザに通知します。また「MirrorSync setup」スクリプトで「$$MIRRORSYNC_CLIENTID 」グローバル変数をセットします。プライマリキーの方針によっては、これは必須です（前述の「プライマリキー」のセクションを参照してください）。

「MirrorSync」スクリプトは通常のFileMakerのスクリプトであり、任意のタイミングで実行するように開発者が設定できます。たとえば、ユーザが変更を加える前に最新の値を必ず見せなくてはならない部分がある場合、ユーザがその画面に移動したことをトリガーとして同期を実行し、その画面での編集が終了したら再度同期します。チェックボックスにチェックを付ける、ボタンをクリックする、他にもあなたが設定した条件によって、同期を開始できます。

ミラーシンクをX秒／分おきに自動で実行することはできますか？

はい。On Timerスクリプトを使って実行できます。ただし、スクリプトを実行するときには現在のレコードが確定され、数秒間新規ウインドウが開くことに注意してください。ユーザが何か作業をしている途中でこれが発生すると、困ることがあります。このため、前の質問で説明したようにスクリプトで同期する処理をユーザの操作に関連付ける方法を推奨します。例外は、操作されないコンピュータです。データベースの予備の複製を作っておくためにユーザが操作しなくても常にミラーシンクを動作させるコンピュータがある場合は、必ず処理を進行させてOn Timerスクリプトステップを使用します（前述の、ダイアログを無効にするFAQも参照してください）。

ミラーシンクのレイアウトをカスタマイズする

自分のソリューションにペーストした「MirrorSync」レイアウトは、自由に外観を変更してかまいません。ただし、変更する前に以下のヒントを実行してください。

カスタマイズする前に、FileMaker ProとFileMaker Goで問題なく同期ができることを確認します。

変更前の「MirrorSync」レイアウトのバックアップコピーを作成します。

レイアウト上のタブと、各タブの中のフィールドをそのままにしておくことが重要です。注意すべき点としてもうひとつ、「MirrorSync」レイアウトには、1x1ピクセルのWebビューアが2つあります。この2つをレイアウト上に必ず見える状態で残しておいてください。

変更した後で同期が動作しなくなった場合、レイアウト上のWebビューアを誤って削除してしまったのかもしれません。レイアウトのバックアップコピーから復元してください。

重複に対処する

2人のユーザが、同じ顧客に関して別々に新規レコードを作成するとします。サーバ上では、同じ顧客名で挿入されたレコードは既存のレコードとして自動で削除したいと考えます。重複を避けるためのスクリプトを配置する場所は、「MirrorSync customization」スクリプトの「DidInsert」セクションです。このスクリプトで、新たに挿入されたレコードの顧客名（あるいは重複を避けるために使用したい任意のフィールド）を取得し、検索を実行する必要があります。レコードが1件だけ見つかったら、それ以上は何もしません。複数のレコードが見つかったら、どちらか要らない方を削除します。このことが、同期が完了した後に、自動で再度同期するトリガーとなります。もちろん、もっと洗練された処理にすることもできます。たとえば2つめのレコードから1つめのレコードに値をまとめたり、実際に削除するのではなく重複の可能性があるとレコードにマークを付けるだけにして後で管理者が整理するといった方法があります。

ダウンロードリンクのURL機能用に独自のフロントエンドを構築できますか？（未翻訳）

原題：Can I build my own front-end for the download link URL feature?

大規模なデータベースを同期するとき注意すべきこと

原題：What should I be aware for very large database synchronization?

非常に大きなデータベースを同期するとき、以下の点を考慮、検討してください

「3.17より前のバージョンでは」、内部の同期データベースの上限が64GBまででした。これは3.17で256GBまでに上がっています。MirrorSync.xmlに‘maxSyncDatabaseSize’の設定をすることでさらにあげることもできます。設定後、同期データをリセットしてから新規同期を行うと有効になります。

MirrorSyncはプライマリキーにシリアル番号またはUUIDを使用できますが、非常に大きなデータベースの場合はUUIDをお勧めします。MirrorSyncの内部同期データベースで何かが壊れた場合、非常に大きなデータベースをシリアル番号の主キーと同期させることはほぼ不可能です。

データベースが非常に大きい場合、競合のマージが遅くなることがあります。フィールドの変更をマージする必要がない場合は、MirrorSync設定でフィールドレベルのマージを無効にします。

データベースが大きくなればなるほど、スピンするディスクのハードドライブからSSDに切り替えることによって得られるスピードの利点が増えます。

ライセンスミラーシンクのライセンスや価格はどのようになっていますか？

ミラーシンクは、1本のFileMaker ProまたはFileMaker GoとFileMaker Serveとの同期については、完全に無料で機能の制限なくお使いいただけます。サーバの構成やデバイスの追加は、オプションで購入できます。

サポートしている構成の種類は以下の通りです。

FileMaker ServerとFileMakerクライアント（GoまたはPro）

```
FileMaker ServerとFileMaker Server
```

FileMaker Serverと任意のSQLデータベース（Oracle、MySQL、MS SQL Serverを完全にサポートしています。JDBCドライバを使用しているデータベースもすべて同期できます）

SQLデータベースとSQLデータベース

SQLデータベースとFileMakerクライアント（GoまたはPro）

デバイスの台数は、1台から購入でき、累計デバイス数に応じて単価を割引して販売しています。無料のミラーシンクで使用できる1台のデバイスに追加して購入できます。

価格の詳細は弊社のオンラインストアをご覧ください。

ミラーシンクのバーティカルマーケット向けライセンスはありますか？

いいえ、ございません。

ミラーシンクはFileMaker Serverの同時接続を使用しますか？

ミラーシンク2.1はオブジェクト以外のデータ（テキスト、数字、日付、時刻、タイムスタンプ）には同時接続を使用しません。オブジェクトフィールドを同期する場合、使用しているFileMaker Pro／Goのバージョンとオブジェクトフィールドの内容の容量に応じて、同期している間はFileMaker Serverに接続することがあります（同期が終わり次第すぐに接続解除します）。

以下の表で「X」となっているのは、ミラーシンクがFileMaker Serverのゲストとして接続する必要があるケースです。

FileMaker Pro／Goのバージョン

サーバからオブジェクトをダウンロード

サーバにオブジェクトをアップロード

（10MB以下）

サーバにオブジェクトをアップロード

（10MB以上）

その他の質問

ファイルのオフラインのコピーだけが手元に残っていて、これをサーバにアップロードして戻す必要があります。どのようにすればいいですか？

必要に応じて、ファイルのオフラインのコピーをFileMaker Serverに再アップロードしてミラーシンクで使うことができます。「MirrorSync」テーブルの「Client」のレコードを削除し、「Server」のレコードだけを残してください。このようにするには、「MirrorSync」レイアウトに移動し、「デバッグ」タブに切り替えます。「type」のフィールドに「Server」と入力して検索します。ステータスバーにある円グラフのアイコンをクリックして、対象外のレコードを選択します。そして、対象となっているレコードを削除します。

トラブルシューティング／既知の問題

問題があるように思えるときは、以下のことを試してみてください。

同期データのリセット

ミラーシンクは、同期しているすべてのデバイスのプライマリキー、修正情報のタイムスタンプ、内部レコードIDを、内部のSQLデータベースに保存しています。ときおり、この内部データベースが最新のデータになっていないことがあります。特に、データベースでプライマリキーが変更された場合に多く見られます。これが問題となっていると疑われる場合は、この内部データをリセットできます。ミラーシンクをまったく同期されたことがない状態に戻してやり直す方法です。ただしこの方法を取る前に、このようにすると既存のオフラインのファイルはすべてそれ以降同期できなくなることを十分に検討してください。オフラインのファイルの変更をまだ同期していないユーザがいる場合は、この方法を実行しないでください！　その心配がなければ、ミラーシンクの管理ツールで構成の名前を右クリック（MacではControl - クリック）して、「同期データをリセット」を選択します。その後、新しいオフラインファイルと再び同期して、問題が解決しているかどうか確かめます。

「ProscTomcatDaemon.jar」ファイルを実行できません

インストール中にこのメッセージが表示され、Kerio VPNクライアントがインストールされている場合は、ミラーシンクをインストールするためにKerioを削除するか、またはミラーシンクを手動でインストールする必要があります。Kerio VPNクライアントはデフォルトで、本製品がProscTomcatDaemonと通信するために使用しているのと同じポートを使用します。

最大数のユーザがこのFileMaker Proを使用しています

これはFileMaker ProとFileMaker Pro Advancedのバグで、「MirrorSync」スクリプトをペーストしたり編集したりしたときに発生することがあります。これはスクリプト中に、内部と外部の両方のIPアドレスを参照する部分があるためです。FileMakerは両方の参照を開き、このことがFileMaker Proが2コピー使われているとライセンスサーバに通知するトリガーとなります。このエラーは、ホストされている1つのファイルに両方の参照を含むスクリプトであればどれでも発生します。

これを回避するには、以下の2つの方法があります。

シングルユーザライセンスを、ボリュームライセンスにアップグレードします。5本以上のコピーを所有している場合は、ファイルメーカー社に直接問い合わせてアップグレードできます。

スクリプトをペーストし、ライセンスのエラーへの対応としてFileMakerを閉じます。スクリプトは適切に保存され、正しく動作するはずです。

この問題について相談したい方は、弊社までお問い合わせください。

「102 フィールドが見つかりません」エラーが発生しましたが、同期のレイアウトに必要なフィールドはすべて配置されています。何が問題なのでしょうか？

同期のレイアウトが、オフラインとサーバのファイルで一致していることを確認してください。繰り返しフィールドがある場合、フィールド定義で指定されている最大繰り返し数が表示されるようになっていることを確認してください。つまり、フィールドの最大繰り返し数が5であれば、インスペクタの「繰り返しを表示」も5にするということです。

「Last sync failed: java.sql.SQLException: Error in table <Sync Layout Name>: Parse Error During Update 1: -1」のエラーが出て、同期が毎回失敗します

同期するソリューションに、同期するフィールドが999個以上ある場合に、この問題が発生します。FileMakerで「Let」文により使える変数の数は、1,000個です。本製品のサーバ - クライアント間のトランザクションでは、内部で変数を2つ使用します。そのため、同期できるフィールドの最大数は、1テーブルあたり998個です。

同期または構成中にエラー502が発生します

このエラーは、リクエスト待ちの後にタイムアウトするようになっているIISの構成によって発生します。とても複雑な構成や処理の場合に、完了するまでにタイムアウトに設定されているよりも長い時間がかかることがあります。

ミラーシンクの構成中にこのエラーが発生する場合は、「Disable IIS timeout（IISのタイムアウトを無効にする）」の手順に従ってください。

同期の実行中に発生する場合は、上述の手順に従ってIISのタイムアウトを無効にするか、またはJDBCを使う構成に切り替えてください。同期にJDBCを使うのは簡単です。FileMaker ServerでxDBCを有効にしてから（FileMaker Server Advanced 12またはFileMaker Server 13が必要です）、同期に使用するすべてのアクセス権セットでfmxdbc拡張アクセス権を有効にします。

オブジェクトフィールドが同期しません

FileMaker 10、11、12のいずれかを使っていオブジェクトフィールドを同期できない場合は、外部データソースをチェックします（「ファイル」＞「管理」＞「外部データソース」）。外部データソースが、正しいサーバのアドレスをポイントしていることを確かめてください。これは「MirrorSync」スクリプトをペーストしたときに自動でセットされますが、ミラーシンクの構成でFileMaker Serverのアドレスを後から変更した場合、ミラーシンクが自動で外部データソースを編集することはできません。これはFileMaker 13およびMirrorSync 2.1以降では発生しません。（FileMaker Serverのゲストとして接続するのではなく）HTTP POSTを使用してオブジェクトフィールドを転送するためです。

FileMaker Server 12を使用していてFileMaker Go 13と同期する場合は、FileMaker Advanced 13（12ではなく）を使って「MirrorSync」スクリプトステップをコピー＆ペーストします。FileMaker Go 13からFileMaker Server 12にオブジェクトのイメージを挿入するとXML Web公開エンジン経由でアクセスできなくなるという既知のバグがあります（ http://forums.filemaker.com/posts/8d3a4548bd ）。スクリプトステップをペーストするときにFileMaker Pro／Advanced 13を使用する場合は、オブジェクトデータにHTTP POSTを使うことでこのバグを回避できます。

ダウンロードの際にオブジェクトフィールドが破損してしまいます。

フィールドの内容をエクスポートして、4バイトの長さになっているかどうか確かめてください。もしそうなっていたら、FileMaker Server 12の既知のバグの影響です（http://forums.filemaker.com/posts/8d3a4548bd ）。FileMaker Go 13を使っているiPadまたはiPhoneがFileMaker Server 12に直接接続してオブジェクトフィールドをアップロードする場合、オブジェクトデータに不可視の属性を追加します。これにより、XML Web公開エンジンを使って正しく公開することができなくなり、ファイルタイプを表す4バイトの値だけを返すようになります。ミラーシンクはデフォルトでXML Web公開エンジンを使ってオブジェクトデータを取得するため、この問題が発生します。この問題の解決策は、いくつか考えられます。

FileMaker ServerでxDBCアクセスを有効にして、同期するユーザにはfmxdbc拡張アクセス権を有効にします。これによりミラーシンクは、XML Web公開エンジンから、このバグの影響を受けないJDBCドライバに変更されます。

FileMaker Server 12から、このバグの影響を受けないFileMaker Server 13に切り替えます。

FileMaker Go 13からFileMaker Server 12に直接接続しないようにします。サーバにレコードを書き込む代わりに、ミラーシンクを使用します。ミラーシンクによって挿入されるオブジェクトは、このバグの影響を受けません。

「このソフトウェアを初めて使うときにはネットワーク接続が必要です」

OS X 10.9（Mavericks）を使っていてJava 6がインストールされている場合、Mavericksのインストーラは信頼済みのSSL証明書のリストを消します。これにより、ミラーシンクはライセンスサーバと通信できなくなります。この問題を解決するには、Apple社の以下ののページからJava 6アップデートをインストールします。 http://support.apple.com/kb/DL1572?viewlocale=ja_JP

ほんとうにこれに起因する問題なのかどうかを確認したい場合は、C:￥Program Files?360Works￥Applications￥logs または /Library/360Works/Applications/logs にあるミラーシンクのログファイルを見てください。「the trustAnchors parameter must be non-empty」というテキストがあれば、明らかにこの問題です。

見つからないフィールド<フィールド名>は、ローカルのファイルで名前が変更されたか、削除されています。★

特定のフィールドに対してすべてのアクセスを拒否するフィールドレベルのアクセス権を設定している場合、同期しようとすると常にこのエラーが発生します。解決策は、クライアントとサーバに対し完全アクセス権で実行されるように「MirrorSync」スクリプトを設定することです。詳しくは以下に記載しています。（ミラーシンクでは、同期するユーザに完全アクセスのアカウントが必要ですか？）

エラー201：「フィールドを変更できません」★

オフラインのユーザに対し特定のフィールドを変更できないようにフィールドレベルのアクセス権を設定している場合、サーバ上でレコードが変更されたときにこのエラーが発生します。解決策は、クライアントとサーバに対し完全アクセス権で実行されるように「MirrorSync」スクリプトを設定することです。詳しくは以下に記載しています。（ミラーシンクでは、同期するユーザに完全アクセスのアカウントが必要ですか？）

セットアップのプロセスで、いくつかのテーブルに空白のレコードが残ってしまいます。

ミラーシンクのセットアップのプロセスでは、テーブルに一時的なレコードを作って、自動でプライマリキー、修正情報のタイムスタンプ、作成情報のタイムスタンプを検知します。終了後に、この一時的なレコードを削除するようになっています。一時的なレコードが削除されない場合は、外部ファイルに保存されているテーブルにカスケード削除のルールが設定されているかどうかを確認します。設定されている場合、自分のユーザ名とパスワードでその外部ファイルにアクセスできるかどうかということと、外部ファイルでそのユーザ名に対してFMXML拡張アクセス権が有効になっていることを確認します。

サーバから500（内部サーバ）エラーが返ってきます。

いくつかの理由が考えられますが、最もよくある理由はWeb公開エンジンのメモリ不足とWeb公開エンジンで発生しているタイムアウトの2つです。どの理由によるものかは、Apacheのログファイルを見るとわかります（FileMaker Server 13では、ログファイルは/Library/FileMaker Server/HTTPServer/logsディレクトリの中にあります）。次のようなエントリーがあれば、タイムアウトが発生しているということです。

[error] (70007)The timeout specified has expired: proxy: read response failed from 127.0.0.1:16021 (127.0.0.1)

タイムアウトの調整は、難しくありません。テキストエディタを使って/Library/FileMaker Server/Admin/admin-helper/WEB-INF/conf/mod_proxy.conf のファイルを変更します。以下のような行を見つけます。

ProxyPass /fmi ajp://127.0.0.1:16021/fmi

「timeout=1200」のパラメータを追加します（これにより1,200秒／20分のタイムアウトがセットされます）。以下のようになります。

ProxyPass /fmi ajp://127.0.0.1:16021/fmi timeout=1200

タイムアウトの問題でない場合は、おそらくWeb公開エンジンのメモリの問題でしょう。これは、FileMaker Server 13よりも、FileMaker Server 11または12で多く発生します。

対象レコードがきわめて多い場合には、XML Web公開ではなくJDBCを使うことを推奨します。JDBCのほうが、メモリ不足の影響をずっと受けにくいからです。JDBCに切り替えるには、FileMaker ServerでxDBCを有効にして、同期するユーザはfmxdbc拡張アクセス権を有効にするだけです。この条件が満たされると、ミラーシンクは自動でJDBCに切り替わります。xDBCに切り替える方法をとらない場合や、問題が解決しない場合は、Web公開エンジンのメモリの割り当てを増やす必要があります。

Web公開エンジンのメモリの割り当てを調整するには、以下のファイルを編集します。

Mac: /Library/FileMaker Server/Web Publishing/publishing-engine/jwpc-tomcat/bin/catalina.sh
Windows: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\jwpc-tomcat\bin\catalina.bat

「-Xmx512M」というテキストを含む行を見つけます。「512」が割り当てられているメモリのメガバイト数です。この数字を1024や2048など、もっと大きい数字に変えます（数字の後の「M」は必ず残しておいてください）。このファイルを保存し、FileMakerのAdmin Consoleを使ってWeb公開エンジンを再起動します。その後、もう一度同期してみます。FileMaker Server 13ではこの数字があらかじめ2048に設定されているため、調整が必要となるのはおそらくFileMaker Server 10、11、12のいずれかを使用している場合だけでしょう。

メモリ不足エラー★

これは、ミラーシンク自体のメモリが不足しているという意味です。レコードを大量に一括処理で同期しているときに、このエラーが発生することがあります。

（初回の同期ではなく）差分の同期中にこのエラーが発生し、差分の同期中にそれほどたくさんの変更はないと考えられる場合には、「MirrorSync customization」スクリプトをチェックしてください。対象レコードが解除される「すべてのレコードを表示」や「検索を実行」が使われていないことを確認してください。対象レコードのサイズを減らすには、「対象レコードの絞り込み」だけを実行します。

初回の同期中にこのエラーが発生し、テーブルに10万件以上のレコードがある場合は、初回の同期のためにおそらくミラーシンクのメモリの割り当てを増やす必要があるでしょう。1台目のデバイスと同期する場合は、特にそうです。

ミラーシンクにはデフォルトで512MBが割り当てられています。20万件程度のレコードの変更を一括で同期する際には、通常はこれで十分です。ただし多くの情報が含まれるレコードでは、この件数はずっと少なくなります。この数字を、同時に同期するデバイス数で割り算してみてください。4人が同時に同期するとしたら、おそらくミラーシンクはデフォルトの割り当てメモリで1ユーザあたり5万件の変更を扱えます。この想定には、オブジェクトフィールドは含まれません。FileMaker Go／Pro 13でオブジェクトフィールドを使用する場合、オブジェクトフィールドは一時的にミラーシンクのメモリに保管され、ユーザが1人だけであってもメモリのエラーが発生するおそれがあります。

メモリの割り当てを増やす必要がある場合、まずMirrorSync 2.2以降を使用していることを確認してください。それから「setenv」ファイルを変更します。手順はWeb公開エンジンの場合とよく似ていますが、ファイルの場所は以下の通りです。

Mac: /Library/360Works/Applications/bin/setenv.sh
Windows: C:\Program Files\360Works\Applications\bin\setenv.bat

次の記述の行を見てください

CATALINA_OPTS="-Dcom.prosc.tomcat=true -Xmx512M

-Xmx パラメーターの値を、割り当てたいメモリサイズに変更します。1GBに割り当てる場合は下記の通りです。

CATALINA_OPTS="-Dcom.prosc.tomcat=true -Xmx1G

新しいメモリの設定を適用するには、360Works Admin.jar を利用して、Tomcat を再起動します。OSX では  /Applications に、Windows では C:\Program Files\360Works\ にあります。

ミラーシンクがファイアウォール越しにFileMaker Serverと通信すると、同期がとても遅くなります。

これは、ミラーシンクのサーバアプリケーションがFileMaker Serverとは違うコンピュータにインストールされていて、その2つのFileMaker Serverの間にファイアウォールがあるときに発生することがあります。ミラーシンクはJDBCのアクセスの際に2399番ポートで接続を確立しようとするために、この問題が発生します。ファイアウォールがこのポートをブロックしている場合、接続の試行がタイムアウトになるまで同期が開始されません。考えられる解決策は3つあります。

1)

望ましい解決策は、ミラーシンクをファイアウォールの内側へ移動することです。以下の構成になっていれば、

クライアント <-> ミラーシンク <-> ファイアウォール <-> FileMaker Server

このような構成にします。

クライアント <-> ファイアウォール <-> ミラーシンク <-> FileMaker Server

これによりミラーシンクは、サーバ上で有効になったときにxDBCを使えるようになります。

2)

ミラーシンクがxDBCの使用を試行しないようにします。このようにするには、XMLの構成ファイルを変更します

Windowsでは C:￥Program Files￥360Works￥Applications￥conf￥Catalina￥localhost￥MirrorSync.xml

Macでは /Library/360Works/Applications/conf/Catalina/localhost/MirrorSync.xml

「useJdbcIfAvailable」という属性を見つけ、これを「true」から「false」に変更します。

3)

ファイアウォールで2399番ポートを開けます。FileMaker ServerでxDBCが無効になっているとしても、少なくとも無効であるというレスポンスは速くなります。