I have a SQLcl Project which includes a Scheduler Job (owner by the application user).
After upgrading from SQLcl version 25.3.0.0 to version 25.4.0.0 (build: 25.4.0.336.1328), deployments are now failing on changesets related to the Scheduler Job with the error:
Error :
liquibase.exception.DatabaseException: BEGIN
*
ERROR at line 1:
ORA-27469: JOB_NAME is not a valid job attribute
ORA-06512: at "SYS.DBMS_ISCHED", line 3441
ORA-06512: at "SYS.DBMS_SCHEDULER", line 3512
ORA-06512: at line 3
https://docs.oracle.com/error-help/db/ora-27469/
Full details:
- Database version: 23.26.0.1.0 (Autonomous OLTP in OCI)
- No changes to the Scheduler Job were made as part of the most recent deployment (not in a long time actually).
- Scheduler Job just runs an inline PL/SQL block - no chains, programs, windows, or any other advanced Scheduler configurations.
- After upgrading to SQLcl version 25.4, two changes are observed while using the SQLcl Projects workflow:
- In the file
my-project/src/database/my_schema/jobs/my_existing_scheduler_job_name.sql the schema name is now omitted from all APIs (i.e. from the “name” and “job_name” fields). I have always had the configuration setting "emitSchema" : false but perhaps now this is only coming into effect for Scheduler Jobs. I don't think this is relevant however.
- A new file called
my-schema/dist/releases/X.Y.Z/changes/my-git-branch/my_schema/jobs/my_existing_scheduler_job_name.sql has been created. This is the changeset that is failing.
The contents of the file included with the changeset is:
BEGIN
DBMS_SCHEDULER.disable('"MY_SCHEMA"."MY_EXISTING_SCHEDULER_JOB_NAME"');
DBMS_SCHEDULER.set_attribute (
name => '"MY_SCHEMA"."MY_EXISTING_SCHEDULER_JOB_NAME"',
attribute => 'job_name',
value => '"MY_EXISTING_SCHEDULER_JOB_NAME"');
DBMS_SCHEDULER.enable('"MY_SCHEMA"."MY_EXISTING_SCHEDULER_JOB_NAME"');
END;
And as mentioned, it's failing with the error stack shown above.
Checking the documentation for DBMS_SCHEDULER , job_name I do believe is indeed an invalid attribute in this case. And consequently, this does look like it might be a new SQLcl 25.4 bug IMO.
(I'll have to skip this changeset to allow for the rest of the deployment to complete.)
FYI