How many of you have ever run a database query with the wrong parameters and produced a report that you sent to fulfill a request? How quickly did you send another note to ask the report be discarded as a new one was coming? Probably a few of you. I know I have been in that situation during my career. If not a bad query, perhaps some of you incorrectly gathered data from other sources or made the mistake of killing the wrong session or updating the wrong data. Database errors occur, and often we have to decide how to pick of the pieces from a mistake.
Recently there was a fairly high profile database query error with Southwest Airlines. Apparently a mass email went out to let customers know they had been awarded the valuable “Companion Pass” from the company. Many customers with a heavy travel schedule aim for this to allow a companion to travel for free with them. After receiving the email, many contacted the company as they didn’t expect the award. As someone that travels a lot, I know most of us do know exactly when we achieve some status and when we’re short of the level.
Southwest admitted this was a “database error” and gave away a few coupons to customers, but this an embarrassment as well as an annoyance for customers. Most probably got the notice and didn’t feel bad when it was taken away, but a few people were probably close enough to try to change plans and book another person, only to find they weren’t getting a reward. I know, this is a first world problem, but still somewhat embarrassing for Southwest IT.
I doubt this was a database error, unless a DBA updated some rows incorrectly. That’s certainly possible as an UPDATE with the wrong (or missing) WHERE clause is a common occurrence. My guess is that this was likely either a bug in some software that posted mileage completed or it was a poorly written query used to send out emails to customers. In any case, this likely wasn’t a big issue, but it is something that has occurred before. Sometimes with worse consequences.
There will always be data entry errors, and certainly query mistakes in what we run. I don’t know of how we’ll eliminate more of these mistakes, other than to create more alerting that looks for anomalies and let’s someone know to double check that the values are correct. Actually, to me this is one area where AI is useful. It can detect things that look wrong, as it does with spell check or next word suggestions, and then let a user decide to keep or change the data. That might be something we would appreciate in SSMS. It could offer to correct my “selcet” to “select” while also letting me know that setting a price to $150 might be wrong when all other prices are $1500 or greater.
Listen to the podcast at Libsyn.