I have a few workstations with SCCM clients that didn't install correctly. Once uninstalled, and later re-installed, I can't get a hardware inventory from these workstations (windows 8). In the SCCM Console on the device's client activity, Policy Request, Heartbeat DDR, and Software Scan are all up to date. Hardware Scan remains blank. I have many other Windows 8 VMs that report accurate hardware inventory.

In the C:\Program Files\Microsoft Configuration Manager\Logs\dataldr.log, here are some of the errors:

ERROR - attempt to update non-existent row (sp = pWorkstationStatus_DATA). Invalid command:  exec dbo.pWorkstationStatus_DATA
~Cannot process MIF XXXXXXX.MIF

I've tried removing the client, deleting the client's C:\Windows\SMSCFG.ini file, and deleting the computer entry in the SCCM console. I then waited a few days, reinstalled the SCCM client on the problematic workstation, but I get the same result: Hardware Inventory date is blank, and errors in the dataldr.log.

I've also gone into the SQL database, and queried one of the problematic machines. There was no entry in System_DATA, System_DISC, or in WorkstationStatus_DATA. I started adding records in the database tables for one problematic machine, with the help of the dataldr.log. Whenever there was a missing entry, I would add it. I gave up after the most recent:
ERROR - attempt to update non-existent row (sp = pBROWSER_HELPER_OBJECT_DATA). Invalid command:  exec dbo.pWorkstationStatus_DATA

I did another SCCM client uninstall, and delete the smscfg.ini. I changed the hierarchy settings for managing conflicting records to "Manually resolve conflicting records" just to *see* if anything appears. After several days, nothing appears in Monitoring\System Status\Conflicting Records.

Is there a hardware ID stored somewhere? How can fix this problem with the database?

Are the VM's generated from a master image?

Are you getting bad mifs generated?

Take a look at my blog on dealing with bad mifs in a VDI environment. 

Not sure if applicable in your instance but you may need to run point 4. 'Remove the Inventory Action ID 1 in WMI to do this run the command wmic /namespace:\\root\ccm\invagt path inventoryActionStatus where InventoryActionID={00000000-0000-0000-0000-000000000001} DELETE /NOINTERACTIVE'

https://sccmentor.wordpress.com/2014/04/08/dealing-with-bad-mif-files-in-a-vdi-environment/

If I remember correctly the VDIs spun from the master weren't reporting back hardware inventory until this space was added.

Initiate a heartbeat DDR from an affected VM and see if it gets updated in the database. If yes: use Roger's Client Center and initiate a full hardware inventory cycle. See if that fixes the problem. 

Those error messages usually appear when a delta MIF is processed but a full MIF was not written to the DB. Usually forcing a full HWInventory collection on the machine will fix this, but if there is some corrupt data coming in with the MIF it could just get thrown into the BadMifs directory again. If that is the case you will likely need to open the MIF from the machine in question (from the badmifs folder on the site server) to see which item is causing the MIF to not be processed, then go to the machine and "fix" or delete that item from WMI or the registry, or wherever it is inventoried from. It could be there is duplicate data in a field that already exists within SCCM - maybe SMS GUID or Serial number or something similar, and SCCM is trying to associate that delta MIF with a different record in the DB.

 I started adding records in the database tables for one problematic machine, with the help of the dataldr.log. Whenever there was a missing entry, I would add it. I gave up after the most recent:
ERROR - attempt to update non-existent row (sp = pBROWSER_HELPER_OBJECT_DATA). Invalid command:  exec dbo.pWorkstationStatus_DATA

What exactly does this mean? How exactly did you do this? Did you ensure that the ResourceID counter was updated? Editing the database like this will like cause more problem than it solves.

Configuration Manager Properties/Actions Tab/Discovery Data Collection Cycle? I tried that, and it didn't work.
I've tried all the Actions.

The errors in the dataldr.log are pretty specific about what table a record is missing during an update. If SCCM needs to update a record that doesn't exist, why not create, so SCCM can update it?

When I uninstalled the client, deleted the smscfg.ini file from the client, deleted the device in SCCM, and reinstalled the client, I get a brand new ResourceID. I kept track of previous ResourceIDs, and deleted records associated with those old ResourceIDs.

I'm also having this problem with one physical machine, that has never been part of any kind of imaging process, and never had it's OS reinstalled.

The errors in the dataldr.log are pretty specific about what table a record is missing during an update. If SCCM needs to update a record that doesn't exist, why not create, so SCCM can update it?

When I uninstalled the client, deleted the smscfg.ini file from the client, deleted the device in SCCM, and reinstalled the client, I get a brand new ResourceID. I kept track of previous ResourceIDs, and deleted records associated with those old ResourceIDs.

Because updating a single table will not update everything that is need. Then you will get into interesting issues where the wrong ResourceID is populated for different computers.

Running the Heartbeat discovery (discovery data collection cycle) should solved your problem by create creating the PC within CM12. if it doesn't then you have a bigger issue and you need to dig deeper into the logs to find out why.

I would start by tracking the DDR fro the computer to the MP then to the inboxes and finally into the db. This will get you started. http://www.enhansoft.com/blog/troubleshooting-inventory-flow