Issue applying Manufacturing Light migration scripts on Windows (suggested fix included)
Description
During a recent migration of Adempiere 3.6.1 to Idempiere release on Windows (postgres 9 also in windows), We notice that one of the scripts of the Manufacturing ligth ((862a_ManufacturingLight.sql) failed to create properly some of the fields for a couple of tables, after some hours of debugging we find a good fix/enhancement to avoid this migration scenario. It is a major issue, because a lot of sql scripts will failed after that, and it is a bit hard to find the source unless you really use the manufacturing light functionality.
Please notice we didn´t use pgadmin to run the scripts (we know it is not recommended) we just used psql command line utility from Postgres 9 database, and we are able to replicate the behavior manually
These SQL sentences should have a default value or they will fail:
1. ALTER TABLE M_Production ADD COLUMN DocumentNo VARCHAR(30) NOT NULL;
should be replaced by:
ALTER TABLE M_Production ADD COLUMN DocumentNo VARCHAR(30) NOT NULL default '';
2. ALTER TABLE M_Production ADD COLUMN M_Product_ID NUMERIC(10) NOT NULL;
should be replaced by:
ALTER TABLE M_Production ADD COLUMN M_Product_ID NUMERIC(10) NOT NULL default 0
3. ALTER TABLE M_Production ADD COLUMN M_Locator_ID NUMERIC(10) NOT NULL ;
should be replaced by:
ALTER TABLE M_Production ADD COLUMN M_Locator_ID NUMERIC(10) NOT NULL default 0;
All of these to be sure that these new columns are created properly....if not, an SQL exception is triggered ...but the SQL continues and a lot of sql migration scripts will fail later (very hard to find them).
Environment
adempeire 3.6.1 migrating to Idempiere, with postgres 9 on windows -
During a recent migration of Adempiere 3.6.1 to Idempiere release on Windows (postgres 9 also in windows), We notice that one of the scripts of the Manufacturing ligth ((862a_ManufacturingLight.sql) failed to create properly some of the fields for a couple of tables, after some hours of debugging we find a good fix/enhancement to avoid this migration scenario. It is a major issue, because a lot of sql scripts will failed after that, and it is a bit hard to find the source unless you really use the manufacturing light functionality.
Please notice we didn´t use pgadmin to run the scripts (we know it is not recommended) we just used psql command line utility from Postgres 9 database, and we are able to replicate the behavior manually
These SQL sentences should have a default value or they will fail:
1. ALTER TABLE M_Production ADD COLUMN DocumentNo VARCHAR(30) NOT NULL;
should be replaced by:
ALTER TABLE M_Production ADD COLUMN DocumentNo VARCHAR(30) NOT NULL default '';
2. ALTER TABLE M_Production ADD COLUMN M_Product_ID NUMERIC(10) NOT NULL;
should be replaced by:
ALTER TABLE M_Production ADD COLUMN M_Product_ID NUMERIC(10) NOT NULL default 0
3. ALTER TABLE M_Production ADD COLUMN M_Locator_ID NUMERIC(10) NOT NULL ;
should be replaced by:
ALTER TABLE M_Production ADD COLUMN M_Locator_ID NUMERIC(10) NOT NULL default 0;
All of these to be sure that these new columns are created properly....if not, an SQL exception is triggered ...but the SQL continues and a lot of sql migration scripts will fail later (very hard to find them).