Viewing 15 posts - 2,071 through 2,085 (of 4,745 total)
perhaps put the code into a never ending loop with a waitfor '00;00;10' in it, and the job kicks off on server start only?
As for getting that hour back, no...
November 2, 2010 at 11:39 am
Gawd, there's always one. I did say I had never had any problems, which is true :-), and also true for the vast majority
running every 10 seconds is unusual and...
November 2, 2010 at 11:37 am
I'd agree with tom here, I've never noticed a problem, clocks going back or forward, other than negative run times recorded in SQL2000. The doco I enclosed with my...
November 2, 2010 at 9:52 am
no takers so I will broaden it out a bit:
Has anyone had to update ODBC drivers on the client end when doing a SQL2000 to SQL 2008 upgrade.
anyone hit this...
November 2, 2010 at 7:44 am
the effects may be OS dependant, SQL seems to blithely carry on. I have a log shipping set up with jobs running every 15 mins and I enclose a doco...
November 2, 2010 at 4:56 am
Stefan Krzywicki (11/1/2010)
Thank you both for the helpful information. Now I can go on vacation this weekend without worrying. : -)George, where are you that you've already had daylight savings?
the...
November 1, 2010 at 1:44 pm
for what its worth, mine ran fine as scheduled. I have seen some weird negative run times reported, but only under SQL2000.
November 1, 2010 at 12:00 pm
I'd use dbcc timewarp on that, especially as its already monday. 🙂
...er to explain, we had daylight savings weekend just gone.
November 1, 2010 at 11:48 am
patience! Its only been a couple of hours and it is sunday!
Have you looked at the installation log? Otherwise people can only guess.
October 31, 2010 at 3:54 pm
Be aware that if you have it as a separate install in its own resource group and there is a chance those groups could be active on different nodes then...
October 31, 2010 at 10:23 am
Brandie, in case you haven't seen it Brian Kelleys article from this weeks database weekly touches on what you are looking at:
Looking at this it would seem if you scanned...
October 31, 2010 at 8:51 am
statistical values are held within the database and therefore within the backup so come across with the backup, therefore no need to rerun
EXCEPT
if you are restoring to a different server...
October 30, 2010 at 3:29 am
glad that fixed it.
Its the prescribed way to move agent log and yes should have been part of your migration plan. You would have had to time it to be...
October 30, 2010 at 3:22 am
presume the old agent log location no longer exists? Did you change the location for the agent errorlog?
USE msdb
GO
EXEC msdb.dbo.sp_set_sqlagent_properties @errorlog_file=N'<New_Errorlog_Location>\SQLAGENT.OUT'
GO
October 29, 2010 at 4:31 pm
Viewing 15 posts - 2,071 through 2,085 (of 4,745 total)