どんなWebアプリケーションでもエラー処理は重要だ。データベース側の処理をおこなう場合、かならず例外処理のことを考えてコードを書く。データベースにFileMakerを採用し、FX.phpを使用しているWebアプリケーションの場合はfoundCountやerrorCode、fxError、lastErrorCodeといった返り値をもとにエラー処理を実装することになる。

Webアプリケーションの開発中、このエラー処理を記述しているときに思わぬところでバグがでやすい。ご存知のとおり、FileMakerでは「レイアウト」や「テーブルオカレンス(TO)」といった独特の考え方がある。たとえばあるテーブルのあるフィールドにたいして-edit処理をおこないたいという場合「変更したいフィールドが指定したレイアウトに配置されていること」が条件になる。なにを今さら、な内容だが基礎中の基礎だけにトラブルのときに見過ごしやすい箇所のひとつだ。

FileMaker Webアプリの開発中、とくに発現しやすいFileMakerエラーとその対応策をまとめた。デバッグ時の参考にしてほしい。

FileMakerエラーコード エラー内容/デバッグのポイント
101 レコードが見つからない。-recidの値が違うか、間違ったテーブルに処理をおこなおうとする場合に発生(-find, -edit, -delete)。401と混同しやすいため注意
102 フィールドが見つからない。フィールドのスペリングミスか、指定したレイアウトにフィールドを配置し忘れている。関連レコードの場合、TO名も完全に一致している必要があるので要確認
104 スクリプトが見つからない。指定したスクリプトのスペリングミスや、ほかのファイルを参照してしまっている
105 レイアウトが見つからない。指定したレイアウトのスペリングミスや、ほかのファイルを参照してしまっている
201 フィールドを変更できない。計算フィールド・集計フィールドにたいして編集処理をおこなおうとしている場合に発生
301 別のユーザがレコードを使用中。Webアプリケーションのみの場合はその特性から発生しにくい。FileMaker ProクライアントとWebアプリケーションの2つのUIを持つ場合は、あらかじめ排他処理をおこなっておくなどの対策が必要
306 レコード修正IDが一致しない。正常処理でこのエラーが返るほか、Ajaxでレコードを編集した場合に戻り値の修正IDを格納忘れで起きる場合も
401 検索条件に一致するレコードがない。ユーザ側が入力する検索条件でもこのエラーが発生するため、トラブル時は切り分けがしにくい(-find)。101と混同しやすいため注意
500 日付の値が入力値の制限を満たしていない。FileMaker内部では日付を「MM/DD/YYYY」形式であつかうため、レコード編集時にもこの形式でリクエストをおこなう必要がある
802 ファイルを開くことができない。FileMakerファイルがFileMaker Server上にて公開・開かれているかを確認する。開いても途中で勝手に閉じてしまう場合は、ファイルの修復を実施してみる
951 予期しないエラー。もっとも切り分けがしにくいエラーのひとつ(FileMaker Pro 6以前では高負荷がかかった場合に発生しやすかった)
958 引数が見つからない。-editや-delete時に-recidが指定されていないことが原因となっている場合がおおい
959 FileMaker Proエラーコードに記載されていないエラー。Filemaker API for PHPを使用している場合、FileMaker Server側で「PHP公開」が有効になっているかを確認

とくに注意しておきたいのは100番台、401、500エラーだ。POSTされた内容をforeachでAddDBParam()で格納していたり、AddDBParamArray()で格納しているとこれらのエラーはなかなか切り分けができなくなる。返り値のURLやlastURLを解析しつつ、今回紹介したエラーコード早見表を参考にしてほしい。

ほんの数行で強力デバッグ! トラブル時のおともに - FX_Fuzzy_Debugger

FX.phpにはバージョン4.5以降、FX_Fuzzy_Debuggerと呼ばれる機能が用意されている。FXによるFileMakerへのリクエストが実行される前にDEBUG_FUZZYを定義しておくだけで、デバッグ用のメッセージが格納・表示されるという優れものだ。トラブル時にも迅速な切り分け処理ができるようになるため、ぜひ使いこなせるようになっておきたい。FX_Fuzzy_Debuggerの活用例は次のとおり。

PHPファイル - fm_fuzzydebug.php

<?php

define('DEBUG_FUZZY', true);

include_once('./fx/FX.php');
include_once('./fx/server_data.php');

$data = new FX($serverIP, $webCompanionPort, $dataSourceType, $scheme);
$data->SetDBData($databaseFileName,'fuzzyTest', 1);
$data->SetDBUserPass($webUN,$webPW);
$data->SetCharacterEncoding('utf8');
$data->SetDataParamsEncoding('utf8');
// 正しいフィールド名は「type」
$data->AddDBParam('typo', 'FX_Fuzzy_Debugger Test');
$data->SetRecordID(1);
$dataSet = $data->DoFXAction('update');

// DEBUG_FUZZYがtrueの場合は、デバッグメッセージを表示
if ( true === DEBUG_FUZZY )
{
    echo $data->lastDebugMessage;
}

// エラーコードの表示
echo '<p>' . $data->fxError . '</p>';

PHPの先頭側でdefine('DEBUG_FUZZY', true);とし、FileMakerエラーコードの表示前にデバッグメッセージを表示するようにしている。typeフィールドに文字列「FX_Fuzzy_Debugger Test」を格納するように記述しているが、スペリングミスで102エラーが返る。DEBUG_FUZZYを無効・有効にした場合の実行結果は次のとおり。

DEBUG_FUZZYをfalseとしている場合。FileMakerエラーコードが表示されているのみ

DEBUG_FUZZYをtrueとしている場合。FileMakerエラーコードの表示前に、FX_Fuzzy_Debuggerによって各種デバッグメッセージとエラーの対応策が表示されている

たった数行加えるだけでデバッグ/トラブルの原因切分時に有用なメッセージが表示されるのは心づよい。今回の例の場合だと、わざわざフィールド名の訂正までデバッグメッセージに含めてくれる。トラブル時に行き詰る前に、FX_Fuzzy_Debuggerの使い勝手をひととおり確認しておこう。