MySQL等の外部DBを使用し、複数のリレーションを設定したポータル内では、検索を実行できません。 たとえば、売上と売上明細のテーブルを[売上No]と[区分]という二つのフィールドでリレートし、ポータルに売上明細のフィールドを置き、これらで検索しても失敗します。
FMのバグでしょう。
関連リンク:『売上猫くん on MySQL』開発日記の記事一覧
2010-03-26
『売上猫くん on MySQL』開発日記 - 番外5 - ポータルで検索できない
2010-03-23
『売上猫くん on MySQL』開発日記 - 番外4 - mysqldump で文字化け?
mysqldumpで作成したテキスト(sql)ファイルを WordPad で開いてみる。 文字化けだらけ。
MySQLクライアントを使用しても、phpMyAdmin を使用しても結果は変わらず。ただ、phpMyAdminで実行結果を画面に出力するとちゃんと表示される奇怪。
「mysqldump 文字化け」でググってみるといろいろと記事があり、それを見ながら --default-character-set やら、my.ini やらでいろいろ試してみるが解決には至らず。
半日ほど頑張ってみたが埒があかないので、念のため、隣の人に聞いてみた。すると「WordPadを使ってませんか?」 。 「はぁ?」 、固まる小生。 WordPadって、NotePadの上位エディタじゃないの? NotePadで 確かに、NotePadは UTF-8とUnicodeの保存オプションがあるのに、 WordPadにはUnicodeのみ。 読み込みできるキャラクタセットが違うらしい。 WordPad のUnicodeはUTF-16LE対応.
Notepadはこれに加えてUTF-8対応。 あー、とんんだ恥さらし記事だけど、小生の同類がいるかもしれないので、恥を忍んで上げておこう。
関連リンク:『売上猫くん on MySQL』開発日記の記事一覧
MySQLクライアントを使用しても、phpMyAdmin を使用しても結果は変わらず。ただ、phpMyAdminで実行結果を画面に出力するとちゃんと表示される奇怪。
「mysqldump 文字化け」でググってみるといろいろと記事があり、それを見ながら --default-character-set やら、my.ini やらでいろいろ試してみるが解決には至らず。
半日ほど頑張ってみたが埒があかないので、念のため、隣の人に聞いてみた。すると「WordPadを使ってませんか?」 。 「はぁ?」 、固まる小生。 WordPadって、NotePadの上位エディタじゃないの? NotePadで 確かに、NotePadは UTF-8とUnicodeの保存オプションがあるのに、 WordPadにはUnicodeのみ。 読み込みできるキャラクタセットが違うらしい。 WordPad のUnicodeはUTF-16LE対応.
Notepadはこれに加えてUTF-8対応。 あー、とんんだ恥さらし記事だけど、小生の同類がいるかもしれないので、恥を忍んで上げておこう。
関連リンク:『売上猫くん on MySQL』開発日記の記事一覧
2010-03-22
『売上猫くん on MySQL』開発日記 - 番外3 - 0を書き込みできない
売上明細テーブル( vw_salesdtls)のInt型のフィールド(balanceFlg)に値を書き込もうとする。他の値は書き込みできるのだが、“0”の書き込みが実行できない。 ログで何が起こっているのか確認する。
Commitに失敗している場合はバイナリログには記録されないので、mysqlbinlog は使えない。 そこで、一般ログというものを、
mysql> set global general_log="ON";
で作成してみる。 以下、1を立てて成功したログと、0で失敗したログ(一部抜粋)。
【1立てで成功】
9 Query SELECT ID,`売上番号`,balanceFlg, ~略~ FROM vw_salesdtls WHERE ID=8340 FOR UPDATE
9 Query UPDATE vw_salesdtls SET balanceFlg=1 WHERE ID=8340
【0立てで失敗】
8 Query SELECT ID,`売上番号`,balanceFlg, ~略~ FROM vw_salesdtls WHERE ID=8341
失敗したほうでは、なぜか FOR UPDATE 以下が発行されず、当然これでは更新できない。 当初はInnoDB側に何か問題があるのかと疑ったが、FileMakerが適切なクエリを発行していないことがわかった。ちなみに、類似した他のテーブルでは、1、0の値に関係なく、更新(Update)は成功する。
いろいろとやってみた。FMのファイルを修復したり、レイアウトモードにして数字の書式を変更してみたり、フィールド定義を眺めてみたり。 そして、これが FileMaker のバグだと判明。 なんと、FileMaker は 空欄(null)→0 への変更は変更と認識しない、null=0 と認識するのである。 更新と認識しないので、 Update が発行されない。 恐ろしい。
結論
ということで、null と 0 を区別して扱う必要がある場合は、非常に注意が必要だ。 0 を参照キーするのは極力避けるべきた。 MySQL側で初期値を0に設定しておく、というのは一案かもしれない。
ちなみに、上述のように「null=0 と認識」するので、0→空欄lに変更を行っても、コミットすると 0 のままである。
関連リンク:『売上猫くん on MySQL』開発日記の記事一覧
Commitに失敗している場合はバイナリログには記録されないので、mysqlbinlog は使えない。 そこで、一般ログというものを、
mysql> set global general_log="ON";
で作成してみる。 以下、1を立てて成功したログと、0で失敗したログ(一部抜粋)。
【1立てで成功】
9 Query SELECT ID,`売上番号`,balanceFlg, ~略~ FROM vw_salesdtls WHERE ID=8340 FOR UPDATE
9 Query UPDATE vw_salesdtls SET balanceFlg=1 WHERE ID=8340
【0立てで失敗】
8 Query SELECT ID,`売上番号`,balanceFlg, ~略~ FROM vw_salesdtls WHERE ID=8341
失敗したほうでは、なぜか FOR UPDATE 以下が発行されず、当然これでは更新できない。 当初はInnoDB側に何か問題があるのかと疑ったが、FileMakerが適切なクエリを発行していないことがわかった。
いろいろとやってみた。FMのファイルを修復したり、レイアウトモードにして数字の書式を変更してみたり、フィールド定義を眺めてみたり。 そして、これが FileMaker のバグだと判明。 なんと、FileMaker は 空欄(null)→0 への変更は変更と認識しない、null=0 と認識するのである。 更新と認識しないので、 Update が発行されない。 恐ろしい。
結論
ということで、null と 0 を区別して扱う必要がある場合は、非常に注意が必要だ。 0 を参照キーするのは極力避けるべきた。 MySQL側で初期値を0に設定しておく、というのは一案かもしれない。
ちなみに、上述のように「null=0 と認識」するので、0→空欄lに変更を行っても、コミットすると 0 のままである。
関連リンク:『売上猫くん on MySQL』開発日記の記事一覧
登録:
投稿 (Atom)