import database task

Hi, this raises a much bigger question….

As an analogy, when you design a physical product, you design not only how it’s going to look in the end user’s hands but also how it’s going to be machined on the factory floor. Both these functional and nonfunctional requirements affect the business value.

Likewise, when delivering a developed IT product, the team should consider the deployment to PROD up front as a deliverable. Deployment is where 90% of problems arise in PROD because “it worked in TEST."

I recommend splitting your DEV and TEST environments. Moving from DEV to TEST simulates the act of moving your work, and your deployment process then becomes part of what you’re testing in TEST.

(Standardizing the environmental factors of deployment as part of the delivery is a big part of DevOps.)

To partly answer your question, splitting DEV and TEST ensures you don’t have to run a scary script like this for the very first time in PROD. The deployment itself becomes part of the delivery.

You can run an .INS file with SQL*Plus:

sqlplus ifsapp/password@tnsname_for_environment @"file.ins"

I normally have to edit these scripts to get them to work right. I recommend putting this stuff on top, above the code:

SET SQLBLANKLINES ON
SET SERVEROUTPUT ON SIZE UNLIMITED
SET FEEDBACK ON
SET ECHO ON
SPOOL out.txt

In order,

This allows lines to span across whitespace.

This turns on output so you can see what’s happening.

This shows the result of each command.

This shows the commands as they’re run.

This outputs the results for history.

Then, below the code:

COMMIT;

EXIT