Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する

　FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。


　スタンバイサーバー - 概要


　プログレッシブバックアップを利用した現用系（プライマリ）と予備系（スタンバイ）のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

　しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

　今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン（VM）のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
　今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
　今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
　スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法

1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
　その後、Windows Server OS と　FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント：
　― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
　― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。



　このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
　上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除（切断）します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD）を作成します。
 Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます。

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる

ポイント：
　― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
　このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事：ドメインにログインできなくなって泣かされる

　― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
　　ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX　日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。



　シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

　― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法

1. プライマリサーバの公開済データベースを全部閉じます。

　コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

　接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
　このセットアップコードをメモしておきます。


2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント：
　― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。

4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

　ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。

5. プライマリサーバのデータベースを再度公開します。

　すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。

　このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。

　スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法（メンテナンス時、障害発生時のサーバ切替）は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。

おまけ： FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法

　これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

　そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。

fmsadmin standby disconnect

　本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

　これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

（亀）

FileMaker バックアップ関連記事：

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


Hyper-V 関連記事：

Hyper-V の仮想マシンの移行方法（エクスポート＆インポート）
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る

【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

新WebDirectのパフォーマンスについてあれこれ

　FileMaker 13 の WebDirect (以下、WebDirect 13) と比べ、FileMaker 14 の WebDirect (以下、WebDirect 14) のパフォーマンスはどれだけ向上したのか？実用に耐えるレベルになったのか？
　WebDirect 14 の導入を検討するにあたり、これはとっても気になるところです。

　FileMaker 社の公式サイトでは、WebDirect の起動スピードは以前より 25% 向上していると謳ってはいます。また、独自にパフォーマンスの比較検証を行って公開している方（会社）もおいでで、そうした情報はとっても貴重です。

　ということで、パフォーマンスについて情報を公開している方の情報を例によって渉猟してみました。　（あと、人様の情報を紹介させて頂くだけでは申し訳ないので、弊社でも WebDirect のパフォーマンスの検証をしてみました。）

米国 FileMaker 社（パートナー）が公開している YouTube ビデオ

　かの有名な  Richard Carlton Consulting Inc. の FileMaker Training Videos Channel という動画です。

　WebDirect関連のビデオでは 「第一部：FileMaker WebDirect 14 のご紹介」、「第二部：WebDirect の最適化方」の 2 本が公開されていますが、その中からパフォーマンスに関する情報を拾って要約しました。

「第一部：FileMaker WebDirect 14 のご紹介」　Introduction to FileMaker WebDirect 14

　WebDirect がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

1. 11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
2. 13:40 WebDirect 14 によるレコード移動時の表示速度デモ
3. 15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
4. 16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている。
5. 20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている！（WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。）。
6. 27:28 WebDirect は ChromeBook の動作保障をしていないが、自己検証ではサクサク動いた。

（動画は英語）

　

　特に　15:13 あたりの WebDirect 13 vs WebDirect 14 レコード移動速度比較実験は必見！
　ウィンドウを左右に並べて比較しているので、速度が向上していることは一目瞭然にわかります。

「第二部：WebDirect の最適化」　Optimaizing Solutions for FileMaker WebDirect 14 

　2013年の Richard Carlton Consulting Inc. の FileMaker 13 WebDirect Overview and Optimization Presentation と基本的な流れは同じですが、 WebDirect 14 に関する情報にも触れられています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

1. 17:55 *.fp7 ファイルを  FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
   これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
   サイズが約半分ということは、転送速度が約2倍になっているといえる。
2. 18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
3. 19:55 WebDirect 13 で共有スタイルで最適化したレイアウトサイズは 480kb だったが、 WebDirect 14 で同様の作業を行うと 425kb で、 約15% スリム化されていることがわかった。

（動画は英語）

 　今回は WebDirect のパフォーマンス比較がわかるところのみを中心にご紹介していますが、ビデオの中では以下のようなことにも触れています。

WebDirect 13 の最適化ビデオと重なる情報は省いてあります。より詳しい情報をご覧になりたい方は、FileMaker 13 WebDirect Overview and Optimization （英語）をご覧いただくか、弊社記事 WebDirect 開発の勘どころ をご覧ください。

画像について 

　ｊpeg, png などの画像利用は最小限にする。
　FileMaker Pro 14 には軽量の SVG ビルトイン画像（glyph）が用意されているので、これを使ってボタンアイコンを装飾することを検討。
　※SVG = スケーラブル・ベクター・グラフィックス

タブ・スライドコントロールについて

　タブ、スライドコントロールの使用もできるだけ避ける。
　必要のない情報をロードさせないのが基本。
　タブコントロールを配置するれば、裏でタブ上のすべての情報がロードされることに注意。

ポップオーバーについて

　FMP13 で導入されたポップオーバーも要注意。
　ブラウザに別ウィンドウを表示させる代わりに使えるが、多用は避けること。
　裏であらかじめすべてのポップオーバーデータをロードすることには変わりはない。

スクリプトトリガについて

　WebDirect 側にはスクリプトエンジンが搭載されていない。
　このため、イベントが発生するたびに FileMaker Server にアクセスして処理を決定する。
　当然、スクリプトをトリガさせるイベントがたびたび発生すれば、その分のトラフィックが増加する。
　このトラフィックコストはできるだけ少なくした方がよい。

