QA@IT
«回答へ戻る

回答を投稿

結局エラーからそのコードに問題があったのかなかったのか、そしてそれを理解しているのかの方が重要でしょう。
エビデンスが無いならばやってないと言われても仕方がないですね。
研修ではなくユーザーに提供した後に問題が発覚したと考えてみてください。
実際にコードに問題がある場合、「やった」「やってない」で腑に落ちないのならば検証不足だったと捉えれば良いかと思います。

REDOログが残っていればLogminer使って辿ることは可能かもしれませんが、
手間を考えると現実的ではないですね。

isbn列が「CHAR(17)」ならば、4文字追加すれば21文字になるので、Trimしていなければ桁あふれになるような気がします。
レコードが1件も無い状態ならば、そのupdate文は成功するでしょう。
更新された内容は確認したんでしょうか。

isbn列が「VARCHAR(17)」だった場合は、
末尾空白が含まれずに4桁増えるので元のデータが13桁以下ならば成功します。
ただしいつかは桁数があふれるので1回目にうまくいったからといって2回目もうまくいく保証がありません。
ISBNは13桁なので普通に考えれば2回実行したらエラーになるでしょう。
現在のデータが既に頭に'ISBN'がついていて17文字ならデータ不良なんではないですかね。

信じてもらえず憤る気持ちはわからないでもないですが、機能が提供できていたのか否か、どうすれば本番でそのようなことが起きるのを減らせるか、そういう方向で考えた方が研修としてはよいでしょう。

結局エラーからそのコードに問題があったのかなかったのか、そしてそれを理解しているのかの方が重要でしょう。
エビデンスが無いならばやってないと言われても仕方がないですね。
研修ではなくユーザーに提供した後に問題が発覚したと考えてみてください。
実際にコードに問題がある場合、「やった」「やってない」で腑に落ちないのならば検証不足だったと捉えれば良いかと思います。

REDOログが残っていればLogminer使って辿ることは可能かもしれませんが、
手間を考えると現実的ではないですね。

isbn列が「CHAR(17)」ならば、4文字追加すれば21文字になるので、Trimしていなければ桁あふれになるような気がします。
レコードが1件も無い状態ならば、そのupdate文は成功するでしょう。
更新された内容は確認したんでしょうか。

isbn列が「VARCHAR(17)」だった場合は、
末尾空白が含まれずに4桁増えるので元のデータが13桁以下ならば成功します。
ただしいつかは桁数があふれるので1回目にうまくいったからといって2回目もうまくいく保証がありません。
ISBNは13桁なので普通に考えれば2回実行したらエラーになるでしょう。
現在のデータが既に頭に'ISBN'がついていて17文字ならデータ不良なんではないですかね。

信じてもらえず憤る気持ちはわからないでもないですが、機能が提供できていたのか否か、どうすれば本番でそのようなことが起きるのを減らせるか、そういう方向で考えた方が研修としてはよいでしょう。