2013-07-25

簡単? FileMakerで在庫管理(6) ―― 場所別在庫レコードの作成方法

 ブログ記事「簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握する」では、倉庫等の場所別の在庫数算についてご紹介しました。
 今回は、同機能のキモとも言える場所別在庫レコードの作成方法についてユーザ様よりお問い合わせをいただいたので、以下にその概要をご紹介します。

場所別在庫レコードの作成方法

1.場所別在庫テーブルとそのレコードの作成方針


 先の記事で紹介した場所別在庫算出方法では、下図のような場所別在庫テーブルが必要となります。



 ここで必要十分なレコードは、在庫場所テーブルと商品テーブルのデカルト積となります。


例:
在庫場所TBのレコード
A(倉庫)
B(倉庫)
C(倉庫)

商品TBのレコード
X(商品)
Y(商品)
Z(商品)

場所別在庫TBレコード
AX
AY
AZ
BX
BY
BZ
CX
CY
CZ

 さて、場所別在庫テーブルでデカルト積となるようにレコードを生成すると、各倉庫の在庫(=[c場所別在庫数])に漏れはなくなりますが、倉庫に一度も入出庫が発生していない商品がある場合、余分なレコードが存在することになってしまいます。

 たとえば、倉庫Aにおいて商品Xは入出庫したことがあるが、商品Y、Zについては入出庫が一度も発生していない場合、AXレコードは必要ですが、AY、AZレコードは、通常は不要です。
 処理速度が遅くテーブル結合が貧弱な FileMaker では、余分なレコードを極力作成しないように設計すべきでしょう。

 ということで、今回の仕様においては、入出庫登録を行う際に場所別在庫テーブルに当該商品のレコードの登録有無をチェックして、未登録の場合のみ、レコード登録を行うようにします。


2.実装概要


◇リレーションシップ

場所別在庫_入出明細#出庫 (新設、出庫明細TBと場所別在庫TBのリンク用)
場所別在庫_入出明細#入庫 (新設、入庫明細TBと場所別在庫TBのリンク用、下図)
[このリレーションを使用して、このテーブルでのレコード作成を許可]の✔を忘れずに

◇スクリプト

g確定Btn (変更、OnRecordCommitで実行されるスクリプト)
  • 入庫/出庫画面のレコード確定(OnRecordCommit)時に、入出明細ポータルをチェックし、場所別在庫レコードが存在しなければ、同レコードを作成します。
    下図の赤いフィールドは場所別在庫_入出庫明細#入庫::在庫場所IDフィールドですが、これが空欄であるということは、[在庫場所ID]=5(座間倉庫)の当該商品の場所別在庫レコードが存在しないということを意味します。その場合は、[入庫場所ID]の値を[場所別在庫_入出庫明細#入庫::在庫場所ID]に入れ、場所別在庫レコードを作成します。
  • 本スクリプト実行時になんらかのエラーが発生した場合は、エラーが発生した旨のダイアログを表示し、ダイアログ内の“OK”ボタンでレコード確定を中止し、“レコード復帰”ボタンで明細行の作成をキャンセルするようにします。
    場所別在庫レコードの作成に失敗しているにも関わらず入出明細レコードのみ確定されると、その入庫数分の在庫はシステムから消失してしまうので注意が必要です。

3.その他

  • 万が一、関連する場所別在庫レコードがない入出明細レコードが発生した場合に備え、入庫/出庫テーブルに[c在庫場所ErrMsg]フィールドを作成し、エラーが発生した場合にのみ画面に表示する、というのは用心深い良いプラクティスと言えるでしょう。
  • 場所別在庫テーブルは巨大化しやすいので、場所別在庫が0で且つ入出庫が最近発生していない場所別在庫レコードを削除するバッチ処理を検討しておくことが望ましいです。

2013-07-24

簡単? FileMakerで在庫管理(5) ―― 倉庫間移動

 当ブログの在庫関連記事 簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握するでは、「FMEasy在庫 R1.0」をベースに倉庫などの在庫場所別に在庫数を算出する方法について概容を説明しました。

 そんな折、「FMEasy在庫 R1.0(開発版)」のユーザ様から、倉庫間移動に関するご質問を頂戴しましたので、今回はその手法をご紹介します。

商品の倉庫間移動


 まず、下図の青色で囲った部分をご覧ください。



 出庫画面に移動先を入力するための[移動先ID]フィールドを配置しています。
 倉庫間移動が発生する場合、ユーザは移動先のIDを入力した後、“倉庫移動”ボタンをクリックします。すると、出庫画面で入力した出庫明細と同内容のデータが入庫にも作成されるという流れになります。


下準備


 取引先マスタに「倉庫間移動」という管理項目を登録しておきます。
 このとき、倉庫間移動の[取引先ID]は「41」であったと仮定してみます。


倉庫移動スクリプト


 倉庫移動ボタンに割り当てるスクリプト仕様はおおまかに以下のとおりです。
  1. $moveTo 変数に移動先IDをコピー。
  2. 出庫明細(ポータル)内のすべての商品ID/出庫数を $prodArrayに変数配列として格納。
  3. 新規ウインドウで入庫レイアウトを開き、新規レコードを作成。
  4. [入庫場所ID]フィールドには変数1、[仕入先ID]フィールドには「41」を入力。同時に[入庫日]、[担当ID]、[伝票区分]にも適切な値を入力。
  5. $prodArray 変数に格納した出庫明細の要素を、入庫明細の商品ID/入庫数に展開。同時に各[在庫場所ID]には $moveTo 変数に保持されている値を設定。
  6. 入庫レコード確定。

 このスクリプトの実行結果は下図のようになります。



注:
  • 入庫明細作成時、場所別在庫テーブルに座間倉庫用の商品が登録されているかチェックし、無ければ登録する。 ここをミスると、商品がシステム上から消失してしまうので、要注意。
  • 入庫画面の[備考2]に移動元のIDと[場所名](倉庫名)を記録するとわかりやすい。
  • 取引先テーブルに各倉庫名を登録、さらに在庫場所テーブルに[取引先ID]フィールドを新設し、そこに各在庫場所に対応する[取引先ID]値を記録し、[仕入先ID]には上記「41」の代わりに、その倉庫の[取引先ID]を入力するのも良い。
  • 社内倉庫間の移動であるから、[仕入単価]は適切に処理 ― 例えば0を入力― する。
  • 倉庫が隣接しておらず、日単位のタイムラグが発生する場合、“倉庫移動”実行タイミングや[入庫日]の値を考慮すること。

2013-06-28

IIS7 でサイトページの内容の一部を自動的に書き換える方法

 Apache では、mod_layout モジュールを使ってページ内容の一部を書き換えたり、URL を変更したりすることができますが、 IIS7 単体ではできません。

 しかし、Microsoft サイトで提供されている URL 書き換えモジュール(URL Rewrite Module) を使うと、同様の操作が可能となります。

 今回は、この URL 書き換えモジュールを使って、ページの文末を書き換える方法について説明します。


1. URL Rewrite Module 2.0 をマイクロソフト公式ダウンロードサイトよりダウンロードし、IIS7 を運用中のサーバにインストールします。

Microsoft URL Rewrite Module 2.0 for IIS 7 (X64) ダウンロード
Microsoft URL Rewrite Module 2.0 for IIS 7 (X86) ダウンロード


 インターネット インフォメーション サービス (IIS) マネージャを起動すると、以下のように、URL 書き換えアイコンが表示されていればインストール成功です。



