You’ve been using computers for quite some time, I’m guessing. You’ve worked in dozens, scores, maybe hundreds of different programs. And in every one of them, when presented with buttons that say OK and Cancel, their behavior is generally consistent. OK commits whatever changes you just made and Cancel discards them. And by “discards them” I mean leaves you in the same exact state as before you went into that dialog or form and started making changes.
That is, unless you’re working in Centricity.
Specifically I’m referring to this dialog:
You see that Cancel button I’ve so subtly highlighted? You know what it does? It deletes everything in that grid.
Let me repeat that. This is a Cancel button that not only discards any changes you may have made during that session, but deletes everything. Simply by opening the dialog, saying, “oh this isn’t where I want to be,” and clicking Cancel, you just wiped out possibly weeks worth of work. I would be delighted to give you all the time you need to let that sink in.
To put this into perspective, understand that software developers generally don’t build most of their controls (e.g., buttons, grids, dropdowns, etc.). Sure, they’ll occasionally need some kind of custom control that’s specific to the needs of their application. But most of the time, they dip into a toolbox full of pre-built controls that are provided with their development environment. This is certainly true of something as utilitarian as OK and Cancel buttons. And in every dev environment in the world, a Cancel button does just that – it cancels. You would have to intentionally go into the code behind that button and write an incredibly destructive piece of code in order to accomplish what takes place in this form. Have I used sufficient text formatting to get across how completely stupid this is?
Our team discovered this over three years ago in CPS95. We have an SPR# for it. And it has yet to be fixed. This is a data destruction bug that requires the removal of code from a Cancel button, and they still haven’t found the time to address it. They did make the app a lovely shade of blue, though, so at least we have that.
The last time this button was inadvertently clicked, over a year ago, it sent one of my coworkers into a fit of tears. Can’t have that. Ten minutes worth of Profiler time in the dev environment later, and I had learned enough to put this in place:
CREATE TRIGGER [dbo].[cus_trNoDeleteOnInsuranceCarriersOrdersApprvProv]
INSTEAD OF DELETE
SET NOCOUNT ON;
-- Do nothing
PRINT 'Deletion has been disabled via trigger.'
Yes, it’s a trigger, and I usually frown upon those. But in this case we’re talking about patching a data destruction bug. I’m okay with it.
I also collected the results of my Profiler traces and the trigger, and sent them off to GE, who looked at them and said, “huh, whadda ya know.” As far as I know, this fix is still not on the list for 12.1, but did we really expect it to be?