In EDB Client Server is there any way to find out Jobs which are currently running.

I have a number of Jobs which can take long but varied amounts of time to run.

The "Last Ran" date is useful to know when a job last finished, but I can't see an easy way to know whether a job is actually in progress.

On 1/14/2015 1:17 PM, Adam Brett wrote:
> In EDB Client Server is there any way to find out Jobs which are currently running.

I think its the enabled flag that is set for whatever job is executing.

Raul

>In EDB Client Server is there any way to find out Jobs which are currently running.

I have a number of Jobs which can take long but varied amounts of time to run.

The "Last Ran" date is useful to know when a job last finished, but I can't see an easy way to know whether a job is actually in progress.<

Try:
select * from configuration.logevents order by logtimestamp

It will have an entry of when the job starts (ends?)  followed by a "Logout From Session" and a "Disconnect From Session". But unfortunately the LogOut and Disconnect will have different SessionId from the Job so you can't tell if they are related.

So I would use the SessionId from the logevents Job row and then execute:
Select * from Configuration.ServerSessions where SessionId=n

where n is the Job's SessionId. If the SessionId is still active *and* logevents does NOT show another process connecting with the same SessionId after the job starts, then it is safe to assume the job is still running. If SessionId is not currently active, or someone else connected with that sessionid after the job was started, it is safe to assume the job has completed. It would be nice if this table had a Job End timestamp, but it doesn't.

I'm not sure if logevents has an ErrorCode when the job is running, but you can check that. I know if the job completes normally the ErrorCode is null.

Barry

Raul,

> I think its the enabled flag that is set for whatever job is executing.

I don't think so. You can disable or enable a job for the current
session. IMHO the flag shows just this state.

Uli

Thanks for the excellent technical reply Barry.

I will write a procedure to try to test the states you mention to assess whether a JOB is active.

I have also noted that if the JOB create files (as mine does) it is possible to do checks on whether new files are being created, and use this to judge (not too accurately!) whether the job is active or not.

I think it would be really useful to have something like the "enabled" flay mentioned by Raul ... i.e. an "Active" or "Running" field on the Configuration.Jobs table, or more coverage in the Configuration.LogEvents table.

Note in Configuration.LogEvents there is a record added "Execute Job" ... it seems to indicate that a job is completed, combined with the other LogEvents records it may help me.

All the same I will request a feature of "Job Started" and "Job Stopped" messages in LogEvents in the Enhancements news group.

Uli Becker wrote:

<<
> I think its the enabled flag that is set for whatever job is executing.

I don't think so. You can disable or enable a job for the current
session. IMHO the flag shows just this state.
>>

Uli,

Could be - i have not investigated jobs too much.

However, I did notice my job that has false for enabled still appears to run on schedule so just having enabled=false is not what i thought it meant.

Also where did you see the "disable or enable per session" ?

I was looking at the manual and only reference i found was the ENABLE/DISABLE JOB and ENABLE/DISABLE JOBS but it does not specify its per session.

Also there is a note that this is  in-memory change only so now i'm getting even more confused since jobs are run by the server so it would have to be not by session.

Anyways, looks like i might need to look into this more unless somebody else has already and can post their findings.

Raul

Raul,

Being an 'in memory' setting only means that it only lasts until the server is restarted and the setting is not saved to the server configuration file. What is ENABLE/DISABLED on a sessions basis is Triggers, not JOBs.

--
Fernando Dias
[Team Elevate]

Raul,

sorry about the confusion, Fernando is right, I confused that (session related) with triggers.

Actually there seems to be an issue with the enabled flag of jobs. I had the same problem on a server: all jobs where listed as disabled but executed correctly.
On another computer it worked as expected. Still investigating that.

Uli

On 1/16/2015 6:15 PM, Uli Becker wrote:
> Actually there seems to be an issue with the enabled flag of jobs. I had the same problem on a server: all jobs where listed as disabled but executed correctly.
> On another computer it worked as expected. Still investigating that.

I just checked and yes it's same here - enabled=false jobs are running.

Let me know if you get to the bottom of why you're seeing different
results on different machines.

So now i'm curious how the enabled flag is supposed to work etc ?

Raul

On 1/16/2015 3:08 PM, Fernando Dias wrote:
> Being an 'in memory' setting only means that it only lasts until the
> server is restarted and the setting is not saved to the server
> configuration file.

Fernando,

Thanks.

I do understand what in-memory means in general but not what is going on
in job context  ?

In my cases the jobs are "enabled=false" and they still run on schedule.

And why would DISABLE JOB (and other job sql) only update in-memory
status anyways that is lost on restart ?!

Raul