2. サーバ全体で書き換えを適用する場合は、左ペインのサーバ名をクリックしてから、URL 書き換えアイコンをダブルクリックします。

 URL 書き換えの規則を管理するウィンドウに切り替わりますので、画面下部の「HTTP 応答のヘッダーまたはコンテンツに適用される送信規則」のセクションをクリックし、次に右ペインより「規則の追加...」をクリックします。



3. 送信規則のセクションで「空の規則」が選択されていることを確認し、“OK” をクリックします。


  送信規則の編集ウィンドウに切り替わります。



4. 名前と必須条件を決めます。

 [名前(N)] に任意の名前を入力し(下図では adcode)、[必須条件(P)]の一覧より「<新しい必須条件の作成...>」を選択すると、下図のように必須条件編集ダイアログが表示されます。



 ここで、[名前] に任意の条件名を入力し(下図では bodyEnd)、[仕様] は「正規表現」が選択されていることを確認してから、“追加”ボタンをクリックすると、下図のような正規表現指定ダイアログが表示されますので、以下のように入力します。



 [条件の入力(C)] {RESPONSE_CONTENT_TYPE} (デフォルト)
 [入力文字列が次の条件を満たしているかどうかをチェック] パターンに一致する(デフォルト)
 [パターン(T)] ^text/html
 [大文字と小文字を区別しない] チェック付き(デフォルト)

 ここまで入力が終わったら、“OK” ボタンをクリックすると、必須条件の追加ダイアログに戻りますので、内容を確認してから “OK” をクリックして閉じます。



5. 書き換え用のテキストを設定します。

 画面中央の[パターン]に書き換えるタグを入力し(下図では
)、アクションのセクションでは、[アクションの種類(Y)] は「書き換え」(デフォルト)、[アクションのプロパティ]には任意の文字列を入力します。


 ここでは、ページの末尾を Powered by Tsuchiya Planning Company </body> で書き換えるという規則を指定したものです。

 ヘッダ部分を書き換えるのであれば、[パターン] を </head>、にし、[アクションのプロパティ] に任意の文字列や制御コードと記述し、</head> で閉じるようにします。
 すべての操作が終わったら、ウィンドウ右上の“適用”をクリックします。


6. ページをロードして、設定が反映されていることを確認します。

 試しに、http://localhost/iisstart.htm にアクセスしてみましょう。
 以下のように、指定した文字列がページの最後に表示されていれば成功です。




 この方法を応用すると、サイトのすべてのページにアクセス解析のトラッキングコードを自動挿入したり、ページの先頭や末尾に広告を自動挿入したりすることができます。




2013-06-05

売上猫くん Standard R5(FileMakerランタイム)からPDF出力

  『売上猫くん Standard R5』をダウンロードされた方から、「PDF出力はできないの?」といったお問い合わせを受けることがあります。FileMakerでランタイムされたシステムでは、PDF出力の機能は使用できなくなるのですが、PDF 作成ソフトを利用すると、PDF 出力が可能となります。このPDF作成ソフトでおススメなのが、PDFCreatorというフリーソフト。 フリーといえども侮ることなかれ。 小社の得意先では毎月末、千以上のPDFファイル(ページ数なら数千ページ)をPDFCreator でバッチ作成しています。 が、実行環境によっては出力できない可能性もあります。導入にあたっては、予めPDFCreatorをダウンロードし、十分テストを行うよう、お願いいたします。


【PDFCreatorによる請求書のPDF出力】

PDF Creator を使った PDF 出力


PDFCreatorは『売上猫くん Standard R5』とかFileMakerランタイムとかに関係なく、印刷コマンドを実行するソフトで利用可能(な筈)です。



(亀澤)

2013-05-14

ポータル行を削除しないバグを回避する

FileMaker にはポータル行を削除できないというバグがあり、米国のFM公式サイトではかなり以前から問題になっており、今現在もこの問題は解決されていない。


本家のスレッド
Delete portal row issue


そこで一子相伝の回避策。


  1. ポータル行となっているテーブルをピックアップ
  2. 上記でピックアップしたテーブルがレイアウト設定の[レコード表示(H):]に指定されているレイアウトを作成する。例えば、システムに売上明細、見積明細、受注明細というテーブルがあり、これらがポータルとして使用されていれば、ポータルがあるレイアウトとは別に、売上明細、見積明細、受注明細というレイアウトを用意し、その[レイアウト設定]―[レコード表示(H):]でそれぞれのテーブルを指定する。
  3. システムのスタートアップスクリプトで、上記で作成したレイアウトを開くようにする(開いた後は即刻閉じて良い)。
これによりシステムファイルを閉じなければ削除できなかったポータル行が、普通に削除できるようになる。
「言うとおりにやったが、削除できないじゃねーか!」とお怒り方がおられれば、ご一報のほど。

(土屋)

分離モデルにおけるSUM/ExecuteSQL関数の問題と対策

FileMakerの分離モデルにおいてSUMなどの集計関数を使用すると、計算結果が正しく表示されないことがある。

例:
App.fmp12(アプリファイル)とData.fmp12(データファイル、売上/売上明細テーブルを保持)があり、App側でDataにある2のテーブルを以下のようにリレートする。


◇売上テーブルの計算フィールド
SUM売上:SUM(売上明細::金額)、
SQL売上:ExecuteSQL("SELECT SUM(\"金額\") FROM \"売上明細\" WHERE " & 売上::Id & "=\"fk\"";"";"")


◇レイアウト



上図は新規の売上レコードを作成し、売上明細(ポータル)に入力しているところだが、[SUM売上]と[SQL売上]には本来「40」と表示されるべきところ、誤った値が表示される。

一方、データビューアで、上記の2つの計算フィールドで設定した式を入れてみると、ExecuteSQL側は(恐らく)常に正しい値 40 を表示するが、Sum(売上明細::金額)は正しい値を表示しない。

次にレコードをコミット(保存)してみると、下図のようにすべての4つの項目で正しい値 40 が表示される。


ということで、分離モデルでは上記に関する対策を講じなければならないが、考えられる対策は以下の通り。

  1. レコードをコミット(保存)するようにユーザを教育する。
  2. 数量、単価を変更したときには、コミットを求めるメッセージを画面に表示する。
  3. 計算フィールドの使用を避け、数値型の売上フィールドを用意。ユーザが数値、単価を変更したときには売上フィールドの値が適正に更新されるように設計を行う(スクリプトとスクリプトトリガを利用。このとき、EcecuteSQLの使用が有効と思われる)。
上記1は開発者には一番楽であるが、寛大なユーザばかりとは限らない。
上記2は実装は簡単だが、Webアプリならまだしも、デスクトップアプリ/LANアプリでユーザに操作負担を求めるのはどうか、というのはある。
最後の3の実装はかなり面倒となる。

また、数量や単価を変更したときに、毎回自動コミットするように設計するというのはあり得るが、あまりに美しくない。

ちなみに、小社でリリースしている『FMEasy在庫 R1.0』は上記2を、『売上猫くん Standard R1.0』と『売上猫くん on MySQL R5β』では上記3を採用している。



(土屋)

【関連リンク】
FileMaker の分離モデル
FileMaker の分離モデル - 2


土屋企画の講習 ― 分離モデルに基づく請求書システムを作る(対象者:中級、4時間×2日)




2013-05-12

「レコード/検索条件を開く」ステップとレコードロック


スクリプトステップの一つ、「レコード/検索条件を開く」はどういう時に使うのか?

本スクリプトステップを実行すると現在選択しているレコードをロックできる。FileMaker Ver6以前ではフィールドにカーソルを入れるだけとそのレコードはロックされ、他ユーザは更新不可となったが、7以降では仕様が変わり、フィールド値を変更するか、このステップを実行しない限り、レコードはロックされない。逆にこのステップを実行して301のエラーが返るならば、このレコードは他のユーザが既に編集していることになる。

