A5Mk2
http://www.wind.sannet.ne.jp/m_matsu/developer/a5m2/
普段、SQL関連は、A5Mk2っていうソフトを使用しています。
今回のエラーは、自分のミスで発生したものなので、別にソフトをディスる訳じゃありません。
むしろ、非常にありがたく使ってますが、ちょっとだけ気をつけないといけないことがありました。
SQLを自分で書きたくない
SQLも新規で作成したり、修正したりと手書きではやってられないので、エディタを使って作成してます。
ER図も使えるし、DBとの接続も可能で軽量なので、割と重宝してます。
SQLもエディタで作成できるし、項目数の多いテーブルを扱う時なんかは、項目名の入力ミスも防げるしで、特殊な構文を使わないSQLなら、結構使いやすい。
数十個の列名と、さらにJOINしたテーブルの項目と・・・なんて、手書きでやってられっか!!ってなりますw
MicrosoftのAccessでも同じようなことは出来るんですが、Accessがインストールされてないと使えないので、環境を選ばないという点でも良い。
エラーと原因
参考URL
ORA-01031: 権限が不足しています。
http://www.shift-the-oracle.com/oerrs/ora-01031.html
こういうのも怒られる原因の1つなんですが、また、ドハマリしました・・・
内容は超単純・・・
テスト用と本番用の環境があって、基本、テスト用のDBで作業を行っているわけです。
で、SQL、特にJOINとかを自分で書けない(1,2テーブルなら書けるんです・・・)ので、こういったエディタは重宝します。
最終的には、PGに組み込んだ上でSQLの実行確認をするわけですが、エディタで作成する時に付与されるんです。
何がって?
スキーマが。
TESTとORGって言うスキーマで作業してると、
TEST.tableA.CD1, TEST.tableB.CD2….
って自動付与されるのが残ってました。
で、どうなるかと言うと、「TEST」スキーマで確認してる分には何の問題も無いわけです。
それが、別の担当者が同じPGで「ORG」スキーマにて実行すると、ORGにTESTの権限が無いため、今回のエラーである「ORA-01031:権限が不足~」となります。
スキーマが付与されていない状態のSQLならテーブル構成(列とかテーブルそのもの)が違わない限り、同じ動作をします。
まとめ
普段なら、スキーマは削除してからPGへ乗せるのに、今回は完全に忘れ去られてましたね。
早く登録しろとか言われたり、別の作業が詰まっていたりして、チェックが足りませんでした。
スキーマの自動付与が悪いわけじゃないんですよねw
移植時のチェックフローを確立しないと、また怒られるw