Disclaimer: The story you are about to read is not only dangerous but stupid. Reading the following text may result in lowering your IQ. The names of companies and products have been changed to protect the attorneys from being sued by other attorneys. The usual disclaimers, exclusions, terms and conditions apply. Use at your own risk. Batteries not included. You’ve been warned.
TurboDouche Enterprises has a software product in use from a company named Sicromoft, which is called “Sysdom Sender Conflagration Mangler” . This product helps manage computer hardware and software inventory as well as deploy software and operating system images. One of the sites in the system hierarchy, a primary site, had a bowel explosion after a site reset. After mopping up with gas masks on, it was discovered that one of the logical “collections” has duplicate resources in the one labeled “Unknown Computers”. This is causing problems with targeting things at the collection by name, and the link is being assigned to a bogus clone, rather than a valid collection.
Looking inside the smelly SQL table named “UknownSystem_DISC”, they discover (pardon the pun) that the two default rows were duplicated and they need to remove the redundant rows.
They can sort the rows by creation date to push the original two rows to the top of the result set as follows:
select * from dbo.UnknownSystem_DISC order by Creation_Date0
To return all of the rows, excluding the original two rows, they can use the “offset” statement along with the number of rows to omit. They have to use a sorting statement as well, which they already did.
After drinking way too much coffee and staring at the results for way too long, they determined that only the first two rows need to remain. To achieve this Utopian ideal, they need to single-out the offending evil rows and destroy them mercilessly.
Since they only need to fetch one identifying column, they replace * (asterisk) with the identity column name (e.g. “ItemKey”)…
select ItemKey from dbo.UnknownSystem_DISC order by Creation_Date0 offset 2 rows
Now that they’ve confirmed the results are correct, they can simply delete them by wrapping the statement with a “delete from” statement…
Now we can re-run the first query to view the new result set…
As you can see, the evil, no-good, deadbeat, vagabond rows were annihilated by the forces of good. The darling angel rows were spared.
Keep in mind that if you have this issue with a particular primary site which resides under a central site, you will need to perform this at the primary level and central level afterwards, but modify the process to filter the results on the central by only the relevant primary site code.
IMPORTANT: This is for test/eval environments only. Never do anything unsupported by the vendor within a production environment. If you’re not sure, call the vendor. They might open a case and call you back with an answer within 48 hours or 2 business days, which ever takes longer. But whatever the case, never perform risky procedures in a production environment unless you’re sure you have a winning lottery ticket.