　FileMaker って、、、あれかなぁ

2015-06-25

新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 がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

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

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

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

17:55 *.fp7 ファイルを FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
サイズが約半分ということは、転送速度が約2倍になっているといえる。
18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
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導入時の注意点

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

上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記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 関連記事を読む

（亀）

2015-06-23

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 関連記事を読む

(亀)

2015-05-15

ポートスキャン、リモートコード実行、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 通話関係の接続確立を試みたようです。

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

2015-04-14

ファイル起動時に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シャドウテーブル（ビュー含む）に対して実行される（ｷﾘｯ

（土屋）

2015-02-09

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

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

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

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

Server Asministrator
DSET
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日)

2015-02-04

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）

2015-02-03

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.
.

On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
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

2014-12-04

『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フィールドはレイアウト上から削除して構いません。

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

以上

2014-12-01

『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！と思います。

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

（亀）

2014-11-26

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

　今回は、iPadによる棚卸入力モジュールの開発方法をご紹介していきます。

FMEasy在庫 R1.0/R1.5 に棚卸入力モジュールを実装する

　ここでは弊社製品 FileMaker 在庫管理テンプレート『FMEasy在庫 IWP/WD R1.5』に沿って解説を進めていきますが、『FMEasy在庫 R1.0』を利用することもできます。

Q.　棚卸入力モジュールを使うと、倉庫の商品のバーコードを iPad で読み取って商品個数を入力するだけで、素早く、簡単に棚卸作業が進められるようになるの？

A.　（最初から期待を裏切ってしまうかもしれませんが）微妙です。
　皆様は棚卸作業の時、商品リストを印字して、倉庫に持っていき、一人が商品をカウントして読み上げ、もう一人が数量をリストに書き込む、というような作業をされいると思います。

　リスト上の商品が棚番でソートされているようであれば、カウントした商品数を素早くリストに書き込むことができ、リストに書き込んだ数値をExcelや在庫管理アプリに入力するというのも、立派なやり方と思います。

　ただ、棚番管理ができていない等の理由により、リスト紙ベースの棚卸がうまく機能していないようであれば、iPadなどの携帯端末による棚卸を検討されてはいかがでしょうか。　

　iPad/iPhoneによるバーコードスキャンは慣れが必要です。スキャンをすばやく実行できるようになれば、棚卸入力モジュールはかなり有望と思います（自画自賛＞＜）。

　それでは、以下の2つの機能に分けて、その作成方法をご説明していきます。

　1. iPad および FileMaker Go 13 のバーコード読み取り機能による棚卸入力モジュール
　2. 上記で入力した棚卸在庫数とシステム上の在庫数の誤差を修正する調整伝票作成機能

　　今回は 1. の棚卸入力モジュールにいて説明しますが、その前に少しだけ用語のご説明……

iPadによる棚卸モジュールを作成する

まずは、こちらの動画をご覧ください。

　倉庫の商品棚のバーコードを iPad で読み取り、各々の商品の個数をタッチパネルで入力している様子です。

　操作手順は以下のとおり。

画面上部の［JAN］フィールドをタップしてカメラをアクティグにする
バーコードにフォーカス。フォーカスが合うと、iPadが勝手に商品を検索してくれて、［棚卸在庫］がアクティブに。
値一覧（1～9）の数値をクリックするか、テンキーから実際の在庫数を入力。

以下、1～3 を繰り返して、各商品の［棚卸在庫］を入力していきます。

　さて、ご覧のように、バーコードは棚に貼りつけておくと、素早くスキャンできると思います。

　この動画では、私が棚卸作業をしていますが、バーコード読み取り時にカメラのフォーカスを合わせたり、数値をスムーズに入力したりするには少々コツがいります。
　慣れればかなり速くスキャンができるようになると思います。

　商品をひとつひとつ手に取り商品上のバーコードをスキャンすることもできますので、どちらが御社に適しているのか、検討してみてください。

　それでは、この棚卸作業用の画面を開発してみましょう。

1. 取扱商品の JAN コードを商品マスタに登録

　社内の取扱商品の JAN コードを商品マスタに登録しておきます。
　商品マスタへのJAN コードフィールドの配置方法と登録のしかたについては、こちらの記事をご参照ください。

　iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

2. 商品テーブルに棚卸作業用のフィールドを追加

　棚卸作業をするにあたり、以下のフィールドを EasyData15.fmp12/EasyData.fmp12 の商品テーブルに追加します。

