I don't know who requested LANDesk to make this change or if it was something they did on their own.
I personally hate it, I mean HATE with a passion these entries, and the entries flood my database.
It also causes the properties for the specific vulnerability to crash due to too many records if you click on the history tab. It takes forever to open, then crashes with too many returned records.
To see how many records are in your table, try the following command (substitute LDMS95 for your database name):
SELECT * FROM [LDMS95].[dbo].[PatchHistory] Where Patch = ''
We had nearly a million entries.
I've finally just resorted to manually deleting them from my SQL database using the following command.
DELETE FROM [LDMS95].[dbo].[PatchHistory] Where Patch = ''
The other option if you wanted to keep X number of days is. Replace 90 with the number of days:
DELETE
FROM [LDMS95].[dbo].[PatchHistory]
Where Patch = '' and dateDiff("d",Actiondate,getdate())>90
We've previously had issues with customized vulnerabilities flooding the patchy history table, and we ended up adding the purge to our SQL maintenance scripts. Where Patch = 'XYZ' and and dateDiff("d",Actiondate,getdate())>90.
This worked pretty well in 9.0 and is working fine in 9.5.....
I have no idea however, why these entries in the table are not tied to a specific patch and the column data is empty. Maybe so it shows up across every history table or something, but IMHO, it needs to be designed better so that its not flooding the database or causing the console to crash. You could easily avoid the crash and improve performance by only returning the latest set of data and then dynamically loading it as you scroll downward or something.