FileMaker WebDirect 14 のパフォーマンス最適化については、「FileMaker 14 WebDirect ガイド」の 14 ページ「ステップ 3: パフォーマンスの最適化」（PDF）にヒントが掲載されています。こちらも併せて読むと、参考になると思います。

---

土屋企画による WebDirect パフォーマンス検証

 

 小社でも『FMEasy在庫 IWP/WD R1.5』 という製品を使い、社外と社内の2つのサーバでテストをしていました。

■実行環境
社外：米国某ホスティングサービス(VM/共用タイプ)、16 GB RAM/Xeon E5 4 cores
社内：自社サーバ（VM/占有タイプ）、4GB RAM/core i7（4プロセッサ割り当て）
FileMaker Server： Ver14.0.2（サーバ1/サーバ2共に）
使用ブラウザ：主としてIE10、IE11
注：VM＝仮想マシン

■テスト内容
　予め、連続ビュー、連続更新、出庫伝連続伝票作成、という3つのループスクリプト（後述）作っておき、5～10個のブラウザウインドウからこれらのスクリプトを実行しています。
　で、こんな感じになります。

　上図は、1台のPC上で10個のIE10ブラウザウインドウを開き、ループスクリプトを実行していますが、Remote Desktop （RDT）で複数のセッションを開き、それぞれのセッションで1～複数のブラウザウインドウを開いてループスクリプトを実行というテストも行っています。
　後述の「■テスト」の項では、＜社内/1PC/複数ブラウザ＞、＜社外/複数RDT/1ブラウザ＞などと表記しますが、前者は社内サーバに1台のPCから複数のブラウザウインドウを起動しアクセス・テスト、後者は社外サーバに複数のRemote Desk Top から1つのブラウザウインドウを起動してアクセス・テスト、を表しています。

■ループスクリプトの内容
1. 連続ビュー
上図の出庫画面で先頭レコードから1件づつ後方へ移動していく。移動直後に0.2～1秒ポーズし、50～100件目に到達したらメッセージを出して終了する。

2.連続更新
上記の連続ビューと基本は同じだが、移動直後に備考フィールドに実行時の日時を追記する。

3.連続伝票作成（クライアントサイド）
出庫伝票形式のデータを連続して100件作る。といっても、1出庫レコードには25の出庫明細レコードが付属しているので、このスクリプトを1回実行すると、出庫レコード100件+出庫明細レコード2500（25明細×100）件、計2600のレコードが作成される。

4.連続伝票作成（サーバサイド）
仕様は上記4同じだが、サーバサイドスクリプトで実行。

■テスト
1.連続ビュー　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続ビューを実行し、すべてのブラウザでエラーなく成功。


以下の動画は、撮影の都合上、6つのブラウザで実行しています。

2.連続更新
2-1　 連続更新　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続更新を実行し、全てで成功。但し、上記1よりは時間がかかる。

2-2　連続更新による影響　 ＜社外/複数RDT/1ブラウザ＞
6つのRDTで1つのブラウザを起動し、それぞれで連続更新スクリプトを実行させた後、ローカルでブラウザを起動し、テスト実行者が手動によりレコード移動や入力を行いました。　これは、他のユーザが入力作業をしていると、どのような影響を受けるかシミュレートしたものです。結果は以下の通りです。

• 6つのRDTの連続更新は時間はかかるもの成功します。
• ローカルのブラウザでは入力は成功するものの 、レコード移動ボタン（＞アイコン）を数回クリックすると、サークルアイコンが現れ操作ができなくなる現象が頻発します。数分待つと画面が表示されますが、これでは実用に耐えないレベルです。　
  

2-3　連続更新による影響　 ＜社内/複数RDT/1ブラウザ ＞
上述の2-2 と同様テスト内容を 社内サーバで実行したときの模様です。

• 今回は、ローカルで新規レコード入力操作中にサークルアイコンが現れ、その後 15 分経過しても状況が変わらなかったため、テストを中断しました。
• このサークルアイコンが現われ操作不能になる現象は今回のループテスト実行中に何回も発生しました。　サーバ性能を上げるとこの現象は緩和されるのかもしれませんが、性能を上げたとしても FileMaker Pro 並みの安定運用を行うのは厳しいのではないかと思われます。　

2-4　連続更新を24セッションで実行 ＜社内/複数RDT/複数ブラウザ ＞
4つの RDTクライアントでそれぞれ5つのIE10ブラウザウインドウを開き、さらにローカルで4つのIEブラウザウインドウを開いて（計24セッション＝4×5+4）て連続更新スクリプトを実行。成功したのは24セッション中9、残りの15セッションはサークルアイコンが出現し制御不能に。

3.連続伝票作成（クライアントサイド） 　＜社外/1PC/1ブラウザ＞
1つのIE10ブラウザウインドウで成功。所要時間は43秒。但し、再度実行すると、ブラウザが反応しなくなる（下図）。

4. .連続伝票作成（サーバサイド）　＜社外/1PC/1or 5ブラウザ＞

1つのIE10ブラウザウインドウで数秒で成功。但し、実行直後から全くブラウザが反応（上図と同様）しなくなることがある。
バグを修正したところ、上記打消し線部の問題は解消。　5つのブラウザウインドウ上で本スクリプトを同時実行したところ正常終了。さらに、続けて5つのブラウザで同スクリプトを実行したところ、こちらも問題なく終了。
※バッチ処理は実行速度と安定性から、利用可能であればサーバサイドスクリプトを利用するのが良い

