May 18, 2004 at 4:50 pm
We login to our sql server with our windows accounts and can look at the sql agent jobs in enterprise manager via the msdb.targetserverrole membership; however, the "Next Run Date" on all of the jobs shows "Date and Time are not available". I have tried placing our accounts in every server role and database role, but the message still displays. The only role that will resolve the problem is the System Admin role and our windows accounts cannot have this membership as it does not appeal to our auditors.
Can anyone shed any light on this anomally?
Thank You, Lloyd
May 19, 2004 at 8:57 am
Are the jobs properly scheduled?
Are the Job's and schedule's enable button checked?
May 19, 2004 at 10:01 am
Yes, they are scheduled and enabled and running fine. It's just that we cannot see the Next Run Date (only Date and Time is not available) unless we login to Enterpise Manager as a Sysadmin member.
Thanks
May 19, 2004 at 12:38 pm
Try adding select permissions for those users to the msdb..sysjobschedules table.
May 19, 2004 at 2:16 pm
Thanks for the suggestion, but that didn't change anything.
May 20, 2004 at 11:14 am
Hi Lloyd,
I did a little more digging, try granting select permission to the sysjobsteps table. If that still doesn't work try granting execute permission to the sp_get_composite_job_info and sp_help_jobschedule stored procs in the msdb database.
Regards,
Steve
Meddle not in the affairs of dragons, for you are crunchy and taste good with ketchup.
May 20, 2004 at 12:25 pm
Thanks, but his did not help either.
Lloyd
April 29, 2007 at 12:12 pm
This thread is kinda old but it did show up while I was researching a current issue I was having with schedule jobs not running and the next run time showing, "Date and Time are not available".
There are other posts stating that reapplying a service pack resolved the issue. I was running sql 2000 with sp3 and I recently had enabled cross database ownership chaining for a new aspstate database. I suspect that this activity may have led to the issue. I installed SP4, probably should have just done sp3, and that seemed to resolve the issue. I tested my website prior to considering issue as resolved and all seems to be working post-SP4.
Maybe someone knows if enabling cross database ownership chaining on sql 2000 with sp3 leads to this job scheduling issue.
April 30, 2007 at 12:23 pm
I had the same thing happen yesterday. We came in early Sunday morning to apply patches to the servers. Our system mandates we shut the servers down and bring them up in a certain order. After applying the patches we shut them down. One of the SQL servers, when brought up had no "Next run date" - not available. I believe that this was caused by Veritas backup starting a backup when it came back on line. (There is one database that is 66 Gig)
December 19, 2007 at 5:55 am
I've been struggling with this issue recently, and I finally found an explanation. Our SQL Server Agent was not running. Once I started it up, the Next Run Date displayed correctly.
You can start the Agent by opening the SQL Server Service Manager, selecting the "SQL Server Agent" Service, and clicking the "Start/Continue" button.
I assume that the original posters have long since discovered an alternative solution(s), but I figure someone else is bound to come along with the same problem. I hope this helps!
March 30, 2008 at 7:42 pm
I had this problem on a client's server. I had a maintenance plan to backup some transaction logs and it wouldnt tell me when the "Next Run Date" was due.
I tracked it down to the schedule being disabled. I hadnt disabled it, I suspect that in creating the maintenance plan something went wrong.
May 8, 2009 at 3:14 am
I know its a long time gone but our "Date and Time not...." issue was resolved because as was pointed out...the SQLSERVERAGENT wasn't started following a reboot after installing BackupExec12. Many Thanks.
June 11, 2010 at 6:15 am
Thanks for offering this solution (schedule was disabled and not by me!), exactly what was wrong on my end.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply