A community of more than 1,600,000 database professionals and growing

It's Friday the 13th, during the month of October. Halloween, a strange holiday associated with horrible events, and Friday the 13th, a bad luck day, are happening this month. Both are associated with horror movies, implying that this isn't necessarily a good month for the world. It's a double dose of bad luck, which is what Equifax would have you believe. I wrote about this yesterday, where the company would have you believe a single employee makes a mistake when a scanner fails, and hackers were ready to attack.

I've, in general, had a lucky career. I've worked hard, and things have gone my way. That doesn't mean I haven't made mistakes or systems haven't gone down, but overall things have gone well. As I think about Friday the 13th of October, I'm reminded about Murphy's Law, where things that can go wrong, may just do so. I've tended to expect that some things will go wrong and prepare accordingly. In fact, in keeping with a corrollary that I've sometimes heard to Murphy's law that if one thing goes wrong, I'd expect that something else will fail.

On this double downer of a day, I'm wondering if you've experienced that. Have you had something bad happen at work, only to find that overshadowed by something worse? Hopefully you didn't make a security mistake and then get hacked, but perhaps something else has broken?

In my career, I've had this happen, though not directly to me. I consulted with a small company to make a little extra money and because I liked their business. I was rooting for them to succeed and wrote some database code to help speed up their application. One day they call me to say that a drive array failed with the database mdf on it. I wasn't worried, and while in another state, I was ready to walk them through a restore process on the new array. Unfortunately, this was a default install, and the default backup path was on the old array. I hadn't set this up, nor was I aware of their backup process.

The lead developer was proud of himself. He'd made a backup the day before, using a file share on a network drive. He had the .bak file. I thought this would be a quick and easy call until he read the error message that not all media sets were provided. That's when I realized that the developer, while making the backup in SSMS, hadn't cleared the previous backup file from the dialog. He'd inadvertently created a striped backup.

Eventually they managed to locate a backup that was many days old. I'm not sure how far back, but they angered a number of clients, who I'm sure all started looking for a new vendor. Eventually the company failed, and I moved on. There wasn't much to be done in that situation, but it was a certainly double dose of things going wrong at the same time.

I hope few of you have had double the bad luck in your career, but if you can share a story, we're happy to commiserate with you.

Join the debate, and respond to today's editorial on the forums

The TODATETIMEOFFSET() functiont takes a datetime value and an offset for the timezone in minutes/seconds. This can be an integer for minutes or a string for hours and minutes.

Ref: Stairway to Advanced T-SQL Level 9: Compare, Modify, Derive and Validate Date and Time Values

TODATETIMEOFFSET - https://docs.microsoft.com/en-us/sql/t-sql/functions/todatetimeoffset-transact-sql

» Discuss this question and answer on the forums