　[棚卸担当ID]　（数値型） ―　棚卸担当の[社員ID]を入力するためのフィールド
　[棚卸在庫]（数値型） ― 倉庫棚の在庫数を入力するためのフィールド

3. JANコード検索用のフィールドを UI テーブルに追加

　棚卸用バーコードスキャン用のフィールドを EasyApp15.fmp12/EasyApp.fmp12 の UI テーブルにグローバルテキストフィールドとして追加します。

4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加

　以下の 3 つの TO を追加します。

　1) 社員_棚卸担当ID （社員テーブル）
　2) self_棚卸担当ID （商品テーブル）任意
　3) self_商品ID（商品テーブル）任意

1) [棚卸担当ID]と社員マスタのリレーション

　商品TOの[棚卸担当ID] と社員_棚卸担当ID TO の[社員ID]を関連付けます。

　2) 同じ[棚卸担当ID]が過去に棚卸処理をした商品を調べるためのリレーション

　商品 TO の [棚卸担当ID] と self_棚卸担当ID TO の [棚卸担当ID] どうしを関連づけます。

　これにより、ある担当者が過去に実行した棚卸実績を閲覧できるようになります。
　棚卸機能としては必須のリレーションではありませんが、棚卸作業もれや棚卸ミスをチェックできますので、用意しておくと便利でしょう。

　3) 棚卸実績の[商品ID]からその商品の情報に移動するためのリレーション

　上記で用意した self_棚卸担当ID TO の[商品ID] と self_商品ID TO の [商品ID] フィールドを関連づけます。

　これにより、棚卸実績の中からその商品情報に移動（照会）できるようになります。
　棚卸機能としては必須のリレーションではありませんが、棚卸作業時には、商品情報照会の操作性がアップしますので、用意しておくと便利でしょう。

5. 棚卸作業用のレイアウトを追加

　EasyApp15.fmp12/EasyApp.fmp12　のレイアウトモードで新規レイアウトを作成します。
　FileMaker Pro 13 では、下図のように視覚的にレイアウトを作成できます。

　このとき、表示するレコードは「商品」、レイアウト名は ipad 用の棚卸画面とわかる名前を指定しておきます。

　また、ここでは縦置きを前提にしたレイアウト選択を行っていますが、運用時に縦置きと横置きとでどちらが使い勝手が良くなるかを事前によく検討しておくと、後々のレイアウト調整の手間が省けます。

　あとは上記で用意した TO とリレーションを使って、[棚卸担当ID]、[棚卸在庫]、[gJAN] （スキャン用）などのフィールドを配置していきます。

　たとえば、レイアウトの加工例はこのようになります。
　最低限のユーザ入力が必要になるフィールドには赤囲みを付けておきますので、参考にしていただけると幸いです。

　図中、「タップでスキャン開始」となっているフィールドは UI TO の [gJAN] フィールドになります。
　操作では、このフィールドをタップした瞬間にバーコード読み取りモードに移り、iPad のカメラが起動させるようにします。

7. バーコード読取スクリプトを編集（または作成）

　iPad からバーコードを読み取るためのスクリプトを用意します。
　スクリプトの作成方法の詳細については、こちらの記事をご参照ください。

　iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

たとえば、バーコード読取スクリプトの編集例はこのようになります。

8. JAN コードによる商品呼出スクリプトを追加

　ユーザが UI の [gJAN] フィールドにスキャンした JAN コードを使って商品検索を行うスクリプトを作成します。

　たとえば、以下の図のようになります。

9. [gJAN] フィールドにスクリプトトリガを実装

　[gJAN] フィールドを iPad でタップした瞬間（OnObjectEnter）にバーコード読取が実行されるようにスクリプトトリガを設定します。

　また、[gJAN]へのバーコード読み取りが終了した瞬間(OnObjectSave) に JAN コード検索が実行されるようにスクリプトトリガを設定します。

　たとえば、以下のようになります。

　ここまでできたら、iPad に FileMaker Go 13 をインストールして、棚卸入力テストを行ってみてください。

　本記事の棚卸操作のような動きになれば成功です。

【棚卸実績を表示させる】

　ここでは、画面右の棚卸実績ポータルの作り方について解説します。
　ご覧のように、同じ棚卸担当者（例：土屋）が行った棚卸実績が一覧表示されていると、棚卸在庫数とチェック漏れの確認ができて便利ですね。

　棚卸実績表示用のリレーションシップの設定については、前述の「4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加」をご覧ください。

