The Case of the Vanishing Data

We were testing an import routine the other day. It was nothing out of the ordinary, a simple tab delimited file which was being imported into a new OI table. The only tricky part (where tricky is a very loose term) is that the OI table required a multi-part key. The OI key was simply the first two columns of the imported data, and the customer wanted those fields stored in the data as well. Actually, calling it tricky is a bit dramatic. Let's say it was about as simple an import as you could want.

We test for a reason, and the initial run through of the code managed to import an empty key. Normally when this happens, a null key is created. However, because we used a multi-part key, a key of "*" was created.

Unlike working with null keys in the system tools, "*" has a length greater than 0, and could easily be examined by the system editor, which we did to ensure that the row was indeed empty. We then proceeded to use the File -> Delete menu option (or Alt-D, which was the actual keystroke hit) to remove the offending record. We then went on to check other records in the table to verify the import processes. Imagine our surprise that the entire file (about 6500 rows) was now empty.

We can only surmise the the code behind the system editor does not do something like

open fileName to handle then
   delete handle, id else
      * // Manage errors
   end
end

but instead must call

call delete_row( fileName, id, FALSE$ )

which in our case resolved to

call delete_row( "TEST_FILE", "*", FALSE$ )

and proceeded to delete all the rows in the table.