むきーっっ！！ ヽ(`Д´)ﾉ
先々週の金曜日、「どうしてもエラーになりテストが出来ないので、テスト方法を教えて下さい。」 と “シタテに出て”
カナダに訊いた案件があったの。
でも、月曜に受け取った回答は
「こちらの環境のデータはそちらと違いますので、
仕様書を参照しながらデータ作成をお願いします。」
なんていう冷たい回答だったのね。 （環境が違うことなんか言われなくたって充分わかってます！！！！ （怒））
悩んださ。 1 週間悩んださ。
それでも結局解決しなくて、さ。
「やっぱりエラーになってしまいます。この設定のドコがおかしいか教えて下さい。」 とこれまた “シタテに出て”
訊いたのが、先週の金曜日。
今日には回答を貰えてテストが続行できると信じてたんだけどレスがなくて、またまた最初からパターンを潰して
地道にテストを続けてたのだよ。
で、「アタシ、悪くないかも。」 を前提にしてみたら （← 稼動中のシステムなので 「アタシが悪い」 が前提だった。）
突然ひらめいた。
「もしかして、もしかしたら、これが原因？？」
その設定値を変えてやってみたら、エラーにならずに見事ロジックが通りましたよ。
やた！！＼(^O^)／
．．．．なんて言ってるバヤイではない。
あんたたち、バ●？？
確かにフィールド属性は 3 桁の CHAR （文字型、と言われるモノだす。） になってるよ。
だけど、ユーザーが先行ゼロ （“01” とか “001” みたいに “1” とかの前にゼロが入ってるって意味ざます。） を
設定しちゃうかもしれない、っていう 「IF」 をどうして仮想して対応できないの？？
こんなに初歩的なミスを含んだ PG 出してきて、どうして平気でいられるの？？？
確かに参照キーになる年齢は生年月日から割り出した NUMERIC （数値型、ね。） かもしれないさ。
「1 歳」 と 「01 歳」 を比較したらそりゃ、「1 ≠ 01」 だよ、確かに。
「テーブルに設定されてません。」 なんて言われるのは理解できるよ、確かに。
でも、参照先のテーブルの該当フィールドが CHAR だったら、相手に変換かけて NUMERIC にする作業 ――
つまり、「自分に合わせる作業」 をしてから参照かけるだろ、フツーは、よ。
なのに、テストが通らないのは全部アタシが仕様書をきちんと読んでないせいで
「こちらの環境のデータはそちらと違いますので、仕様書を参照しながらデータ作成をお願いします。」 ですか。
嗚呼、そうですか。
ま、これから仕様書の 「補足説明」 欄に追記するんですけどね。
こんなことをわざわざ 「補足」 説明しなくちゃならないってのがムカつくわ。
バグじゃなくて仕様書記載漏れ、とか言われるのがオチなのが余計ムカつくわ。
（ちなみに仕様書書いたのはアタシぢゃありません。はい。）
むきーっっ！！ ヽ(`Д´)ﾉ