Known issue when MOM gathering is run twice in one day it will fail the second time and create a (4286822)

Known issue when MOM gathering is run twice in one day it will fail the second time and create a

The fix that went into 6.0.1 is a short term fix (Solution #16871) with a known issue that if the MOM gathering is run twice in one day it will fail the second time and create a second T_LogJournal entry that could will issues with the reports or gatherings.

Common Error:
Error in Executing SQL Statement - Message: Violation of UNIQUE KEY constraint CN_T_LogJournal. Cannot insert duplicate key in object T_LogJournal;; SQL Statement = UPDATE T_LogJournal SET [ApplicableDate] = :ParamAppDate WHERE [LogJournalGUID] = :ParamLogJournalGUID AND [ApplicableDate] = [GatheringDate];; Param List = Param(0)=8/10/2006, Param(1)={FC59617C-A901-4F41-B203-D7ECA1FCD3DC}</P>

The short term fix was to manually update the T_LogJournal entry and set the applicable day back by one. The MOM gathering should have had an applicable date of yesterday, much like the tracking log gatherings do. The problem with the short term fix is that when SourceExpansion runs for the second time to determine which tasks to run again, it fails to find a T_LogJournal entry with a gathering date of today and an applicable date of today. It allows the task to run and creates a new T_LogJournal entry. You should not to run the MOM gathering more than once per day.

WORKAROUND:

Please run the below query in SQL Query Analyzer and following the instructions provided for resolving the issue with MOM Reports,

Run this query first

Select * from T_LogJournal
Where DataSource = MOM Server Availability and
ApplicableDate = GatheringDate and
GatheringDate > <your upgrade date>

If any rows are returned mark down the LogJournalGUID, then run the below query. Make sure you keep the LogJournalGUID because we might need to delete some data if the T_MOM... table contain data.

Run this query second,

If there are only a few entries run:

Delete from T_LogJournal
Where LogJournalGUID = �<your guid>�

If there are a lot of rows returned run this:

Delete from T_LogJournal
Where DataSource = MOM Server Availability and
ApplicableDate = GatheringDate and
GatheringDate > <your upgrade date>

Now run the report and see if any data is present, of course this presumes that the MOM server is configured properly

STATUS:

Waiting for fix in a future release of MessageStats.

CR0178106