※　今回のテストを通じて思ったこと　―　WebDirect導入時の注意点

1. 複数のブラウザでループスクリプトを実行しても（動作は遅くても）比較的に安定して動作する。
2. ユーザが ＜ や ＞ （レコード間移動）ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。 ＜ や ＞　を連続押しすると、この現象は高い頻度で発生する。
3. レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる（サークルアイコンが出っ放し状態）になることがある。
4. サーバサイドスクリプトが実行できる状況であれば、使う

上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記2の現象に関し、WinMTR の結果をホスティング会社に送付し問い合せたところ、「some severe packet loss and latency from you location in Japan to our location」とのことでした。　ただ、サークルアイコン出っ放し状態の時でも、FileMaker Pro によりサーバにアクセスして ＜ あるい ＞ をクリックすると、速度は遅いものの正常に動作すること、社内サーバを使用してもサーバへの負荷を高めるとサークルアイコン出っぱなし現象が発生することからみて、WebDirect にはまだ問題があると思います。
　尚、小社のLAN内のWebDirect環境では、ブラウザの　＞ または ＜ 　ボタンを連続押ししても、上記の問題は発生していません。  

　以上のことから、WebDirect の導入に際しては、サーバ性能（メモリ/CPU）に加え、ネットワーク環境にも十分注意を払う必要があります。実際の運用環境にできるだけ近い環境を用意し、事前に十分なテストを行うことも必要でしょう。　またテストを行う際も精度の高いプロトタイプを用意し、十分な実行速度が確保できるかもチェックしたいところです。ブラウザ上の ＜ と ＞ （ナビボタン）を非表示にしたり、短い間隔で連続実行できないようにするなどの工夫も必要かもしれません。　導入担当者または開発者は、サークルアイコンの地雷を踏まぬよう、十分注意しましょう。

注：
「社内サーバのスペックが低すぎるのがサークルアイコンの原因だろ？」とお思いの各位、御尤もです。メモリたっぷりなサーバを調達してテストしてみたいです。　ただ、サーバ性能が低いにしても、サークルアイコン出っぱなしはオカシイと思います。

---

WebDirect のパフォーマンスに関するその他の情報

　バージョン間での WebDirect パフォーマンス比較を実際に行っている開発者は残念ながらまだ少ないようです（公式サイトの 25% 速度アップについて言及していらっしゃる方は多いでのですが）。

　そんな中、米国の FileMaker Forum ではいくつかのスレッドで WebDirect のパフォーマンスに関する情報がみつかりました。
　リンク先は英語ですが、スレッドの紹介程度に要約を載せておきます。

1. FileMaker Server 14 & WebDirect Performance

　NickLightbody という方が WebDirect 1ユーザあたりの消費メモリを計測して表にされています。
　こちらのスレッドでは、3 WebDirect ユーザ の場合は 100MB の RAM　を消費し、 30 ユーザでは 1 GB の RAM を消費することを挙げたうえで、独自の計測結果も公開されているのでとても参考になります。　すばらしい！　＼(＾o＾)／

2. FMS 14 WebDirect Performance?

　WebDirect 14にアクセスしたところ、ロード中のアイコンが出っぱなしになり、10～20 秒後にログイン画面に戻ってしまうという現象が発生。

