# Issue with job scheduler tool **URL:** \ **Category:** SQL Navigator\ **Created:** [November 30, 2012, 12:09pm UTC](https://forums.toadworld.com/t/issue-with-job-scheduler-tool/4710 "2012-11-30T12:09:46Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![estevens\_062](https://avatars.discourse-cdn.com/v4/letter/e/cdc98d/32.png) [@estevens\_062](https://forums.toadworld.com/u/estevens_062)\ **Post date:** [November 30, 2012, 12:09pm UTC](https://forums.toadworld.com/t/issue-with-job-scheduler-tool/4710/1 "2012-11-30T12:09:46Z")
SQL Nav ver 6.7.0.2372 When using the job schedule tool, we’ve noticed that almost anything we do to a job causes the job to be immediately submitted. Most of our jobs are set up with a repeat interval specified with a pl/sql function, and we are trying to change them to use scheduler calendaring. However, until that change gets made, simply disableing the job causes the scheduler to recalculate the NEXT\_RUN\_DATE and thus submit the job immediately. I finally did a session trace to see what was going on with this. The steps I followed are: 1 - start SQL Nav and establish a new session against the database 2 - star the scheduler tool 3 - select a job 4 - uncheck the ‘enabled’ box 5 - from a seperate sqlplus session, start a trace on the sql nav session (exec DBMS\_MONITOR.SESSION\_TRACE\_ENABLE …) 6 - back in SQL Nav, hit the ‘save’ button to execute the pending ‘disable’ action 7 - back in the sqlplus session, stop the trace 8 - review the raw trace file What the trace revealed was that SQLNav is doing a whole bunch of stuff unrelated to simply disabling a job. Here’s a brief of what I see in the trace file begin sys.dbms\_scheduler.set\_attribute(:name,:attr,:value); end; (job\_class) begin sys.dbms\_scheduler.get\_attribute(:name,:attr,:result); end; (program\_name) begin sys.dbms\_scheduler.get\_attribute(:name,:attr,:result); end; (schedule\_name) begin sys.dbms\_scheduler.get\_attribute(:name,:attr,:result); end;(job\_type) begin sys.dbms\_scheduler.set\_attribute(:name,:attr,:value); end;(job\_action) begin sys.dbms\_scheduler.set\_attribute(:name,:attr,:value); end;(job\_type) begin sys.dbms\_scheduler.set\_attribute(:name,:attr,false); end;(auto\_drop) begin sys.dbms\_scheduler.set\_attribute\_null(:name,:attr); end;(end\_date) begin sys.dbms\_scheduler.set\_attribute(:name,:attr,:value); end;(repeat\_interval) begin sys.dbms\_scheduler.set\_attribute(:name,:attr,:value); end;(comments) And finally, the one and only thing I specified to be done … begin sys.dbms\_scheduler.disable(:name); end;() So my question is … why is SQLNav doing all the extra, unnecessary calls to dbms\_scheduler? ---
**Author:** ![roman](https://sea1.discourse-cdn.com/quest/user_avatar/forums.toadworld.com/roman/32/65_2.png) [@roman](https://forums.toadworld.com/u/roman)\ **Post date:** [December 2, 2012, 11:25pm UTC](https://forums.toadworld.com/t/issue-with-job-scheduler-tool/4710/2 "2012-12-02T23:25:17Z")
Hi estevens\_062, Currently the logic of the job saving routine is too simple: instead of setting only the attributes that have changed, we set ALL attributes displayed to the user. This certainly should be improved. I don’t understand though why your jobs are submitted after you save them. I’ll investigate and come back to you. Regards, Roman ---
**Author:** ![estevens\_062](https://avatars.discourse-cdn.com/v4/letter/e/cdc98d/32.png) [@estevens\_062](https://forums.toadworld.com/u/estevens_062)\ **Post date:** [December 3, 2012, 7:18am UTC](https://forums.toadworld.com/t/issue-with-job-scheduler-tool/4710/3 "2012-12-03T07:18:16Z")
Roman, thanks for the reply. As for the unplanned job submission, my tracing did not show them being specifically submitted, so I presume it has to do with the nature of the pl/sql functions used to specify the repeat interval. These are old, home-grown functions originally written for dbms\_job instead of dbms\_scheduler. I really don’t have a good handle on that, and replacing them with dbms\_scheduler calandering is a big part of this current project. I am presuming that something about the changes causes the scheduler to recalculate NEXT\_RUN\_DATE and somehow come up with “now”. I have not observed this behavior when REPEAT\_INTERVAL is expressed as a calender rule instead of a pl/sql function.