Resolved accidental V/I item import that resulted in hundreds of corrupt records

Hi,

Thought I would post this as an FYI that can hopefully be found if someone searches with a similar issue in future.

A client accidentally imported the XLSX version of their spreadsheet into CI_Item instead of their CSV. Normally V/I and the business logic would block this without a valid product line, except that the import was set up to automatically assign the product line. (It has since been altered to force them to put a valid product line into their spreadsheet so this can't happen again.)

The result is that roughly 450 complete junk records got imported into CI_Item and IM_ItemWarehouse, each. (Binary XLSX data was used, not text.) These items would appear in the item lookup, but were not selectable or deleteable through the regular panels. I could pull them into a Crystal report to at least ID them.

I considered and tried deleting them line by line, but Data File Display and Maintenance couldn't really handle a lot of them either, and would crash on many of the bad records. Never mind that I was trying to navigate to 450 records interspersed between over 20,000 valid items.

I considered dumping the table to Excel and cleaning it up from there, then initialising the file and importing back, but wasn't 100% certain I'd get the data back in exactly as it was. At the very least I'd mess up DateCreated/Modified values. I vaguely recall there being other problematic read-only fields too from past experiences. I'd still have to deal with IM_ItemWarehouse too. (I was under the impression that recalculating Item Transaction History should have recreated IM_ItemWarehouse, except that I just got a blank file.)

Finally the solution came to me, and it was ridiculously simple -- rebuild key files on CI_Item and IM_ItemWarehouse. It just removed all the records with illegal characters and left the legit data intact. Some bad records remained because they happened to randomly use regular letters and numbers, but those were then easily identified with a query and deleted manually from DFDM.

Hope that helps someone!