　ちなみに、当方でも同じ現象に遭遇したことがあります。
　ホスティング会社にこの件について問い合わせたところ、FileMaker Server 13 から発生している既知の現象で、この現象が発生した場合は、FileMaker Server を再起動しないとどうにもならないとのことでした。
　また、この現象はいまのところ FileMaker Server 14 でも発生しているので、今後のアップデートが望まれるところです。　早く出さんかいヽ(`Д´)ﾉ

　その他の WebDirect 関連記事を読む

（亀）

WebDirectの導入事例を渉猟す

　WebDirect の導入に際してやはり気になるのは先行する導入事例。　
　小社でも時たま導入事例の紹介記事を探していますが、記事は多くありません。

　FileMaker 13 の WebDirect は、FileMaker Pro レイアウトのレンダリングが魅力的である反面、動作条件の厳しさ（高スペックなハードウェアの要求）、デザイン時に考慮すべき点の多さ、実行速度の問題など、機能的にはまだまだ発展途上という感じでした（これらの問題については、WebDirect 開発の勘どころ　をご参照ください。）


　そんな折、2015年5月13日に FileMaker 14 が発売になりましたが、やはり WebDirect の進化に注目が集まるっているようですね。

　ということで、小社では改めてWebDirect(WD)の導入事例を探してみました。
　以下は見つかった記事の要約、編訳となります。　

※WebDirectが2013年12月にお目見えしてから1年半。まだまだ導入事例は少ない感じです。Ver14で状況は変わるのでしょうか。

【WebDirect の導入事例】

1. Braun Electric Company, Inc. （米国カリフォルニア州）

　電設会社。
　435人以上の従業員の安全を FileMaker Go for iPad/iPhone で管理。
　SeedCode 社の GoMaps プラグインを併用し、従業員の現在地を GoogleMap で確認。

　今後は複数の業務処理の自動化に向けて、WebDirect を導入していく“予定”とのこと（予定なんで、これ、全然導入事例ではないです。GoMapsがCooｌそうなんで、思わず載せました。すみません）。

　参照元：http://www.filemaker.com/solutions/customers/stories/braun-electric-company.html　
　参考リンク：　GoMaps プラグイン（英語）

2. Annex Medical, Inc. （米国ミネソタ州）

 　医療用精密機器製造会社。
　従業員数 20人。
　社内のシステムを FileMaker Go for iPad でフル活用。
　品質記録、検品、工数管理、原料管理、在庫管理、配送、送り状作成までをトータルに行っている。

　作業効率化のためにダッシュボードをWebDirect で公開し、従業員の作業工数をチェックできるようになっている。 

　参照元：http://www.filemaker.com/solutions/customers/stories/annex-medical-inc.html

3. Cure Kids (ニュージーランド・オークランド)

　児童健康研究所。

　乳幼児突然死のリスク計算アプリを WebDirect メインで開発。

　データ入力を行うと、瞬時に死亡率のリスク計算ができるところがウリ。　
　開発期間が数週間だったにもかかわらず、ここ一年間で大きな修正はない。
　今後はカスタム開発を行い、ソリューションを完全レスポンシブな Web アプリケーションに発展させる予定（うーん、このWDソルーションはCWPソルーションに置き換わるのか。　WDで超高速開発して急場を凌だり、あるいはWDでプロトタイプを作成してエンドユーザに試用してもらう。で、本番システムはCWPで開発、みたいな）。

　参照元：http://www.teamdf.com/work/cure-kids
　開発元：http://www.teamdf.com/

---

【WebDirect 導入の具体例を示しているエンドユーザ】

1. Beko BBL　（ドイツ・ケルン）

　プロバスケットボールリーグ。
　32 人の審判と 10 人のスタッフ監督で運用中。

　全国バスケットボールリーグの所属審判を WebDirect および FileMaker Go で管理。

　（動画はドイツ語）

　
　スケジュール、評価、目標達成度、その他要素を含むすべての関連データを iPhone またはiPad で審判に公開。
　審判は、どこにいても iPhone または iPad を使い、 WebDirect　や FileMaker Go 経由でシステムにアクセスしてデータ入力可能。
　
　一元管理された目標達成やその他要素を含む情報は、リーグ管理者および審判が人選に利用。

　FileMaker プラットフォームで審判データベースを開発することにより、人材管理を実現。
　所在地情報をはじめ、年間出場試合数、身体データ、資格情報、関連情報、一般・技術審判の区分などを含む試合関連情報に関する個人データを管理。

　参照元：http://www.filemaker.com/de/solutions/customers/stories/bbl.html　

2. Akubra Hats （オーストラリア・ニューサウスウェールズ州）

　服飾品製造業。
　
　生産管理・受注管理に会計パッケージを統合させたシステムを FileMaker プラットフォームで開発。
　新たに導入されたレポート機能によって、季節ごとの商品在庫レベルを把握しやすくなり、在庫回転率が向上。
　早期受注にも対応でき、受注状況の確定も迅速化。

　システム導入後、一年間で受注レコード 2万件（受注明細レコード数 25万件、関連サイズ別レコードも含めると 56万件）を管理。
　工場および事務処理の一日 20 時間相当の業務をこのシステムで実現。
　今後のシステム最適化により、さらなる業務効率化が期待される。

　FileMaker Go と FileMaker WebDirect の併用により、モバイル顧客および遠隔顧客のニーズにも対応。
　また、2015 年の小売業者向けオンライン受注システム導入に向けて WebDirect によるモジュールをテスト運用中。


　参照元：http://www.filemaker.com/au/solutions/customers/local_stories/akubra-hats.html
　

3. サンラモン市街化区域（スペイン）

　都市開発事業。

　マドリードの民間開発区域、サンラモン市の 2000人の居住者を、18人の従業員により24時間体制で監視するシステムを運用。
　一日 3 シフト制でサンラモン市内を監視。
　訪問者・車両登録処理を含め、地域の安全を目指すのが基本目的。
　
　FileMaker Go および WebDirect によるアクセス。

　email を利用した居住者自宅訪問の実現。
　FileMaker Go for iPad を使ったレコード承認、訪問スケジュール管理
　WebDirect を使った居住者データベース管理
　
　より安全でシンプルな承認作業と堅牢なアクセス管理を実現。

　居住者に公開しているデータベースは二種類。
　居住者連絡先詳細データベースは地域事務所が WebDirect を使って更新。
　登録車両情報データベースは居住者自身が編集可能。

　訪問者がある場合は、e-mail または SMS で訪問者情報を監視員に送信。
　これにより 訪問者登録に要する時間を98% 削減。

　FileMaker Go for iPad による訪問者登録処理が可能になり、業務が簡略化されるとともにセキュリティログの記録量が 300% 増加。


　参照元：http://www.filemaker.com/es/solutions/customers/local_stories/Ciudad_San_Ramon.html

---

【WebDirect を使ったソリューションを提供している業者の開発例】

1. Contraflow （オーストラリア）

　道路交通網関連団体の計画作業と管理サービスを提供するシステムを構築。
　150人の従業員による内勤作業・オンサイト作業の両方に対応したあらゆる管理業務向けのソリューション。

　25 人の FileMaker Pro ユーザ、80人の FileMaker Go ユーザ、関連会社 5 社による WebDirect アクセスによりシステムを運用。

　【導入効果】
　コンプライアンスと安全性の向上、監査時不適合案件の減少、
　ワークフローのペーパーレス化。即時更新、各ステージの時間短縮、
　カオス化の完全排除、効率化されたプロセス、　自動 SMS 送信により電話による通話を廃止
　拠点呼び出しの時間と労力の削減、給与計算の自動化
　回転率の予測作業の迅速化と単純化、人員管理、必要車両とVIP 客の特定


参照元： http://info2.filemaker.com/Contraflow_Contraflow.html

2. SeedCode Calendar for WebDirect　（米国）

　WebDirect 対応の FileMaker Pro 向けカレンダープラグイン。
　カレンダーの週間表示、月間表示、　テーマ切替、ガントチャート表示などに対応。

（動画は英語）

　その他詳細は SeedCode 社の製品ページをご参照ください。
　SeedCode Calendar for WebDirect

弊社でも FileMaker 13 版 WebDirect 対応の在庫管理テンプレート製品『FMEasy在庫IWP/WD R1.5』を販売しております。

FMEasy在庫 IWP/WD R1.5 製品紹介ページはこちら
 
※この動画には WebDirect の動画部分は含まれていませんm( _ _ )m　インスタントWeb（IWP）の動画となっております。　14も出たことだし、WD部分の動画も作ろうか、と思う今日この頃です。
 　

　その他の WebDirect 関連記事を読む

(亀)

ポートスキャン、リモートコード実行、VoIP 攻撃

　先日、連続ネットワークアクセスのログが大量に記録されました。

　こんな感じです。


IP アドレス： 1.20.150.223 （タイ）
ポートスキャン後、連続アクセス。

IPS Prevention Alert: WEB-ATTACKS bash Access, SID: 8920, Priority: Medium -  1.20.150.223, 5313

bash Access とあるので、bash シェルの脆弱性（Shellshock）を狙った攻撃のようです。
　Unix、Linux、Mac OS X をお使いの方は注意が必要ですね。

参考：
bashに存在する「Shellshock」脆弱性についての注意喚起

　そして、この Shellshock 狙いどおり、リモートコード実行試行が10分間で 5700 回以上の連続アクセスが記録されていました。
　攻撃先のポートが 80 (http) だったので、Web サーバ狙いでしょうね。

WEB-ATTACKS Web Application Remote Code Execution 45, SID: 5617, Priority: Medium - 1.20.150.223

IP アドレス： 212.83.136.198 （フランス）

　ポートスキャン後、 連続アクセス。
　過去のレポートを見ていると、先月末からもちょこちょこアクセスしている記録がありますし、この IP アドレスは以前から悪用が報告されているようです。

参考：
AbuseIPDB.com への報告

IPS Prevention Alert: VoIP-ATTACKS SIPVicious Activity 1, SID: 5616, Priority: Medium - 212.83.136.198, 5093

　VoIP で攻撃先のポートが SIP だったので、IP 通話関係の接続確立を試みたようです。



　みなさまもお気を付けください。

ファイル起動時にFileMakerからMySQLに投げられるクエリ

FileMaker Pro をフロントエンド、MySQLを バックエンドにしたアプリを起動する時には、以下のようなクエリが投げられるんですね。　
（FileMaker Pro 13使用時）

SET NAMES utf8　［参考URL］

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, “future incoming messages from this client are in character set cp1251.” It also specifies the character set that the server should use for sending results back to the client.

A SET NAMES 'charset_name' statement is equivalent to these three statements:

SET character_set_client = charset_name;
SET character_set_results = charset_name;←A
SET character_set_connection = charset_name; 

SET character_set_results = NULL　［参考URL］

If you want the server to perform no conversion of result sets or error messages, set character_set_results to NULL or binary: 

SET SQL_AUTO_IS_NULL = 0　［参考URL］

If this variable is set to 1 (the default), then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form:

SELECT * FROM tbl_name WHERE auto_col IS NULL

If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function.

つまり、INSERT直後、 AUTO_INCREMENT値は存在するにもかかわらず、IS NULL として認識されるというもろ刃の剣。

SET AUTOCOMMIT=0　 [参考URL]

The autocommit mode. If set to 1, all changes to a table take effect immediately. If set to 0, you must use COMMIT to accept a transaction or ROLLBACK to cancel it. By default, client connections begin with autocommit set to 1. If you change autocommit mode from 0 to 1, MySQL performs an automatic COMMIT of any open transaction.

set @@sql_select_limit=DEFAULT 　［参考URL］

The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server allows per table, which depends on the server configuration and may be affected if the server build was configured with --with-big-tables. Typical default values are (2³²)–1 or (2⁶⁴)–1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.
If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.
sql_select_limit does not apply to SELECT statements executed within stored routines. It also does not apply to SELECT statements that do not produce a result set to be returned to the client. These include SELECT statements in subqueries, CREATE TABLE ... SELECT, and INSERT INTO ... SELECT.　
※うちのDEFAULTは、 (2⁶⁴)–1=18446744073709551615　でした。こんなん返されても困るわ。

SET SQL_MODE='STRICT_ALL_TABLES'　［参考URL］

For transactional tables, an error occurs for invalid or missing values in a data-change statement when either STRICT_ALL_TABLES or STRICT_TRANS_TABLES is enabled. The statement is aborted and rolled back.

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

INFORMATION_SCHEMA から、アプリで使用さているビューを含むテーブル情報を取得。

select database()

接続中のデータベース名を返す

describe `郵便番号`

当該テーブルのコラム情報を取得

SHOW KEYS FROM `easyinv15`.`郵便番号`

プライマリ等キー情報を取得、Cardinality ってここにあるのね。


SELECT TABLE NAME ～　から SHOW KEYS ～　（イタリック部）は、FileMaker ファイル内に登録されたすべてのMySQLシャドウテーブル（ビュー含む）に対して実行される（ｷﾘｯ


（土屋） 

ハードディスクの不良ブロックとメーカーサポート

Windows Server 2008 のイベントログに、イベントID:7、「デバイス \Device\Harddisk0\DR0 に不良ブロックがあります。」が記録されていることに気づいた。普段はでないのだが、毎金曜の真夜中に開始されるフルバックアップを実行する度に出ていた。

ググると、CHKDSK /F を行えとか、ディスクのプロパティを選択して、 ツール→エラーチェック を行え、とか書いてある。　CHKDISK単独ならエラーは出ない。　が、パラメータに /F　や　/R　を付けると、サーバ稼働中は実行できない旨のメッセージが出る。サーバなので、そう簡単には落すわけにはいかぬ。
ネット上には、ハードディスクに問題がある可能性があるので交換したほうが良い、という書き込みも散見された。

ということで、メーカーのDELLのサポートに電話をかけるとすぐに繋がる。　DELLはいろいろ言われているが、"サーバ"のサポートはいつも良い。　担当に現象を説明すると、原因を精査するには、以下の3つの方法（いずれもプログラム）があると言う。

1. Server Asministrator
2. DSET
3. Diagnostics

上記1と3はサーバを一旦は停止しなければならないため、 「2.DSET」（ディーセット、と読むらしい）という診断プログラムを送付してもらい、実行した。終了すると、ZIPファイルが出来上がるので、それを返送する。
夜も更けてきても電話が来ないので、こちらから電話をしてみると別の担当者が出て、送ったファイルを見てもらう。と、即「ディスクに異常がある」とのこと（ふーん、そんな簡単に解るのか！？）で、ディスク交換となった。

なにが言いたいかというと、重要なハードはやはりハード屋に任せるのが良いということ。トラブル発生時、イベントログをチェックし、CHKDSK を行い、ググる、位までのところはなんとかなる。　そこで見当をつけてHDDやらの部品を調達して交換とかも、クライアント機であればなんとかなる。が、ダウンタイムを最小限にしなければならないサーバとなると、ソフト屋には厳しい。オンサイト契約料は高いがケチってはいけないと、今日だけは改めて思ったのだった。


後日談（15/4/14追記）
ハードディスクを交換してもらって10時間位かけてリビルド、しかし上記のエラーは解消されず。
サポートにDSETを再度送ると、「（RAID1の）ディスクが両方壊れている」という。ちょっと待った！　いまさらそれは反則だ。もしそうなら、全部再インストールすることになる。　とりあえず、前回交換しなかったもう一方のドライブだけ交換してもらうことになったが、同時に不吉な記事を見つける。

Double Faults and Punctures in RAID Arrays

とっとも厭な予感。いい予感はあたったことはないが厭な予感はとっても良く当たる。
数日後メンテの人が来てもう一方のドライブを交換、当然リビルド＝10時間。で、やっぱりエラーは解消されない。　結局、一旦Windows Server Backup　を実行し、ディスクを初期化後にリストア。以後2か月強、このエラーは発生していない。


（土屋）


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

MySQL 5.1 から 5.6 にデータベースを移行する際、source コマンドを使うとエラーが発生することがある

MySQL 5.1 のデータベースのバックアップを取り、別のサーバ機の MySQL 5.6 にインストールする際、source コマンドを使ってデータベースの復元を行うと、以下のようなエラーが発生することがあります。

ERROR 1146 (42S02): Table 'test.蜃ｺ蠎ｫ' doesn't exist

この文字化けしたテーブル名は日本語表記になっており、データベースの文字コードは utf8 です。

このような場合は、source コマンドの代わりに  mysql コマンドでデータベースの復旧を試みると解決することがあります。


例：
mysql -uroot -ppassword  < test.sql


【注意点】

mysql コマンドを使って大規模データベースを復旧する際、以下のようなエラーが発生して処理が停止してしまうことがあります。

MySQL server has gone away.

これを回避するには、 my.ini（my.conf） の max_allowed_packet の数値を増やします。

max_allowed_packet = 64M
（デフォルトは 4M）

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one

The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:

Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.

1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.

	Common Model	BTHM	Remarks
Fast development	Yes	No
Ease of operation	Good	No so good
Performance for big tables	Very poor	Good
Weird behaviors	Many	Minimum
Records order	Weird	OK	Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya

『FMEasy在庫』 のバックエンドを MySQL に変える（２） ― 在庫

　本稿では、リリース予定の『FMEasy在庫 on MySQL R1.5』（仮称）の商品画面の在庫に関して説明いたします。

　以下が商品画面となります。

　『FMEasy在庫 on MySQL R1.5』では、2つの方法で在庫を算出します。
　一つは「SQL Update方式」、もう一つは「FM計算方式」です。

　それではそれぞれに関して説明します。

SQL Update方式

※特徴
　この方式は“実行”ボタンをクリックすることにより、［在庫基準日］時点の全商品の在庫数を算出して記録します（技術仕様的には、入庫数計/出庫数計/在庫数を「upd在庫」という専用テーブルに記録します）。

　一旦記録されたデータは次に“実行”ボタンを実行するまで更新されません。
したがって、“実行”ボタンクリック時点には最新情報ですが、時間が経過するに従い、最新の在庫数とは異なる可能性が高くなります。

　“実行”ボタンクリック時に入出庫データが大量にある場合、処理に数秒～数十秒、1千万件を超えるような場合は数分かかる可能性がありますが、処理が終了してしまえば即座に数値を表示・印刷できます。
　「SQL Update方式」は、在庫表などで在庫情報をリスト形式で表示・印刷する場合、高速に処理することができます。

注：
　本機能はクライアント/サーバ環境に置いて、FileMaker ServerにODBC設定がされていれば、FileMakerクライアントにはODBCのインストール/設定は不要です。

※操作方法
　実行ボタン　―　任意の［在庫基準日］を指定して本ボタンを実行すると、［在庫基準日］時点の入庫数/出庫数/在庫数が算出・記録されます。

　当方のクライアント/サーバ環境下で、入出明細レコード170万件に対してこの処理を実行すると、30秒～1分程度の時間を要します。

　作成済在庫データ選択ウインドウ（FileMaker 13使用時のみ）　―　実行ボタン右横の黄色の部分をクリックすると、小さなウインドウ（下図）が表示されます。この時、プルダウンメニューをクリックすると、他のユーザ（アカウント）が作成した在庫データの一覧が表示されるので、ここでその内の一つを選択すると、以後、「SQL Update方式」には選択したアカウントが作成した在庫データが表示されます。

他のアカウント(admin/seminar/stockchecker)が作成した在庫データを照会できる。
アカウント右側の日付は、データ作成時に指定した［在庫基準日］

注：
　各ユーザ（アカウント）は［在庫基準日］を指定して“更新”ボタンを実行することにより、全商品の在庫データを作成・記録できます。
同アカウントが次に“更新”ボタンを実行すると、前回作成した在庫データは上書きされます。例えば、admin アカウント で［在庫基準日］に「2014/11/27」と指定して本ボタンを実行すると、全商品に対して［在庫基準日］時点の在庫データが作成されますが、次に adminアカウントが「2015/12/31」を指定して同操作を実行すると、「2014/11/27」時点のデータは上書きされます。

　尚、他のアカウントが作成した在庫データは上述の通り照会することはできますが、別のアカウントで上書きすることはできません。例えば、adminアカウントでログインしている場合、seminar が作成した在庫データの照会はできても、上書きすることはできません。

FM計算方式

※特徴
　この方式は旧来のFileMakerの計算式を使用した在庫算出方法（参考記事）です。この方法のメリットは、常時最新の在庫情報を表示される点です（下記注参照）。

　ディメリットは、入出庫明細にデータが多量にある場合、在庫情報の表示に時間がかかることがある点です。 例えば、入出明細レコードが170万件あり商品Aを含むレコードがその中に2万9千件ある場合、当方の低SPECなクライアント/サーバ環境下では商品Aの［在庫数］を算出するのに5秒強程かかります。

　商品画面で個々の商品情報を一つ一つ計算・表示する場合はまだいいのですが、複数の商品の［在庫数］をリスト形式で表示する場合はかなりのストレスを感じます。

注：
　ネットワーク上の他ユーザが照会中の商品の入出庫データを追加・更新した場合、“画面更新”をクリックすると、最新の在庫情報が表示されます。

※操作方法
　計算するチェックボックス　―　チェックすると「FM計算方式」の在庫情報が表示されます。チェックを外すと在庫情報の計算を行わないので、画面表示が高速になります。

　尚、「FM計算方式」の出庫数計/入庫数計/在庫数のフィールドをレイアウト上に配置するだけで、システム起動後に初めて商品レイアウトを開く際に時間がかかります。
入出明細に170万件のレコードがある場合、当方の環境下では、1分前後の時間を要します。

　この詳しい理由については割愛しますが、簡単に言うと入出明細テーブルのビューに対して、DISTINCT句を含むクエリを発するためです。
「FM計算方式」が不要であればこれらの3フィールドはレイアウト上から削除して構いません。

　その他の在庫関連記事を読む

以上

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成

　前回の記事では、iPad のバーコード読み取りによる棚卸入力機能を実装するところまでをご紹介しました。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　棚卸作業をしてみると、システム上の在庫数と、棚卸在庫数（実在庫）が一致しない　―　誤差がでる ― ことはよくあることです。

FMEasy在庫 R1.0/R1.5 に在庫誤差調整伝票作成機能を実装する

　今回は『FMEasy在庫 R1.0/R1.5』をカスタマイズし、入庫/出庫の調整伝票を作成することにより在庫誤差調整を行う機能の作成方法をご説明します。

　前回と同様、以下の用語を使っていきます。

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

　それでは、こちらの動画をご覧いただいたあとで、実際のカスタマイズ方法をご紹介します。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 在庫誤差調整に必要なフィールドを準備

　以下のフィールドを EasyData15.fmp12（R1.0の場合、EasyData.fmp12） の商品テーブルに追加します。

　[c在庫誤差]（計算）　―　在庫誤差、誤差がある場合、調整の対象となる
　式：　If(棚卸在庫 = ""; 0; c在庫数 - 棚卸在庫)   //[棚卸在庫]が空欄(未入力)の場合、誤差は 無いものとみなす

　[c入庫数調整]（計算）　―　[c在庫誤差] がマイナスのときに、この誤差を入庫対象数とする
　式：　If(c在庫誤差  <  0; Abs(c在庫誤差); 0)

　[c出庫数調整]（計算）　―　[c在庫誤差] がプラスのときに、この誤差を出庫調整伝票の対象とする
　式：　If(c在庫誤差  > 0; c在庫誤差; 0)

　[gNo]（数値型、グローバル）　―　入庫伝票No/出庫伝票No の入出明細取込用一時記憶フィールド、後述のスクリプトで使用

2. 在庫誤差調整伝票作成スクリプトを作成

　このスクリプトの仕様は以下の通りです。

1)  在庫基準日を本日の日付（棚卸作業実施日）にする。
2)  棚卸作業を行わなかった商品は調整対象から除外する。
3) [在庫数] - [棚卸在庫] の誤差がプラスの場合は 出庫伝票、マイナスの場合は 入庫伝票 を作成する。
4) [在庫数] - [棚卸在庫] が 0 になる商品については、調整伝票を作成しない。
5) 入庫伝票/出庫伝票 の[伝票区分]は [7:在庫調整]（新設）とし、通常の伝票区分とは区別する。
6) 入出明細::備考フィールドに[棚卸担当ID]を記録。

　上記の条件に従ってスクリプトを記述すると、たとえばこのようになります。

　スクリプトの流れ上、入力チェックやウィンドウ切替などのステップも含まれていますが、基本的には上記の赤囲みの部分が押さえられていれば調整伝票を作成できるようになります。

① システム在庫を本日時点のものにする

　棚卸作業が終わった直後、つまり本日時点のシステム在庫と、棚卸在庫の差違をみるため、[在庫基準日1]　に本日の日付を設定します（Get(日付)）。

② [c入庫数調整] に値が入っている商品データを検索します。　
　このデータが入庫伝票作成対象となります。
　対象レコードがみつかった場合は、入庫伝票を新規作成し、その[入庫No]を [gNo]に一時記録します。

　次に、対象商品データを入庫明細として「入出明細」テーブルに取り込みます。
　その際、[入庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
仕入単価	→	仕入単価
JAN	→	JAN
棚卸担当ID	→	備考
c入庫数調整	→	入庫数量
gNo	→	入庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

③[c出庫数調整] に値が入っている商品データを検索します。　
　このデータが出庫伝票作成対象となります。
　対象レコードがみつかった場合は、出庫伝票を新規作成し、その[出庫No]を [gNo]に一時記録します。

　次に、対象商品データを出庫明細として「入出明細」テーブルに取り込みます。
　その際、[出庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
販売単価	→	販売単価
JAN	→	JAN
棚卸担当ID	→	備考
c出庫数調整	→	出庫数量
gNo	→	出庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

　ここまでできたら、一度スクリプトを実行してみましょう。
　調整伝票が作成されるとともに、商品の[在庫数]と[棚卸在庫]がぴったり一致していれば成功です。

【入庫調整伝票の例】

【出庫調整伝票の例】

【在庫の一致を確認（テスト段階）】

　何度かテスト実行して、問題がなければ、上記スクリプト内でコメントアウトされている[棚卸在庫]および[棚卸担当ID]の全置換クリアステップを有効にします。

　これにより、棚卸調整在庫が作成された後は、自動的に棚卸情報がクリアされますので、次回の棚卸作業時に[棚卸在庫]および[棚卸担当ID]フィールドがクリアされていないということがなくなります。

【在庫誤差調整伝票スクリプトの配置場所】

　在庫誤差調整伝票作成の実行ボタンは、ここでは商品一覧画面に配置してみます。
　赤囲みのところにご注目ください。
　[棚卸在庫]フィールドを[在庫数]フィールドの下に配置することで、調整伝票作成前に棚卸状況を確認できるようになっています。

　そして、“調整実行”ボタンをフッタ位置に配置し、ボタンクリックで調整伝票を一括作成することができます。

　“調整実行”ボタンについては、ユーザ権限による制御を追加するなど、誤操作防止策を検討してみてください。


【重要：在庫誤差調整伝票を作成するタイミング】

　システム在庫は常に変動しています。
　このため、棚卸作業開始～在庫誤差調整伝票作成完了までの間、一般ユーザによるシステムの使用や入出庫作業を禁止する必要があります。

　「禁止！」と言っているのにアクセスしてくる困ったちゃんがいる場合、FileMaker Server を停止し、サーバ上で本スクリプトを実行します。
　これにより、在庫の誤差がなくなることになります。

　なお、繰越処理（在庫や各種残高を繰り越す処理）を行っている場合、繰越処理の中に本スクリプトを組み込むのも Good！と思います。

　その他の在庫関連記事を読む

（亀）