There's a few starting points for you (a bit of context would be VERY helpful, since if we have the full picture, we can give better advice):
Basic, old(-er) SOAP-based API -- Getting Started with the MBSDK (Example Scripts Included)
This is a decent starting place to understand how the patch info is stored in the database (it's pretty straight forward) -- Getting started with Patch Reporting (SQL, Tables & such) .
I would suggest playig with the above on a test core with a small handful of devices so you don't drown in data. The structure is simple - it's just usually a LOT of data.
But yeah - what are you trying to do / achieve (and why)? If we know more, we can give decent advice.
thanks for the API link, will try to use at least a few as and when requests comes in.
A request was to automate the heath check of Landesk server/services, I was able to get the services, .scn file count, scheduled download and gather tasks from DB, backup & activation info from CSA using powershell.
the last step is to get that above info ( screenshot)
wanted to know what that Data is ( AFAIK it looks to be a scan date, not sure ) and where I can pull that from? this is the last task which is pending.
So - that's a "calculated value" (the devs do a bit of code-based maths -- this isn't just a "field in the database" that you can query).
Why are you so after the # of devices since GatherHistorical last ran?
You can check when a given device last sent in a / somrt sort of vulnerability scan easily enough (though this is JUST based on the type of scan - i.e. Security, Vulnerability, etc -- it's NOT checking whether you scanned against "all your definitions" or "just a custom group") by poking this DATETIME field in the COMPUTER table.
select DEVICENAME, LastUpdInvSvr as 'Last Inventory Update', VALastScanDate as 'Last Vulscan Update' from COMPUTER
... which would give you something like the following output ...
The maths is essentially just a case of "when did Gather Historical last run" versus "who has reported in since then" ... not difficult if need be ... but not a super reportig-centric thing as you can just Gather Historical on a sensible schedule and know that "at most, a record will be X old" ... and as long as that's within your acceptable numbers, that's fine (be it 1 week or 1 day, or whatnot).
It's usually more important / relevant to ensure that clients are checking in regularly in the first place (as you can always run GatherHistorical by hand if need be for reporting).