　ポータル指定の際に使うリレーションは「self_棚卸担当ID」となります。

　
　このリレーションの参照先が商品テーブルとなっていますので、[商品名]と[棚卸在庫]を配置しておけばよいでしょう。

　本稿では省略しますが、“照”ボタンをクリックすることによって、その行の商品の詳細情報を別ウィンドウで表示させたりすると、より使い勝手がよくなるでしょう。

　在庫誤差調整機能については、次回の記事でご紹介したいと思います。

　「iPadでバーコードスキャンして、棚卸表ができました！」というだけでは「で？」と突っ込まれそうなので、入力した［棚卸在庫］とシステム上の在庫数の誤差を調整伝票を発行して修正する機能もつくりました。
　続きはこちらの記事をご覧ください。

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

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

（亀）

2014-11-25

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

　『FMEasy在庫 R1.0/R1.5』ではバックエンドに FileMakerデータベースを使用しています。
　本稿では、これを MySQL 5.1或は5.6に置き換える方法の概要を説明すします。なお、本稿は『FMEasy R1.5』に沿って解説を進めていきます。

はじめに

FileMaker によるアプリで、バックエンドを FileMaker から SQLデータベース（ESS、External SQL Source）に置き換えるとき、リレーションシップのウインドウで各TOをFileMakerテーブルからESSテーブルに貼り替えるわけですが、このときリレーション、レイアウト、スクリプトおよびびセキュリティ内のフィールド等が壊れてしまいます（詳細は後述）。
　この場合、壊れた設定をひとつひとつ手動で設定し直さなければならなくなります。実に無意味で苦痛な作業を強いられるわけですが、対策が記されたサイトがみつかりました。

FileMaker, mySQL, and ESS; A Little Known Secret, to Me Anyway

　上記を要約すると、ESSテーブルに貼り替える前に、「FileMakerのテーブルを作成日順でソートし、そのソート順にESSテーブルのフィールドを並び替えた後に、FileMakerのリレーションを張り替えろ」、というもの。
　小社でこの方法をやってみましたが、うまくいきませんでした（やはりフィールドのマッピングが壊れてしまう）。もし上記のリンクの方法で「旨くいったぜ」という方がいれば、一報頂ければ望外の喜びとなります。
　ということで、以下、無意味？で苦痛なバックエンドの変更手順を解説します。

開発環境

小社における開発環境は以下のとおり。

FileMaker Pro 12/13 Advanced
FileMaker Server 12/13 Advanced
MySQL 5.1/5.6
ODBC　5.1/5.2/5.3
MySQL Workbench 5.2/6.2

MySQL5.6で使用するODBCドライバは...
外部 SQL データソースに対してサポートされている ODBC ドライバ

注：
　FileMaker 12/13 による MySQL 5.5 の使用はビューが認識されない等の問題があるため、お勧めしません。

　MySQLの管理ツールはいろいろあります。あえてMySQLコマンドラインを使うならそれも良いですが、他にも以下のようなツールがあります。
で、どれがいいの、という議論は、
Workbench, Navicat, TOAD for MySQL?

　なお、MySQL Workbench 6.2 は 5.1/5.2 に比べるとかなり良くなってる印象です。

データベース及びテーブルを作成する

ツールが決まったらスキーマ（ここでは名称を easyinv15 とする）とテーブルを作成します。このとき、テーブル名とフィールド名は、『FMEasy在庫 R1.0/1.5』のデータ用ファイル EasyData15.fmp12 のテーブル/フィールド名と合致させるようにします。
　なお、計算フィールドについてはMysqlApp.fmp15 のシャドーテーブル（後述）で作成可能ですが、パフォーマンスが劣化するのでなるべく使用しないように設計します。また、グローバルフィールド（グローバル値を持つテキスト/数値/日付/タイムスタンプ/オブジェクトの各フィールド、ここでは計算フィールドを除く）はシャドウテーブル内では作成できないため、グローバルフィールドに関連する処理は再設計が必要となります。特に在庫関連機能の再設計は面倒なので、機会を改めて述べたいと思います。

さて、スキーマ/テーブルの作成が終了したら、右図のようにODBC設定を行います。

外部データソースの変更とリレーションキーの再設定

次にFileMaker側。まず、「FMEasy在庫 R1.5」の EasyApp15.fmp12 を複製して適当な名称を付けます（ここでは、MysqlApp.fmp12）。つぎのこのファイルを開きます。［ファイル］メニュー→［管理］→［外部データソース...］を選択し、下図のように設定します（名前は EasyODBC15 とする）。このとき、もともとあったFileMakerのデータソース EasyData15 は削除しておきます。