わかりやすい用例としては、請求書印刷スクリプトの先頭部でこのステップを入れ、他のユーザが当該レコードを編集中している(エラー301が返る)のであればメッセージを表示し印刷を中止する、というのがある。
請求書印刷に限らず、レコードが他ユーザに編集されている状況でなんらかの処理を実行してしまうと不味いという状況は業務アプリではよくあるわけで、本ステップを入れた「g(eneric)競合時処理強制終了」スクリプトを用意しておき、そうした不味い状況が発生しうるすべてのスクリプトの先頭部分に g競合時処理強制終了スクリプト をかましておくことが重要となる。

また、大量のレコードをバッチ更新する場合、FileMakerでは複数行ロックやテーブルロックを行う方法がないので、「レコード/検索条件を開く」ステップを対象レコード間でループ実行させ、301が一度も返らなかった場合にのみ、実際の処理をループさせる(例えば売掛残高更新ループ)というのは一考に値すると思われる。


(土屋)

2013-05-07

売上猫くん Standard R5.0 リリースしました!

2013年5月7日、「売上猫くん Standard R5.0」をリリースしました。

売上猫くん Standard R5 のサイト

【お知らせ】
カスタマイズに関する情報をプレリリースサイトに追加しました(2013/3/22)。
iPhone 機能情報をプレリースサイトに追加しました(2013/3/11)。



土屋

2013-02-19

突然名前解決できなくなる(次回対策用私的メモ)

今朝、自分のPCを起動して社内の他のPCにアクセスしようとるすと、失敗する。
昨日まで全く問題なかったのに。

  > ping his_pc

とやると、

Ping request could not find host his_pc. Please check the name and try again.

とか返ってくる。以前も同じようなことが数回発生した記憶があるが、解決方法については明確な記憶はなく、記録もとらなかったので、例によって後悔しきり。 よって、今回は本稿に記すことにした。

で、次に

> nslookup his_pc

とやると、


Server:  internal_dns.company.jp
Address:  192.168.0.254

Name:    his_pc
Address:  192.168.0.100


と返ってくる。で、

> ping 192.168.0.100

をやると、正常に応答がある。
よって内部DNSは正しく動作しているようだ。が、前回、内部DNSのレコードが誤って記録されていて、それを修正することにより治ったような記憶が微かにあるので、念のため内部DNSを調べてみる。やはりhis_pc のレコードの内部IPは正しく登録されている。次に第3のPCから

> ping his_pc

をやると正しく応答するので、小生のPCのDNSキャッシュ(DNSリゾルバ・キャッシュ)がおかしいようだ。そこで 

> ipconfig /displaydns

をやってみると、予想に反し、his_pc に関する情報が表示されない。予想では his_pc レコードに誤った値が登録されている筈だったのだが… 本来、ipconfig /displaydns についてちゃんと調べるべきなんだろうが、今日は時間切れ、つか面倒になってきたので、エイヤ!と

> ipconfig /dnsflush

 を実行。 すると、名前解決できるようになった。
1年後、同様の現象が起こったら、その時は /displaydns やDNSリゾルバ・キャッシュをちゃんと調べようと誓うのだった。


(土屋)


参考リンク
TCP/IPの設定を確認する「ipconfig」
WindowsのDNSキャッシュをクリアする方法 ‐ CClener の新バージョンではキャッシュが見れるらしい

2013-01-29

簡単? FileMakerで在庫管理(4) ―― ExecuteSQLによる在庫数算出

 これまで FileMaker Pro による在庫算出の基本、繰越処理の考え方、複数倉庫の在庫算出方法についてご紹介してきましたが、今回は商品在庫を求める方法として、3 つのパターンをご紹介したいと思います。

在庫算出の 3 つのパターン

パターン1: FileMaker Pro で在庫算出専用の TOG を構成する方法


 弊社で配布しているシンプルな入出庫・在庫管理システム/テンプレート 「FMEasy 在庫」では、以下のようなリレーションシップを構成することによって、特定時点の商品在庫を算出しています。

ここでは |×| 以外のリレーションは無視して下さい。

※「簡単? FileMakerで在庫管理(1) ―― 在庫算出の基本」に類似リレーションの解説がありますので、参考にしてみてください。

 ユーザが商品レイアウト上の [g在庫基準日1]に任意の日付を指定すると、在庫算出開始点となる日付[g在庫基準日2]を決定します。
 [g在庫基準日2]~[g在庫基準日1]の範囲内の日付で発生した商品の[入庫数]と[出庫数]が対象となるようにリレーションシップを組み、対象となった[入庫数]、[出庫数]、および商品側の[繰越在庫数]を使って[g在庫基準日1]の在庫を求めます。

 このように考えた場合、商品テーブルの [c在庫数]の計算式は、たとえば次のようになります。

Case(IsEmpty(繰越情報::繰越日付) or g在庫基準日1 < 繰越情報::繰越日付; 導入時在庫数;繰越在庫数) - Sum(入出明細_商品::出庫数量) + Sum(入出明細_商品::入庫数量)

 この計算式は比較的単純ですが、リレーションが不細工なことと、[g在庫基準日1]や[g在庫基準日2]という管理フィールドを商品テーブルに持たせざるを得ない点には、スマートさがあまり感じられませんね。


パターン2:ExecuteSQL関数を使用する方法(JOINなし)


 FileMaker Pro 12 に新たに追加された ExecuteSQL 関数を使うことによって、商品の在庫を算出します。

 この方法を採用すると、入出庫数絞り込みのためのリレーションシップが不要となります。
 また、商品テーブルの[g在庫基準日1]フィールドおよび [g在庫基準日2]フィールドも不要となります。
 ユーザが日付を指定する[g在庫基準日1]は、ユーザインタフェース専用テーブル UI に移動してしまいましょう。



 上記のように、 入出明細TO さえあればリレーションは不要となります。単純なのがいいですね!
 それでは、商品テーブルの方に在庫算出用計算フィールド[cNoJoin在庫数]を追加し、計算式を以下のようにしてみましょう。


//$date は期間開始日、$date~ UI::g在庫基準日1 の入出庫の計を加減して在庫数を算出
Let ( 
    $date = 
      Case(
        IsEmpty(繰越情報::繰越日付) or UI::g在庫基準日1 < 繰越情報::繰越日付; Date( 1; 1; 1 );
        繰越情報::繰越日付 = UI::g在庫基準日1; 繰越情報::繰越日付 +1;
        繰越情報::繰越日付 +1
      );

    Case( IsEmpty( 繰越情報::繰越日付 )  or  UI::g在庫基準日1 < 繰越情報::繰越日付; 商品::導入時在庫数;商品::繰越在庫数 )
  - ExecuteSQL ( "SELECT SUM( \"出庫数量\" ) FROM \"入出明細\" WHERE \"商品ID\" ="  &  商品::商品ID & " AND (\ "入出庫日\" BETWEEN '" &
   GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "') "; ""; "")
  + ExecuteSQL ( "SELECT SUM( \"入庫数量\" ) FROM \"入出明細\" WHERE \"商品ID\" ="  &  商品::商品ID & " AND ( \"入出庫日\" BETWEEN '" &
   GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "') "; ""; "")

)

 ここでは $date が [g在庫基準日2]フィールドに代わって期間開始日となるため、 [g在庫基準日2]フィールドは不要となります。


