We had recently a "nice" issue on live environnement : instead of purging old orders, they have purged all orders after 1st january 2008... (ok you can laugh, but was not me...)

Instead of recovering from the database backup the customer decided to reimport them from SAP using the usual $BatchLoader. So all orders were recreated with a different $InternalKey.

Now, there are orders in $YourBigAppand and Orders in $OtherBigApp, they are the same but the $KeyNum referenced in $OtherBigApp is no longer the one of $YourBigApp. This is not yet an issue as there is no control on this field. However, there will be in the future a control on this field.

So the question is : can the $KeyNum that have been deleted be  reused in the futur for a different record ? We want to be 100% sure that the deleted $KeyNum will never be reused by the system. (I know putting the right $KeyNum in $OtherBigApp would be eayser...already explained this to the customer)

The ticket's from France. I know that France, like Belgium, uses the completely wacked-out AZERTY layout. I have tried to use these keyboards before and found it quite painful. The key just to the right of the left shift is the same, though, and I knew immediately what had happened:

Some genius decided to drop to a command line, connect directly to the DB, and do a massive global drop without first SELECTing the full dataset just in case someone might notice the DBA-typing-master-supergenius showing some sort of weakness in the form of self-doubt. So instead of issuing a command something along the lines of:
      SELECT * WHERE Master.Table.Data = (SELECT * FROM Master.Table.Data WHERE DATE > 20080101)

He let rip with:
      DROP * WHERE Master.Table.Data = (SELECT * FROM Master.Table.Data WHERE DATE > 20080101)

And he didn't notice that his finger had also contacted the shift key as he pressed the greater-than, slightly changing the intended query and command. Fuckwit.

Marie,

I have to say that you have a very... unique... definition of "nice". Rest assured I'm not laughing; just as on your AZERTY keyboard, it's quite easy to accidentally type a ">" instead of a "<" on my German QWERTZ keybaord.  Our $KeyNums are NEVER reused. In fact, a great deal are never used at all due to certain internal generation methods. For more detailed information, see my document, "Healthy Respect for Healthy $KeyNums Gives You Healthy Data".  Inserting the new $KeyNum into the $OtherBigApp record is indeed the best solution and fully supported. You should be able to batch the job but mind the shift key.  Regards,   REC

And that should've been it. And lo and behold, it was... almost.

Thanks a lot for confirming !!! I just told it 3 times to the customers but they did not beleave in it. I think it is the biggest bullet I saw in my career.

I would never understand how they could realize it only one day later...

Thanks for giving my the reference. I searched for it but was not able to find it. I really dislike this new µù%$£! support web site (µù%$£! stands for some word that a polite woman is not suppose to use!)

kind regards

Marie

A fucking human! I was actually, truly, unmistakably communicating with a human being! A competent and friendly one, at that! That's my 2008 quota used up.

Root Cause: 6-Customer Error. If it'd been the fucking bozo who actually did the drop then yes, there'd be five internal notes appended demanding my Root Cause: 17.