トラブルシューティング

最終更新日: 2022年6月23日

インポートエクスポート機能で生じるトラブルとその対策を説明します。

特定のテーブルの削除に失敗する

概要

Wagbyのインポート処理は「drop and create」方式です。ここで最初の drop 処理が失敗する場合があります。（コマンドラインから "drop_db.bat" コマンドを手動で実行し、失敗する場合も含みます。）

drop 処理は、ビルドする前のアプリケーションに含まれるdrop_db.batを使って行う必要があります。（もしくはデータベースごとdropして、再作成します。）

ビルドした後のアプリケーションに含まれるdrop_db.batを使った場合、正常に処理できないことがあります。この理由を説明します。

詳細 : ビルド後に drop 処理を行おうとすると失敗する理由

例として test1 モデルに check1 チェックボックス項目がある場合、下記のようなテーブル定義となります。

   create table "test1$check1" (
       "id" varchar(255) not null,
       "check1" integer,
       "cid" integer not null,
       primary key ("id", "cidjshid")
   );
   create table "test1" (
       "id" varchar(255) not null,
       "content" varchar(255),
       primary key ("id")
   );
   alter table "test1$cont" 
       add constraint FK71CD34BF2EE4ECB9 
       foreign key ("id") 
       references "test1";

このモデルをdropするためのSQL文は次のようになります。

   alter table "test1$cont"
       drop constraint FK71CD34BF2EE4ECB9;
   drop table "test1$cont" if exists;
   drop table "test" if exists;

上の例からわかるように、Wagbyでは「繰り返しコンテナ」や「チェックボックス」はメインのテーブルとは別のテーブルで管理します。また、このテーブルはメインのテーブルと外部キー制約を設定しています。

ここで、このcheck1項目を削除してビルドすると、テーブル定義およびdropのためのSQLは次のように作り直されます。

   create table "test1" (
       "id" varchar(255) not null,
       "content" varchar(255),
       primary key ("id")
   );
   drop table "test" if exists;

このため、ビルド前の test1 モデルのテーブルを、ビルド後の（新しい）drop文で削除しようとすると、外部キー制約のため、testテーブルを削除できないこととなります。