Wonderfull , this show that wat great factor shoub be noted by any DBA hows its important , keeep it up
Great Idea, this thought pattern can be used in other area's too.I would give my left leg for a method of dumping out Server EVT's parsing them cleaning them and then letting me know if anythings' gone wrong.
Without me having to lift a finger.
Haven't found the problem yet but even after putting a "WARNING" message in my log, I'm still getting No Errors in the Error Logs
I thought the use of character fields for the Error_Date fields could be a problem but now I don't think so. Must be something in Usp_Errorlog_Notification
RAISERROR ('WARNING', 16, 1) with log
All,
The version of the proc I included is incorrect, and I will ask Steve to post a new zip file with the updated code. Essentially when the delete happens based upon the date, we used to have a convert statement and we lost that during one of the last frantic rewrites as we tried to get things working for SS2K5.
Anyway, the key is to have this line:
delete #Errors from #Errors eTmp where vchLogDate <= @MxDateDel
changed to this:
delete #Errors from #Errors eTmp where convert(datetime,vchLogDate) <= convert(datetime,@MxDateDel)
That should avoid the problem you are seeing right now, i believe. Also, when in doubt, we sometime will flush the ErrorsP1 table with a truncate statement in order to see if that helps things flow through again.
Let me know if there are any other issues with the code so that I can research it immediately.
tom
I also changed this line to convert char to datetime -- before that I was getting lots of very old log entries emailed to me.
-- next, find the current max date in the ErrorsP1 table
Select
Also removed "login failed for user" from ErrorlogScanExclude table because I don't get many and wanted to see them.
