I will explain the trouble caused by the import export function and its countermeasure.

Overview

Wagby import processing is "drop and create" method.Here the first drop processing may fail.(Include cases where you fail to execute "drop_db.bat" command manually from the command line.)

The drop process buildsBeforeYou need to do this using drop_db.bat included in the application.(Or drop each database and recreate it.)

I built it.rearIf you use drop_db.bat included in the application, it may not be processed normally.I will explain this reason.

Details: Reasons to fail when trying to perform drop processing after build

As an example, if there is a check 1 check box item in the test 1 model, the table definition is as shown below.

   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";

The SQL statement for dropping this model is as follows.

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

As you can see from the example above, in Wagby, "repeating container" and "check box" are the main tableAnother tableIt manages with.Also, this table sets the main table and foreign key constraints.

Here, this check 1 itemDelete and build, The table definition and the SQL for drop are recreated as follows.

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

   drop table "test" if exists;

Therefore, if you try to delete the table of the test1 model before the build with the (new) drop statement after the build, you can not delete the test table because it is a foreign key constraint.