　つぎに「リレーションシップ」タグを開くと、元の EasyData15.fmp12 のテーブルによるリレーション設定は喪失して下記の図のようになっているので、個々のTOを上記で登録した EasyODBC15 のテーブルに正しく張り直します。
　この際、元の EasyApp15.fmp12のリレーションシップ画面またはその印字物を参考にします。

この時、TO名は元のママになるよう注意します。たとえば、「入出明細_入庫」TOを選択し直すと「入出明細」になってしまうので、張り直す直前にTO名をコピーし、張り直し後に「入出明細」になったらペーストして上書きすると良いでしょう。

　なお、この張り直し後に［テーブル］タブをクリックすると、今選択したMySQLのテーブルがイタリック（斜体）で表示されます。
　これらのテーブルは（MySQLの）シャドウテーブルと呼ばれます。このシャドウテーブル内では計算フィールドを作成することができますが、他のフィールドは作成できません。MySQLテーブルのフィールドを新設/変更/削除するには、MySQLコマンドライン等の他ツールを使用する必要があります。

レイアウトのフィールド張り替え

TOを張り替えてた時点で、レイアウト上のフィールドも誤ってマップされてしまうので、各レイアウトの各フィールドを一つ一つ、張り直す必要があります　―　絶望的に退屈だけど、間違えられない作業ですね。

TO張り替え後、壊れてしまった取引先レイアウト ― 一つ一つレイアウトを開き
不正なフィールドを一つ一つ張り替えていく

スクリプトはStandardのものを開いてコピペ

次はスクリプトです。MysqlApp.fmp12内のスクリプトに設定されているフィールド名もグチャグチャになっているので、元の「FMEasy在庫 IWP/WD R1.5」の正しいスクリプトをコピって、MysqlApp.fmp12側に貼ります。
　具体的には、MysqlApp.fmp12 とともに EasyApp15.fmp12を開き、双方のファイルの「スクリプトの管理」ウインドウを開きます。次に EasyApp15.fmp12 側のスクリプトを開いて中身をすべてコピーし（Cntrl＋A → Cntrl＋C）、対応する MysqlApp.fmp12 のスクリプトを開きペーストしていきます（Cntrl＋A → Deleteキー → Cntrl＋V）。

MysqlApp.fmp12 の壊れたスクリプト。フィールドに関するステップが壊れている。
MysqlApp.fmp12側で正しいスクリプトの中身をコピーし、上図でCntrl＋A をしてスクリプトの中身を選択、
Deleteキーで削除、Cntrl＋V で正しいモノをペーストし直す。

　これを壊れてしまったすべてのスクリプトに対して繰り返し実行します。

値一覧の修正

値一覧も修正が必要になります。下図で赤枠は壊れてしまったモノです。青枠はMySQLでは数値フィールドに文字列を入力することが許容されないため修正を要するモノで、これらのフィールドがスクリプトに使用されている場合は、数値のみをセットするようにスクリプトも修正する必要があります。

その他

　「FMEasy在庫」では不要ですが、他のシステムではアクセス権限セットやカスタム関数についても修正が必要になる可能性があります。

　以上、やっていて実に虚しくなる作業ではあり、もうすこしスマートな方法があるのではないかと。

　ということで、次回は在庫算出についてご紹介します。
　FileMakerのリレーションを使用して、「FMEasy在庫 R1.0/R1.5」のように、

　　　　前回繰越在庫＋SUM(今回入庫数)－SUM(今回出庫数)

　とかやってしまう~~と、FileMakerバックエンドより時間がずーっとかかってしまうので、~~方法と、高速なMySQLの実力を発揮できそうな方法の2つをご紹介したいと思います。

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

（土屋）

2014-11-01

受注・受注残管理モジュールを作る（４）受注残の算出― FMEasy在庫のカスタマイズ

　本稿では商品毎の受注残、可用在庫等をどのように算出するかを説明します。

在庫情報タブ

商品レイアウト上にタブオブジェクトを配置します。在庫情報タブには在庫及び受注残関連フィールドを配置します。

商品テーブルに追加するフィールド