パターン3:ExecuteSQL関数でJOINする方法


 最後は、ExecuteSQL に結合(LEFT JOIN)を組み込み在庫を算出する方法です。ここでは出庫テーブルと入庫テーブルを入出明細テーブルに JOINし、出庫.出庫日 と 入庫.入庫日 を WHERE 句で使用できるようにするため、入出明細テーブルの[入出庫日]も不要となります。

 パターン2と同様、配置するのは 入出明細TO のみで、リレーションは不要です。



 結合にはLEFT JOIN を使用していますが、INNER JOIN も使えます。RIGHT JOIN は FileMaker が非対応のようです。商品テーブルで商品在庫を求める計算フィールド[cSqlLeftJoin在庫数]を追加し、以下のような計算式を組み立てます。

Let (
    $date =
        Case(
            IsEmpty( 繰越情報::繰越日付 ) or UI::g在庫基準日1 < 繰越情報::繰越日付; Date( 1;1;1 );
            繰越情報::繰越日付 = 商品::g在庫基準日1; 繰越情報::繰越日付 +1;
            繰越情報::繰越日付 +1
        );

    Case( IsEmpty( 繰越情報::繰越日付 ) or UI::g在庫基準日1 < 繰越情報::繰越日付; 商品::導入時在庫数;商品::繰越在庫数 ) -

    (
        ExecuteSQL ( "SELECT SUM( \"出庫数量\" ) FROM \"入出明細\" LEFT JOIN \"出庫\" ON \"入出明細\".\"出庫No\" = \"出庫\".\"出庫No\" WHERE \"商品ID\" ="  &  商品::商品ID & " AND ( \"出庫日\" BETWEEN '" & GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "' ) "; ""; "" )
    )
    +
    ExecuteSQL ( "SELECT SUM( \"入庫数量\" ) FROM \"入出明細\" LEFT JOIN \"入庫\" ON \"入出明細\".\"入庫No\" = \"入庫\".\"入庫No\"WHERE \"商品ID\" ="  &  商品::商品ID & " AND ( \"入庫日\" BETWEEN '" & GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "' ) "; ""; "" )

)

 このように商品テーブルの[g在庫基準日1]フィールドと[g在庫基準日2]フィールド、在庫算出用のリレーションに加え、入出明細テーブルの[入出庫日]フィールドが不要となります。また、入出明細テーブルに[入出庫日]を設定するというスクリプトによる面倒な制御も不要になります。


 ExecuteSQL 関数のメリット


 ExecuteSQL を利用すると、本来不要なリレーションやグローバルフィールドを省けるため、データベースの正規化がしやすくなります。また、結合を使用すれば、スクリプトによる余分な制御も不要となります。

 ただ、実行速度的にパターン1~3 のどれが一番有利かは検証が必要です。それについては機会を改めてやりたいとは思っています。



(亀澤)

2013-01-24

FileMaker IWP (インスタントWeb公開) で一覧を表示させる方法

 前回の記事で、インスタントWeb(IWP、Instant Web Publishing)では、一度にリスト表示できるレコード件数が 25 件という制限があるため、リストレイアウトは向いていないというような内容に触れました。

 そこで今回は、FX.php と Web ビューアを使うことによって、IWP 上でリスト表示させる実行方針について紹介します。

 FX.php による検索操作方法は、FX.php のマニュアルをご覧ください。
 以下は、それ以外の部分について簡単に説明します。


1. IWPを使ったページのリロードと印刷方法の情報を流用して、FileMaker Pro レイアウト上に Web ビューアを一つ置き、検索実行用の php ファイルを指定します。

 初期状態は、以下のようにパラメータは無しで指定します。




2. 次に、レイアウト上の“検索”ボタンが実行されたら、指定条件(上記の例では[g氏名fr検])に入力された値をパラメータとして Web ビューアに渡して処理を実行するようにスクリプトを作成します。

 以下は、スクリプト内のWeb ビューアの設定で、URL へ移動するオプションを選択し、検索文字列として $str に格納された検索条件を付加しているところです。


 これにより、“検索”ボタン実行時に、上記の URL に切り替わり、指定された php ファイルの中で検索条件を取り出して FX.php で検索を行い、その結果をリスト形式で展開すれば、その結果リストを照会したり、印刷したりすることができるようになります。


3. ここまで設定し、IWP で表示を確認すると、以下のようになります。。
 ページ上のオレンジ色で示された部分が検索条件指定フィールド、ピンク色で示された部分が Web ビューア(IWP 上ではインラインフレーム)となります。



 [氏名]に「川」を入力して、“検索”ボタンを実行し、「川」を氏名に含む人物を一覧させた場合のイメージは、たとえば以下のようになります。

ご覧のように、氏名の一覧表示が可能となります。

データ作成でズボラをかましてしまいましたので、[氏名]と[ふりがな]に同じものが表示されていますが、これらのフィールドはそれぞれ別フィールドとなっております。




 ピンク色で示したインラインフレームを印刷するようにすれば、一覧をプリンタに出力することができます。


以上

(亀澤)


【IWP関連記事】

【弊社のIWP関連製品・サービス】






2013-01-17

IWP(インスタントWeb)導入の可否

 インスタントWeb(IWP、Instant Web Publishing)とは、FM社公式サイトによると「さまざまなフォームをワンクリックでWebに公開すること」。
 ワンクリックはさすがに言い過ぎと思うが、FileMakerで作成したデータベースのデータを非常に簡単にWeb公開できるのは事実だ。

 同時利用者が数十でデータの照会と検索だけでことたりるシステムであればIWPは有力な選択肢となりうるし、そのような用途であれば海外で多くの導入事例がある(後述)。
 にもかかわらず、FileMaker社(FM社)のIWPに対する立ち位置は微妙な感じ。

 試しにFMの導入事例が紹介されている日米のFM社のWebサイトの「FileMaker カスタマ・ヒストリー(FileMaker Customer Stories)」と銘打ったページを見てみると、iPadやiPhoneの導入事例は数多くあるのに対し、IWPに関する事例が非常に少なく、日本のサイトで1つ、米国のサイトで2つしか見つからなかった。
 これはFM社のIWPに対する立ち位置が微妙なるがため、と思われる。なぜか? 

 上述のように、同時アクセスユーザが数十、かつレコードの検索と照会だけであれば有用なIWPも、いったん、データの入力・更新が要求されると、多くの制約が発生してくる。

IWPの制約