フィールド名	型	計算式	解説
繰越受注残	数字	―	繰越処理実行時に、各商品の［繰越日付］時点の［受注残］を記録。尚、繰越処理は未実装。
受注数	計算（数字）	Sum(受発注明細_商品::受注数量)	［在庫基準日］までの［受注数］計。［受注数］は受注画面上の［数量］または［受注数］
納品数	計算（数字）	Sum(入出明細_商品#納品数::出庫数量)	［在庫基準日］までの［納品数］計。［納品数］は受注画面上の“出庫移行”ボタンにより出庫登録された商品の数
受注残	計算（数字）	Case(IsEmpty(繰越情報::繰越日付) or g在庫基準日1 < 繰越情報::繰越日付;0; 繰越受注残) -納品数+受注数	［在庫基準日］の受注残（受注はしたが納品していない商品の数）
可用在庫	計算（数字）	在庫数-受注残	販売先（用途）が決まっていない自由に使用できる商品の数
gcKey1	計算（数字）	1（常に1）	入出明細レコードが受注明細と紐付されているかチェックするためのシステムフィールド。

リレーション

　上図の入出明細_商品#納品数で「gKey1≦受注明細ID」が「真」であれば、その入出明細レコード（出庫した商品）は“出庫移行”ボタンにより受注画面から出庫登録されたことになります。
　逆に「gKey1≦受注明細ID」が偽であれば、その入出明細レコードに対する受注登録がないことになります。

在庫情報の変化

さて、右図上の在庫状況において、受注画面上で［商品ID］＝1の商品明細の［移行数］に「10」を入力し“出庫移行”ボタンを実行する（右図中）と、在庫情報は右図下のように変化します。

　つまり、10 個の商品を出庫登録したのだから、［納品数］は10増えて「11」となり、［受注残］はその分減って「1」となります。

　このとき［出庫数］も 10 増えて「49」に、［在庫数］はその分減って「42」となります。

以上

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

（土屋）

2014-10-23

受注・受注残管理モジュールを作る（３）受注残タブの実装― FMEasy在庫のカスタマイズ

　本稿では受注残管理モジュールを作成します。受注レイアウトには受注品目入力用の「受注」タブと、受注残管理用の「受注残」タブを配置します。

仕上がりイメージ

受注残関連仕様

下表は上図の受注残関連オブジェクトの仕様になります。

オブジェクト	タイプ	説明
伝票区分	数値FD	レコード確定時、1:全残(納品した商品無)、2:残有（受注残の商品有）、3:過納（過剰納品した商品有）、4:完納（受注した商品を全て納品）の何れかの値がセットされる。 OnRecordCommitを使用しスクリプトを起動。尚、本フィールドを計算フィールドにすることもできるが、索引が設定できずレコードが増えるに従い検索速度が劣化してしまう。
Id	数値FD （主キー）	「受発注明細」テーブルの主キー。“出庫移行”ボタン実行時、このキーの値を移行先のテーブルである「入出明細」テーブルの［受注明細ID］に貼り付け、納品数算出用のTO（入出明細_受注#注残）の外部キーとして使用。下表及び下のリレーション図参照。
受注数	数値	＝受注タブの［数量］
納品数	計算FD(数値)	当該商品の出庫への移行数合計、下表及び下のリレーション図参照。
受注残	計算FD(数値)	受注数－納品数、本値が0以外（受注残がある）の場合、本フィールドの背面が赤くなるように条件書式を設定すと、受注残がある商品が一目で解る。
移行数	数値FD	当該商品を出庫移行する数量をユーザが指定する。
→	ボタン	上記［受注残］を［移行数］に貼りつける。
出庫移行	ボタン	各商品を［移行数］分、出庫へ移行・登録する。

FD：フィールド

EasyData15.fmp12 のテーブル定義

名称	タイプ	補足
■受注テーブ
伝票区分	数値	上表参照
■受発注明細テーブル
ID	数値(主キー)	上表参照
納品計	計算(数値)	Sum(入出明細_受注#注残::出庫数量)、上表及び下表参照
受注残	計算(数値）	上表参照
移行数	数値	上表参照
■入出明細テーブル
受注明細ID	数値(外部キー)	上表及び下表参照

EasyData15.fmp のリレーション

受発注明細テーブルに、［納品数］=Sum(入出明細_受注#注残::出庫数量)、を作成

EasyApp15.fmpの出庫移行ボタンのスクリプト

出庫移行ボタンは［移行数］で指定した数量分の商品を出庫に移行します　―　つまり、受注画面で入力されたデータの一部を出庫（出庫/入出明細テーブル）にコピーします。ポータルを含むデータを他のテーブルにコピーする場合、1.元のデータを一旦変数に格納して変数をコピー先のテーブルに貼りつける方法と、2.元のデータを格納するテーブルからコピー先のテーブルへ取り込む方法、の2つがありますが、後者の方が高速になります。

　以下は後者の方法を用いたスクリプト例です。
（当スクリプトは検証不十分です。利用は自己責任でお願いします。　m( _ _ )m）

#
#事前チェック
#
スクリプト実行 [ 「gブラウズ以外実行不可-IwpWD」 ]
スクリプト実行 [ 「gレコード無CK-IwpWD」 ]
スクリプト実行 [ 「gレコード確定強制-IwpWD」 ]
#
#受注ヘッダ情報をUIのグローバルフィールドにセット（後でUIを取り込み、出庫ヘッダを作成する前処理）
#
フィールド設定 [ UI::gCompId; 受注::得意先ID ]
フィールド設定 [ UI::gDeptId; 受注::請求部署ID ]
フィールド設定 [ UI::gPicId; 受注::担当ID ]
フィールド設定 [ UI::gTaxRate; 受注::消費税率 ]
フィールド設定 [ UI::gDate; Get(日付) ]
変数を設定 [ $oriWinName; 値:Get ( ウインドウ名 ) //スクリプトの最後でこのウインドウに戻る為、記憶する ]
#
#移行する受注明細を抽出
#
関連レコードへ移動 [ テーブル: 「受発注明細_受注」; 使用するレイアウト: 「受注明細#取込」 (受発注明細_受注) ] [ 関連レコードのみを表示; 新規ウインドウ ]
変数を設定 [ $orderNo; 値:受注::受注No ]
検索実行 [ 指定された検索条件: レコードの検索; 条件: 受発注明細_受注::受注No: 「$orderNo」 AND 受発注明細_受注::移行数量: 「>-9999999999」 ] [ 記憶する ]
#
#UI→出庫取込
#
関連レコードへ移動 [ テーブル: 「出庫」; 使用するレイアウト: 「出庫」 (出庫) ] [ 関連レコードのみを表示 ]
レコードのインポート [ ソース: 「file:EasyApp15_p」; ターゲット: 「出庫」; 方法: 追加; 文字セット: 「シフト JIS」; フィールドデータのインポート順: ソースフィールド 37 のインポート出庫::得意先ID ソースフィールド 38 のインポート出庫::請求部署ID ソースフィールド 39 のインポート出庫::担当ID ソースフィールド 40 のインポート出庫::消費税率ソースフィールド 41 のインポート出庫::出庫日 ] [ ダイアログなし ]
変数を設定 [ $shipNo; 値:出庫::出庫No ]
#
#受注明細→出庫明細を取込
#
レイアウト切り替え [ 「出庫伝票」 (入出明細_出庫) ]
レコードのインポート [ ソース: 「file:EasyApp15_p」; ターゲット: 「入出明細_出庫」; 方法: 追加; 文字セット: 「シフト JIS」; フィールドデータのインポート順: ソースフィールド 2 のインポート入出明細_出庫::商品ID ソースフィールド 3 のインポート入出明細_出庫::販売単価ソースフィールド 13 のインポート入出明細_出庫::備考ソースフィールド 14 のインポート入出明細_出庫::単位ソースフィールド 15 のインポート入出明細_出庫::受注明細ID ソースフィールド 20 のインポート入出明細_出庫::出庫数量 ] [ ダイアログなし ]
フィールド内容の全置換 [ 入出明細_出庫::出庫No; 計算で置き換える: $shipNo ] [ ダイアログなし ]
フィールド内容の全置換 [ 入出明細_出庫::入出庫日; 計算で置き換える: Get(日付) ] [ ダイアログなし ]
関連レコードへ移動 [ テーブル: 「出庫」; 使用するレイアウト: 「出庫」 (出庫) ] [ 関連レコードのみを表示 ]
ウインドウの調整 [ 収まるようにサイズ変更 ]
ウインドウを選択 [ 名前: $oriWinName; 現在のファイル ]
フィールドへ移動 [ 受発注明細_受注::移行数量 ]
#
#移行数FDはクリアしておく
#
Loop
　　Exit Loop If [ 受発注明細_受注::Id = "" ]
　　フィールド設定 [ 受発注明細_受注::移行数量; "" ]
　　ポータル内の行へ移動 [ 次の; 最後まできたら終了 ]
End Loop
レコード/検索条件確定 [ ダイアログなし ]

以上

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

（土屋）

2014-10-08

iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

FileMaker Go 13 を使ったバーコード読み取り機能について

　FileMaker Go 13 にはバーコード読み取り機能が付属しています。
　専用のバーコードリーダーをお持ちであれば、もともとデスクトップからバーコード入力できますが、バーコードリーダーをお持ちでなくても、iPhone や iPad のカメラ機能でバーコードを読み取れるようになったのは嬉しいですね。

　外回りが多い営業さんや、倉庫管理をする際にも、モバイル操作でバーコード読み取りができれば、適用範囲も広がりそうです。

　今回は、弊社製品『FMEasy在庫』をカスタマイズすることによって、iPad から商品バーコード（JAN）を読み取りながら、入庫登録ができるようにする方法をご紹介します。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
バックアップのしかたはこちらを参照
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。細心の注意を払い、ご自身の責任で行ってください。

『FMEasy在庫』に JAN 読み取り機能を追加する

　今回は、『FMEasy在庫 IWP/WD R1.5』を使って説明を進めていきますが、『FMEasy在庫 R1.0』開発版をご利用の方も、操作は同様となります。

1. 商品レイアウトに [JAN] フィールドを配置

　『FMEasy 在庫』には、[JAN] という名前の予備フィールドがあらかじめ用意されていますので、FileMaker Pro 12/13 を起動して開発者パスワードで EasyApp15.fmp12/EasyApp.fmp12 を開き、下図のように、お好みの位置に [JAN] フィールドを配置してください。

2. iPad からのJAN コード読み取り機能を商品レイアウトに追加

　iPad からから上図の[JAN]フィールドをタップしたときに、バーコード読み取り機能が走るようにします。

　スクリプトエディタを開き、「デバイスから挿入」スクリプトステップを使って[JAN]フィールドにバーコードが挿入されるように指定します。

　このとき、FileMaker Go で [JAN] フィールドをタップしたときのみ、このスクリプトが実行されるようにしますので、一行目の If 文に　PatternCount(Get ( アプリケーションバージョン ); "Go")　が指定されているところに注目してください。

　バーコードの読み取りが終わったら、次のフィールドに移動するように設計しておくと、システム運用時に使いやすくなるでしょう。

　これをスクリプトトリガとして、商品画面の [JAN] フィールドに設定します。
　イベント発生のタイミングは、OnObjectEnter （タップ時）になります。

　ここまでできたらレイアウトを保存します。

　FileMaker Go 13 で商品レコードにアクセスし、[JAN] フィールドをタップするとカメラに切り替わりますので、JAN のバーコードを読み取ると、JAN コードが登録されます。

　同じ要領で、JAN コードを商品マスタに登録していきましょう。

3. 入出明細テーブルに [JAN] フィールドを追加

　EasyData15.fmp12/EasyData.fmp12 のフィールド定義を開き、入出明細テーブルに [JAN] フィールドをテキスト型で追加します。

4. 入出明細の [JAN] から商品マスタの [商品ID]を呼び出すためのリレーションを追加

　EasyApp15.fmp12/EasyApp.fmp12 のリレーション定義を開き、「入庫レイアウト TOG」のセクションに下図のようにリレーションを追加します。

　入庫_商品#JAN TO の参照テーブルは商品テーブルです。
　商品と入出明細の [JAN] を関連づけます。

5. iPad 用の入庫管理レイアウトを作る

　EasyApp15.fmp12/EasyApp.fmp12　のレイアウトモードで新規レイアウトを作成します。

　FileMaker Pro 13 では、下図のように視覚的にレイアウトを作成できます。

　このとき、表示するレコードは「入庫」、レイアウト名は ipad 用の入庫画面とわかる名前を指定しておきます。

　また、ここでは縦置きを前提にしたレイアウト選択を行っていますが、運用時に縦置きと横置きとでどちらが使い勝手が良くなるかを事前によく検討しておくと、後々のレイアウト調整の手間が省けます。

　レイアウトのテーマや体裁はお好みで結構ですが、明細部分に [入出明細_入庫::JAN] フィールドを配置するのを忘れないようにしてください。

　たとえば、できあがったレイアウトを FileMaker Go 13 で閲覧してみると、以下のようになります。

　上図のように、[商品ID]と[JAN]フィールドは両方配置してください。

6. [JAN] のバーコード読み取りスクリプトを作り、OnObjectEnter のスクリプトトリガとして動作させる

　前述「2. iPad からのJAN コード読み取り機能を商品レイアウトに追加」と同じ操作になりますので、ここでは説明を省略します。
　
7. [商品ID]/[JAN] 相互呼び出しのスクリプトトリガを追加する

　iPad入庫画面で、[商品ID] を入力したら [JAN] を自動的に呼び出し、また[JAN]を入力したら [商品ID]を自動的に呼び出すようにスクリプトを作成します。

　『FMEasy在庫』のような分離モデルを採用したシステムの場合、レコード未確定状態ではフィールド定義のルックアップが正常に動作しないことがありますので、このスクリプトを考慮されるとよいでしょう。

備考：　[仕入単価]、[単位]の呼び出しも用意しておくとより確実でしょう。

　スクリプトができたら、iPad入庫画面の [商品ID] と [JAN] のそれぞれに、OnObjectSave のタイミングでスクリプトトリガを設定します。

　これで準備が整いました。

　以降はデモビデオで実際の操作感をご覧ください。

『FMEasy在庫』に iPad から入庫登録をするデモ動画

商品を仕入れたという前提で、iPad入庫画面で商品のバーコードを読み取って JAN コードを入力しているところです。

　JAN コードの入力のタイミングで、[商品ID] が自動入力されます。

[数量]を入力すると、制御が次の行に移ることによって[JAN] 読み取りのスタンバイ状態になりますので、連続的な操作でバーコード読み取りができます。

　実際にやってみてわかったことですが、カメラ機能のフォーカスを合せるのに少々コツがいります。
　今回は手ブレ対策として、このように鉄アレイで本体を固定してバーコード読み取りをしました。

補足：
　このような iPad スタンドを使ってみると作業しやすくなるかもしれません。
　鉄アレイに比べれば見た目もグーーーンとおシャレですし、何と言っても角度を変えられますから^^。

※『FMEasy在庫』をカスタマイズするには、開発版が必要となります。

参考記事：
FileMaker Go による iPad/iPhone 向けソリューションの開発ヒント集

『FMEasy在庫』カスタマイズ関連記事：
受注・受注残管理モジュールを作る ― FMEasy在庫のカスタマイズ (1)
受注・受注残管理モジュールを作る ― FMEasy在庫のカスタマイズ (2)

登録: 投稿 (Atom)

メニューバー

2015-06-25

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

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

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

画像について

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

ポップオーバーについて

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

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

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

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

1. FileMaker Server 14 & WebDirect Performance

2. FMS 14 WebDirect Performance?

2015-06-23

【WebDirect の導入事例】

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

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

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

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

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

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

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

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

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

2. SeedCode Calendar for WebDirect （米国）

2015-05-15

2015-04-14

SET NAMES utf8 ［参考URL］

SET character_set_results = NULL ［参考URL］

SET SQL_AUTO_IS_NULL = 0 ［参考URL］

SET AUTOCOMMIT=0 [参考URL]

set @@sql_select_limit=DEFAULT ［参考URL］

SET SQL_MODE='STRICT_ALL_TABLES' ［参考URL］

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 '郵便番号'

select database()

describe `郵便番号`

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

2015-02-09

2015-02-04

2015-02-03

Definition of terms

Problems of FileMaker's common interface

Big Table handling model in FileMaker/MySQL Environment

Common Model vs Big Table Handling Model

2014-12-04

SQL Update方式

FM計算方式

2014-12-01

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

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

2014-11-26

FMEasy在庫 R1.0/R1.5 に棚卸入力モジュールを実装する

iPadによる棚卸モジュールを作成する

2014-11-25

はじめに

開発環境

データベース及びテーブルを作成する

外部データソースの変更とリレーションキーの再設定

レイアウトのフィールド張り替え

スクリプトはStandardのものを開いてコピペ

値一覧の修正

その他

2014-11-01

在庫情報タブ

リレーション

在庫情報の変化

2014-10-23

受注残関連仕様

EasyData15.fmp12 のテーブル定義

EasyData15.fmp のリレーション

EasyApp15.fmpの出庫移行ボタンのスクリプト

2014-10-08

FileMaker Go 13 を使ったバーコード読み取り機能について

『FMEasy在庫』に JAN 読み取り機能を追加する

『FMEasy在庫』に iPad から入庫登録をするデモ動画

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

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

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

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

2. SeedCode Calendar for WebDirect　（米国）

SET NAMES utf8　［参考URL］

SET character_set_results = NULL　［参考URL］

SET SQL_AUTO_IS_NULL = 0　［参考URL］

SET AUTOCOMMIT=0　 [参考URL]

set @@sql_select_limit=DEFAULT 　［参考URL］

SET SQL_MODE='STRICT_ALL_TABLES'　［参考URL］