「filemaker IWP」でググると、Top 10 Instant Web Publishing No-No’sなるページリンクが表示される。
 このページは「IWPの禁忌TOP10リスト」とも訳すべきページで、FileMakerではできるのにIWPでは互換性がないまたは実用に適さない機能のTOP10をリストしている。 

 以下意訳、つか編訳。
  1. 新規ウインドウは開けない
  2. 動的値一覧は使うな ― 動作しないことは無いが遅いので使わないが吉
  3. リストレイアウトは使うな ― 使えるが25行しか表示されない、なんでポータルを使おう
  4. 角が丸いオブジェクトは表示不可 - 角丸ボタンは四角で表示される
  5. 条件付書式は機能しない
  6. スクリプトトリガも機能しない
  7. ダイアログ表示のスクリプトも不可 - なんでグローバルフィールドにメッセージ表示するとか
  8. 自動保存オプションも不可
  9. Excel/Word/PDF等のファイルの挿入も不可(fx.phpを使って無理矢理サーバへファイルアップしたり
  10. レコードのインポート/エキスポートも不可
※IWPの制約については、以下のリンクも見てね
FileMaker Instant Web Publishing, Part I: Is IWP Right For You? (英語)


日本はともかく、外国はどうなん?


 上記の制約をみると、IWPの採用に二の足を踏む開発者やWeb担当者は多いと思う。
 減点法ベースの日本人は家電でもAV機器でも、機能がテンコ盛りのモノを好む。目的指向ではなく、減点指向。

 ただ、HTML、JavaScriptやPHPを1行も書かずにWebアプリを作成できる可能性を端から排除してしまうのは、開発コスト、FMクライアントライセンス費を考えるとあまりに惜しい、状況もある。
 では目的指向的、合理主義的な米国ではどうか。

 下図は「FileMaker インスタントWeb」(青)と「FileMaker Instant Web」(赤)の検索件数の比較である。
 青線が100%日本で実行されていてこれが1であるのに対して、赤線は100%米国で実行されていてこちらは23、つまり日本と米国ではIWPへの関心に極端に差があることになる。





 では実際の導入状況はどうか、ググって見た。
 URLに「"fmi/iwp"」を含むサイトを言語別/地域別で検索してみると以下のような結果となる(2013/1/22現在)。

言語別IWP導入状況
サイト言語 サイト数
日本語 220
英語 4,040
全言語 5,180
地域別IWP導入状況
地域 サイト数
日本 448
米国 2,190
全地域 5,180
注:図にはイントラネットや検索エンジン忌避対策を施しているサイトは含まれない。


 対英語比では約18倍、対米国比で約5倍(人口を考慮すると約2倍)、導入状況に差がある。

で、どういうときに使うん?

実際問題、IWPはどういうときに使えるのか。
 「アプリの性能よりも開発工数を抑え、コストを抑えることが第一」、「Webアプリを社内開発したいが、PHPやASPXの技術者を養成または雇用するのは厳しい」という方、以下を参考にしてみてはいかが。
  1. 高速なアプリを求めない
  2. IWPはFileMakerのスクリプト(実行可能スクリプトステップに上記の制限あり)でしか制御できないのため、実行速度を上げるたの作り込みができない。IWPに関する経験値が不足している場合、プロトタイプを作成して最低限の実行速度が出るかテストを行うことも必要。

  3. 高度な可用性を求めない
  4. 24時間/365日稼動みたいなシステムには使用しない。何かあったら、関連サービスを再起動できるような余裕がないと…

  5. 大規模なシステムにならない
  6. レコード数が数百万を超えるようなものは…、避けよう。

  7. Coolなユーザインタフェイスを求めない
  8. 上述のような制約があり、またJavaScriptをページに埋め込みブラウザを制御するようなこともできない(WebViewerを使うという抜け道がないこともないが…)。GoogleのようなCoolなインタフェイスを求めても無理。
 上記条件に合致し、IT責任者が今回はIWPの導入が適切と判断しても、「黙って俺について来い!」といえないような環境では、本開発の前にプロトタイプを作成して、関連部署のコンセンサスをとることも必要となるのだろう。


世界の大学や公共機関で使われるIWP

 ということで、目的合理性を解する大学、研究機関や政府・公共機関でIWPが使われていたりする。



以上

(土屋)



参考サイト:
全国90拠点、グループ社員5,000名が利用するWeb社内販売システム(日本のIWP導入事例)
Coach Source — A Fountain of Wisdom(米のIWP導入事例)
FileMaker Instant Web Publishing, Part I: Is IWP Right For You?
FileMaker Instant Web Publishing, Part II: Five Top Tips for Success



【IWP関連記事】

【弊社のIWP関連製品・サービス】

2013-01-16

FileMaker IWP (インスタントWeb公開) 上で JavaScript を使い、ページのリロードと印刷を行う方法

 FileMaker Pro/FileMaker Pro Advanced, FileMaker Server Advanced で インスタントWeb公開(Instant Web Publishing, 本記事では IWP で統一)を行うと、FileMaker Pro で開発したレイアウトをそのまま Web に公開してデータベースの更新や照会ができるようになります。

 現行で最新バージョンとなっている FileMaker 12 では、FileMaker Pro/FileMaker Pro Advanced の場合は、最大 5 ユーザまで Web での同時使用が可能となっており、これに対し、FileMaker Server Advanced の場合は最大 100 ユーザまで Web での同時使用が可能です。


 ただし、FileMaker Pro 本体に比べると、IWP には仕様上の制限があるため、開発時にそれらの制限を十分に考慮する必要があります。

 IWP でできないことは以下のとおりです。
  1. オブジェクトフィールドへのファイルのアップロード
  2. データのインポート/エクスポート
  3. FileMaker Pro のデータから PDF ファイルや Excel ファイルを作成
  4. FileMaker Pro のレポート閲覧
  5. レイアウト、レポート、スクリプト作成
  6. 警告音、メッセージポップアップ表示
  7. 印刷コマンド実行
 また、この他にもスクリプトトリガ、スクリプトステップ、条件付き書式などでも IWP に対応していない動作がありますので、FileMaker Pro 本体と IWP を併用する形でデータベースを運用する場合は、FileMaker Pro 側と Web 側での動作の違いに気を付けながら開発を進める必要があります。


 さて、今回は、上記に示した IWP の仕様制限のうち、1. オブジェクトフィールドへのファイルのアップロード、および 7. 印刷コマンド実行について対応方針を考えてみることにします。


【オブジェクトフィールドへのファイルのアップロード】

 オブジェクトフィールドそのものへファイルをアップロードする代わりに、php を使って Web サーバ上にファイルをアップロードし、そのファイルへのリンクを FX.php を使って FileMaker Pro データベースに書き込みます。

 FileMaker Pro 側の設定は、レイアウト上に以下のような Web ビューアを配置し、アップロード処理および FX.php 書込み操作を記述した php ファイルを指定します。



 php ファイルは Web サーバ上に配置してください。また、[Web ビューア内容とのインタラクションを許可] チェックボックスには必ずチェックを入れておきます。

 そのあと、IWP でデータベースを開くと、たとえば以下のようなページが表示されます。


 イメージとしては、ファイルアップロード後は、矢印が示すフィールド [FileURL] にそのファイルへのリンクを表示させるようにしたいわけですが、FX,php はバックグランドで操作されますので、ここは動的には変化しません。

 これを、JavaScript コマンドをページアップロード後に呼び出されるように組むことで、ページをリロードさせて反映させようというわけです。

 画面上に、「この部分が Parent」と表記しておりますが、Web ビューア(ピンク色)を自分自身とした場合、外のエリア(紫)が親 (parent) となりますので、JavaScript では parent に向けて処理をするようにします。



 parent.location.reload();


リロード後のイメージ



 FX.php を使った FileMaker Pro データベースへのデータ書込の話題は、以下の記事群をご覧ください。

【印刷コマンド実行】

 FileMaker Pro の印刷コマンドは、IWP では実行できません。
これでは、顧客一覧、見積書、請求書などの帳票を IWP で印刷したいときに不具合があります。

 この対策として、上記のファイルアップロード例と同じ要領で Web ビューアを配置し、印刷ボタンを配置したページを指定します。





 ファイルには、フォームの 印刷ボタンをクリックすると、JavaScript で以下のような関数を呼び出し、 parent ページを印刷するようにします。



function reportprint()
{
parent.focus();
parent.print();

}



 これにより、Web ブラウザの印刷ダイアログが表示されます。



 上図のように、印刷ボタンの部分もページとして印刷されてしまいますので、Web ビューアを配置する場所は 2 ページ目の先頭あたりにくるようにし、印刷時は 1 ページ目を選択するようにすると都合が良いでしょう。

以上

(亀澤)



【IWP関連記事】

【弊社のIWP関連製品・サービス】




2012-12-20

簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握する

 弊社では在庫管理システムの講習を行っていますが、時折「うちは在庫の保管場所が複数あるので、保管場所毎に在庫を管理したいのだが、おたくの講習は対応できる?」との問い合わせを受けることがあります。 

 実のところ、複数の在庫場所に対応した在庫管理システムの構築は難度が上がってしまうのですが、なんとかコアの部分だけでも本記事でご説明させていただきます。

倉庫など場所別に在庫数を把握する


 ここでは、『FMEasy在庫 R1.0』で複数の在庫場所を管理できるように、仕様変更してみることにします。
 これまでに弊社の在庫管理講習を受講された方、または『FMEasy在庫R1.0(開発版)』ユーザ、倉庫別在庫管理の考え方を学びたい方の参考になれば幸いです。

  1. テーブル設計
    1. 在庫場所テーブル (新設、倉庫/保管場所等管理用マスタ)
      • ID(主キー)
      • 場所名(テキスト)
    2. 場所別在庫TB(新設)
      • ID(主キー)
      • 場所ID(外部キー)
      • 商品ID(外部キー)
      • 導入時在庫数(数値、導入時に元々あった商品在庫数を在庫場所別に記録)
      • 繰越在庫数(数値、繰越処理実行時に特定時点の商品在庫数を在庫場所別に記録)
      • c場所別在庫数(場所別在庫算出用計算フィールド)
      • g在庫基準日1/g在庫基準日2(入出庫の期間特定用グローバルフィールド)
    3. 入庫テーブル/出庫テーブル(変更)
      • 入庫場所ID/出庫場所ID(新設、入出庫場所を登録)
    4. 入出明細TB(変更)
      • 在庫場所ID(新設、入庫テーブル/出庫テーブルの入庫場所ID/出庫場所IDをコピーする)

  2. リレーションシップ設計

  3. レイアウト(LAY)/スクリプト設計
    1. 在庫場所LAY(新設、場所別の在庫数をポータルに表示)
    2. 入庫LAY/出庫LAY(変更)
      • 入庫場所ID/出庫場所IDを配置する
      • OnRecordCommitで入庫場所ID/出庫場所IDを入出明細テーブルの在庫場所IDフィールドにコピー
      • OnRecordCommit時、必要に応じて場所別在庫レコードを作成(4-a参照)

  4. 考慮すべき事項
    1. 場所別在庫レコードを作成するタイミング
    2. 複数倉庫がある等、場所別に在庫を管理しようとすると、FileMakerの場合、どうしても場所別に商品を登録しておく専用テーブル(場所在庫テーブル)が必要になる。そこで、場所別在庫レコードを登録するタイミングが問題となる。余分なレコードをテーブルに極力保持しないためには、入出庫レコード登録時(OnRecordCommit)に、未登録商品の場所別在庫レコードを登録するように制御する。 
    1. 倉庫間移動に対応
      • 出庫時、倉庫1の出庫伝票を、入庫時、倉庫2の入庫伝票を作成
      • 倉庫2の入庫伝票作成漏れを防ぐ
      • 倉庫2の入庫伝票作成後の関連伝票更新をどう考えるか?
    2. 出入庫同時作成機能(商品の近接場所間移動時)
    3. その他


リレーションシップ


 まず、テーブルでキモとなるのが場所別在庫テーブルですね。このテーブルにより、場所別に商品在庫数の算出が可能となります。
 ここで特に重要なフィールドは、在庫場所ID、商品ID、c場所別在庫数(計算フィールド)です。なお、下図で場所名と商品名は商品テーブルと在庫場所テーブルを参照しています。

【場所別在庫テーブルを表形式レイアウトに表示】



在庫算出部分のリレーション。

↓ 


 入出明細テーブルには商品ID/在庫場所ID(出庫元/入庫先の在庫場所ID)と入出庫数が登録されているわけだから、入出明細テーブルと場所別商品在庫テーブル上記のようにリレートして、以下のように計算式フィールをを作ればよいでしょう。 

元々ある在庫+特定期間のSum(入庫数)-特定期間のSum(出庫数)

注:
 「元々ある在庫」は繰越処理が未実行であれば[導入時在庫数]、実行済であれば[繰越在庫数]となり、「特定期間」はユーザが指定する[g在庫基準日1]と、[g在庫基準日1]のOnObjectValidate/Saveで起動するスクリプトにより制御された[g在庫基準日2]の値により決まります。
 [g在庫基準日2]の設定値については、「簡単? FileMakerで在庫管理(2)」の図が参考になると思います。

 他にもリレーションシップの追加はあるのですが、難しくないので省略します。


レイアウトとスクリプト


 入庫/出庫レイアウトには、それぞれのテーブルで新設した[入庫場所ID]と[出庫場所ID](入出庫した場所を示すID)を登録し、OnRecordCommit時に入出庫明細テーブルの[在庫場所ID]にコピーします。
 なお、Commit時に、入出明細テーブルに入力されている[商品ID]で場所別在庫テーブルに未登録の商品は登録するという、第2のキモともいうべきスクリプトについては、できれば機会を改めて書きたいと思います。

【出庫レイアウト】


 最後に在庫場所別に商品在庫数を表示するレイアウト。ユーザが[在庫基準日]に日付入力することにより、その日付時点の各商品の在庫数が表示されます。


【在庫場所レイアウト】

ポータル部分に在庫数(=場所別在庫::c場所別在庫数)と商品テーブルの情報が表示されます。
以上、『FMEasy在庫』というテンプレートをベースにカスタマイズしてみましたが、半日強の時間でとりあえず場所別在庫数は表示できるようになりました。
 上述の場所別在庫のレコード作成処理や、繰越処理は別途作成しなければなりませんが、意外と実装に時間はかかりませんでした。


 (土屋)

2012-11-08

SQL Server 2000 を FileMaker 11で使う

 FileMakerが公式サポートしているMicrosoft SQL Server のバージョンはMS SQL Server 2008 R2/MS SQL Server 2008 SP2/MS SQL Server 2005 SP3のみです。

 が、10年程前に SQL Server 2000 と ASP で作成したシステムのデータをちょこちょこ弄る必要がでてきました。
 これを Active Server Page でやるのは大変すぎるので、FileMaker Pro 11でSQL-Server 2000のDBを扱えないものかと無謀にも思い立ち、試してみました。

 本記事は、その備忘録となります。

 例によって「システムDSN」を登録。
 環境は Windows 32bit、ODBCドライバは「SQL Server 6.00」。
 問題なく登録できる。



 次に FileMaker Pro 11 Advanced を起動してFileMakerデータベースを作成。
 上記で登録したDSNをFileMakerの外部データソースとして登録する。



 さらに、リレーションシップのウインドウで、上記で登録した SQL Server データベースのテーブルをTO(Table Occurrence)として現出させ、リレーションとかもしてみる。問題なし。



 FileMaker では TO 毎にレイアウト(フォーム)が自動作成される。ブラウズモードにして、表示方法を「表形式」を選択すると、以下のような表が表示される。



 ここまで、慣れていれば5分程度で作成できる。
 いまのところ、照会/検索は普通にできている。



 最後に躓いた点のメモ:

 上記のFileMakerデータベースを Windows Server 2008 x64 の FileMaker Server で運用する場合、普通にDSN登録をすると、上記のリレーションシップのところでエラーが起こると思われる。
 この場合、SysWoW64フォルダの odbcad32.exeを起動して、DSN登録を行うこと。

参考リンク


(土屋)


【IWP関連記事】

【弊社のIWP関連製品・サービス】


2012-07-18

QNAP障害発生時のマイグレーション

今回発生したQNAPの障害を機に、ハードディスクではなく、QNAP本体で障害が発生した場合のマイグレーション(Migration)をシミュレートしてみた。 ここでいうマイグレーションとは、障害が発生した元QNAPのハードディスクを新QNAPに移動し以後QNAP2で運用することを言う。
以下、今回行ったシミュレーションの手順・注意点を記録しておく。

1.障害はハードディスクかQNAP本体かを見分ける
ハードディスクの障害であればマイグレートしてもしかたがない、というか余計症状が悪化する可能性もある。ハードディスク障害の症状、チェック方法、復旧方法については、以下を参照。

QNAPで恐怖のエラーがぁぁぁぁああああ

本体のHDDのLEDが赤く点滅していればHDD障害の可能性大。LEDが緑(点滅)であっても、PCからアクセスできない、ブラウザからQNAP管理画面の左ペインの(いくつかの)リンクにアクセスしようとすると「Loading Driver Please Wait... 」と表示されたままになりアクセス不能、RAID情報を見ると理由もないのに「Sychronizing...」していてHDDのLEDが緑点滅している、という状況があればHDDが疑わしい。

今回のようにHDDが中途半端に生きている場合、「Sychronizing...」(十数時間)→アクセス障害→手動再起動→アクセス復旧→「Sychronizing...」(十数時間)→アクセス障害→手動再起動… をHDDが完全に死んでLEDが赤点灯するまで何十時間も繰り返すことがあるので、障害原因がハードディスクかQNAP本体かをいかに早く見極めるかが、腕の見せ所。



3.事前確認
今回のシミュレーションでは、「元QNAP(いままで運用中のQNAP)本体が障害を起こしたと仮定し、元QNAPの4台のHDDを新しいQNAPに移し(マイグレーション)、ネットワーク上のマシンから問題なくアクセスできることを確認、その後4つのHDDを元QNAPに戻して運用を再開する」という一連の作業を行う。 かなり不安な作業なので、QNAPサポートにこれを実行して問題ないかを問い合わせたところ、「問題ない筈だが、マイグレーションに関する以下のURLを読んでみろ」とのこと。

曰く、「After the migration has finished, all the settings and data will be kept and applied to the new NAS. However, the system settings of the source NAS cannot be imported to the destination NAS via “System Administration” > “Backup/Restore Settings”. Configure the NAS again if the settings were lost.」
つまり、元QNAPの設定とデータは新しいQNAPに継承される。が、“System Administration” > “Backup/Restore Settings”を利用しても、元の設定を取り込めないこともあるので、その時は手動で設定してね、と怖いことが書いてある。 元QNAPで行った設定はすべてスクリーンショットを取っておき、万が一の場合は手動設定する準備をしておく必要がある。


4.元QNAPのファームウェアのアップグレード
実際にQNAP本体に障害発生した場合、ファームのアップグレードはできないが、今回はシミュレーションなので、マイグレーション前に元QNAP機のファームをアップグレードした。 

まず、アップグレード前にファームの更新履歴をみて、アップグレードの可否の判断を行う。 QNAPファームは頻繁にアップグレードされバグも多いようなので、この判断は慎重に行うこと。 今回は3.5.0→3.7.1へとアップグレードを行った。

アップグレードに要した時間は10分程度だったか。終了後は再起動を求めてきたので再起動。 ところが、再起動後にまた「Synchironizing...」が始まった。 これに要した時間が10時間強。QNAPのサポートにこの件を問い合わせたが、「通常、Synchironizeはそうそう起こるものではない。今回の原因はわからない」とのことだった。


5.マイグレーション、そして再度元のQNAPへ戻す
10時間強のSynchronizeが終わったところで、元QNAPの電源を落とし4台のHDDを抜き取り、新QNAPに移して電源をいれた。 数分で問題なく起動してきた。これでマイグレーション作業は終了。
ところがログをチェックしてみると、「The firmware versions of the system built-in flash (3.4.2 Build 0331T) and the hard drive (3.4.2 Build 20120615) are not consistent. It is recommended to update the firmware again for higher system stability.」と出ている。ファームウェアは、ハードディスクと本体フラッシュメモリの両方にあるらしい。マイグレーション先の新QNAPのフラッシュ内のファームが古いというのは当然だが、元QNAP内にあった4台のハードディスクのファームが3.4.2というのはおかしい。


一方、“Firmware Update”のリンク をクリックすると、「Current firmware version: 3.7.1 Build 20120615」と表示される。 よってthe hard drive (3.4.2 Build 20120615) の表記はバグと思われる。

今回はシミュレーションなので新QNAPでのファームのアップグレードは見送り、この状態でブラウザのQNAP管理画面からチェックをおこなった。IPアドレス、その他は旧QNAPの設定がそのまま継承され、マシン名も旧QNAPと同様である。その他の設定も旧設定をそのまま継承している。ここで、旧QNAPを使用していた仮想/物理マシンを起動してみたが、問題なくアクセスできた。

一通りチェックが終わったところで、新QNAPの電源を落とし、4つのハードディスクを新QNAPから取り出し、元QNAPに戻した。 されに元QNAPの電源を入れてログをチェック。 問題がないことを確認後、各マシンから再びアクセスをさせたところ、問題なく動作した。

(土屋)







2012-07-12

ターミナルエミュレータを使って QNAP の状態を確認する

先日の QNAP の不具合でわかったことですが、QNAP 本体にトラブルが発生すると、Web ブラウザによる管理ツールで使えない部分が出てくることがあります。

たとえば、RAID 構成を表示させるページや、ISCSI の構成を表示させるページ等は読み込み中のまま、まともに動かなくなってしまったりします。

そういった場合に、エラーの発生したディスクカートリッジを交換したり修理に出したりする前に、直接 QNAP の OS にアクセスして状態の確認やログ参照を行うことにより、原因を特定しやすくなるかもしれません。

ここでは、PuTTY というターミナルエミュレータを使うことによって、QNAP にログインし、基本的なステータス確認コマンドを走らせる方法について説明します。

1. PuTTY のダウンロード

以下のページにアクセスし、適切なバージョンの PuTTY をダウンロードします。


PuTTY は実行ファイル単体で動作しますので、Windows ユーザの方は putty.exe をダウンロードすればまず問題ないでしょう。

2. PuTTY の起動

putty.exe を起動すると、PuTTY Configuration という画面が表示されます。


上図の青囲みのように Host Name に QNAP の IP アドレス、ポートに 22 (SSH) を指定してから、“Open”ボタンをクリックします。

3. QNAP へのログイン

接続に成功すると、以下のようなPuTTY のターミナル画面が開きます。



 ログインを求められますので、admin を指定し、正しいパスワードを入力して Enter キーを押します。


4. mdstat でメディアの状態をチェック

以下のコマンド入力して Enter キーを押すと、現在のメディアの状態を確認できます。

cat /proc/mdstat 




上記の黄色囲みに注目してください。
UUU_ と文字が並んでいますが、4 文字目がアンダースコア _ になってしまっています。
これは、4 番目のメディアに何らかの障害が発生しているため、mdstat では読み取り不能であることを示しています。

つまり、QNAP の 4 番目のディスクカートリッジに障害が起こっていることがこれでわかります。

6. klogd.sh dump でさらに状態を詳しくチェック

以下のコマンド入力して Enter キーを押すと、カーネルログデーモンで発生しているイベントのログを照会できます。

/etc/init.d/klogd.sh dump 

しかし、これではすべてのログが表示されてしまいますので、後尾に grep を付けてキーワードの絞り込みをすると場所の特定が容易になるでしょう。


たとえば、入出力のエラーを確認したいときは以下のように入力します。

/etc/init.d/klogd.sh dump | grep "I/O error"




I/O error ログのみが抽出されます。
上記の黄色囲みの部分を確認すると、sdd デバイスに入出力エラーが発生していることがわかりますね。


【補足】

メディア名をコマンドでチェックするには、以下のコマンドを入力します。

ls /dev/sdd*



sdd、sdd1、sdd2、sdd3、sdd4 とメディア名が定義されており、最初から順に QNAP のカートリッジと対応しています。上記 4. の mdstat で説明したとおり、今回は4 番目のデバイス sdd3 (QNAP 本体では物理的に 4 番目のカートリッジ)に障害が起こっています。

また、sdd4 は物理的には存在していないデバイスとして定義されているようですが、この部分は当方は未確認です。



その他、QNAP の不具合に関して具体的なサポートを受けたい方は、以下にお問い合わせください。


QNAP HELP DESK (問い合わせは英語)


2012-07-11

QNAPで恐怖のエラーがぁぁぁぁああああ

知人のQNAPはiSCSIを構成しており、Hyper-Vの仮想マシンと物理マシンがそのiSCSIボリュームを使用している。 ある朝突然、それらのiSCSIボリュームにアクセスできなくなったと言う。「Hyper-Vマネージャー」を起動してみてみると、「仮想マシン」の一覧に表示されるマシンのいくつかに「一時停止 - 重大」と表示されている。 これらのマシンはみなiSCSIボリュームを使用しているものだ。
ブラウザでQNAPのシステムログを見ようとしても「Loading data. Please wait...」と出てくきて、先へ進めない。 仕方がないのでブラウザからQNAPを再起動しようと試みるもいつまでたってもシャットダウンしない。 またまた仕方がないので、QNAP本体の“POWER”ボタンを長押しして無理やり電源を落とす。次に再度“POWER”ボタンを押して起動を試みるも、

「SYSTEM BOOTING」

が本体ディスプレーに表示されたまま、10分ほど経っても起動してこない。「qnap system booting」や「qnap system booting forever」でググってみると、「ハードの故障だ」とか「PSU(Power Supply Unit)だ」とか面倒そうなことが一杯書いてあり、気分が悪くなってくる。 さらに仕方がないので、“POWER”ボタンを2回押して再起動。やはり、「SYSTEM BOOTING」が出てきて、起動してきそうもない。 上記の記事を丹念に読み始める。 どうみても簡単に直りそうもない、と絶望的な気分に陥りそうになったところで、チラっと本体のディスプレーを見ると、なんと!「SYSTEM STARTING...」(だっけな?)みたいなのが表示されており、狂喜する。 しばらくすると、ディスプレーからメッセージが消え、PINGも返るようになる、ブラウザからもアクセスでき、最後にiSCSIボリュームも復活して、Hyper-VのクライアントOSからもそれらを利用できるようになった。

それでログを見てみると、「[RAID6 Disk Volume: Drive 1 2 3 4] The file system is not clean. It is suggested that you run "check disk".」と表示されている。さらに「RAID MANAGEMENT」をクリックしてみると、「Synchronizing (0%)」と表示されている。 ところがこのSynchronizingが遅々として進まず。15時間が経過した午前2時過ぎに97%と表示され、この時点でiSCSIボリュームが再度使用不能になっていることに気づく。 この期に及んで、いくら待ってもSynchronizingは成功しそうにないことにやっと気づくが、とりあえず、朝までSynchronizeを走らせることにして就寝。 翌朝見てみるとやはりSynchronizingは97%のままで終わっていない。 24時間が経過しようとしてもまだ終わらない。


諦め気分でふとQNAP本体を見ると、4つの目のHDDのLEDが緑点滅から赤点灯に変わっている。
「RAID Management」の 「Current Disk Volume Configuration」 は、"RAID 6 Disk Volume: Drive 1 2 3"を示し、第4ドライブが表示されていない。24時間かかって、「やっぱりハードディスクか」とかなり確信を持つ。 念のため、今回の現象をQNAPのサポートにメールしてみると、「問題のハードディスクを取り外して、もう一度入れてみろ」というので、その通りにする。すると、本体のSTATUSが赤く点滅し、第4ドライブのLEDは緑に点灯。 以下のようなログが表示された。


2012-07-1016:13:11System127.0.0.1localhost[RAID6 Disk Volume: Drive 1 2 3 4] RAID device in degraded mode.
2012-07-1016:13:09System127.0.0.1localhost[RAID6 Disk Volume: Drive 1 2 3 4] Drive 4 removed.
2012-07-1016:12:59System127.0.0.1localhostDrive 4 plugged out.


Drive 1 2 3 のSynchronizing が無事終了するまでにさらに10時間程が経過。以下のような状態になった。

Current Disk Volume Configuration : Physical Disks
DiskModelCapacityStatusBad Blocks ScanSMART Information
Drive 1Hitachi HDS722020ALA330 JKAO1863.02 GBReadySCAN NOWGOOD
Drive 2Hitachi HDS722020ALA330 JKAO1863.02 GBReadySCAN NOWGOOD
Drive 3Hitachi HDS722020ALA330 JKAO1863.02 GBReadySCAN NOWGOOD
Drive 4Hitachi HDS722020ALA330 JKAO1863.02 GBDisk Read/Write ErrorSCAN NOWGOOD

Note that if you are going to install a hard drive (new or used) which has never been installed on the NAS before, the hard drive will be formatted and partitioned automatically and all the disk data will be cleared.

Current Disk Volume Configuration : Logical Volumes
Disk/ VolumeFile SystemTotal SizeFree SizeStatus
RAID 6 Disk Volume: Drive 1 2 3EXT43664.62 GB3023.18 GBIn degraded mode


かくしてディスク交換の止む無きに至り、Amazonから Segate ST2000VX000 を注文、待つこと2日でブツが到着。 いそいそとDirve 4を抜く。
Drive4を抜いた状態

調達した新ドライブをいれると、Rebuildが始まった。

15時間後、Rebuild無事終了。


【メモ】
  1. ディスクが中途半端に壊れると、その壊れかかったディスクを使用して、Synchronizeを行おうとする。 このSynchronizeはQNAPが完全にそのディスクが壊れていると認識できるまで、続行する。 問題は、この Synchronizeの過程で、iSCSIほかのサービスが異常中断し、ブラウザのQNAP管理画面からも、アクセスできない機能があること。
  2. 今回は原因特定に時間がかかり過ぎた。次回、HDDの障害が疑われる場合(の一案)→ cat /proc/mdstat を実行して障害HDDを特定→QNAPの電源を落とし障害HDDを抜き再起動→Synchronizingが実行される(十数時間)→新HDDを入れてRebuildする。
  3. SSHによるRAID状態チェック→こちら
  4. QNAPが完全にそのディスクが壊れていると認識した時点でSynchronizeは中断し、当該HDDのLEDには赤が点灯とする。このディスクが少ない状態(今回は4→3に減った状態)で、再度Synchronizeが実行される。
  5. HDD交換時は→ QNAP互換HDDリスト
  6. コンパクトで省エネ、比較的お手軽に導入できるQNAPのiSCSI。 が、一旦障害が発生すると復旧はかなり面倒になることも。 ググると、障害対応で苦労しているユーザが一杯いる。ただ、ここ(本社)のサポートはかなり秀逸だったりする。  Danny、謝謝。 

土屋