"The system is down!" cried the voice at the end of the phone. "We've run out of numbers!"

"You've… run out of numbers?" asked Daryl.

"That's what it says," the user lamented. "'You have run out of numbers. Contact support.' You're support, so fix it!"

Daryl pried more information out of the user. He asked important questions like, "What the hell system are you talking about?" and "Is it down down, or just not behaving like you expect?" and "Why on earth did you think I was the right person to call about this?"

The last question yielded the most useful answer. A year ago, the IT guy at a remote site up and left without notice. Since nothing broke, nobody bothered to replace him. Six months later, their database crashed and they didn't have a backup newer than the day the IT guy left. That little pile of fail cruised around the upper management level before dropping its payload of crap onto Daryl's head. He spent the better part of a week helping them reassemble their data from mostly corrupted redo logs.

Daryl hadn't thought about the primary rule of IT support: whoever touched it last owns it . Daryl was the last person to touch the app six months ago. Therefore, he owned it. With a heavy heart, he shouldered his burden and remoted into their systems.

A glance at the error logs pointed Daryl to table TBL14A_FX004B in the database. That table had a six digit ID column, and a quick SELECT MAX(id) showed him that they had hit 999999. Sure enough, they were out of numbers.

There was no documentation. Daryl was tempted to try increasing the size of the column, but had no idea what he might break. He didn't really understand what data was actually in there, since most of the records appeared to be meaningless glop. Daryl talked to other IT folks, his managers, their managers, the guy who had been with the company 40 years and had worked on every application at one point in his career, but no one had any idea how this application worked.

The only good news was that, after the IT guy left, no one was there to delete his network drive. In fact, his old computer was still there on the network, sucking watts out of the wall outlet and adding absolutely nothing to the company's bottom line. Daryl held his breath, remoted in, and dove deep- past the MP3s, past the malware, past the gigs of porn, all the way to the bottom of the hard drive, where he found "FixOutOfNumers.sql".

Salvation! Daryl opened the file up, ready to proclaim victory. Instead, he found: DELETE FROM tbl14a_fx004B WHERE id >= 30000; --fix nuber issue. Daryl wasn't terribly confident in that particular solution, so after copying those records to a temporary table, he let the script run, and then checked with the user.

"Yep, we're good to go. Thanks!"

The users might have been good to go, but Daryl wasn't. He had just fixed something, but hadn't the foggiest idea of how or why- or what the consequences might be. He negotiated with HR for awhile and eventually got the last-known contact information for the old IT guy. He gave it a shot, and sure enough, the number was still good.

"Hahaha." The old guy didn't try to hide his amusement. "So you're the poor sucker that caught that turd. Yeah, I remember that- how could I forget. That table doubles as orders, employee info, and scratch space. All of the IDs between 1 and 199 are reserved for employees, 200-499 for product codes, and then everything up to 30000 for customer orders. Everything else is scratch space used by internal processes. You can just whack those records whenever. At worst, you'll just cause any running transactions to fail."

"And… what happens when we hit 30,000 orders?"

"Oh, I wouldn't worry about that," the old IT guy comforted Daryl, "unless they've started handling a lot more orders than they used to, there's probably another year before they hit that. There's a hidden screen in the application with a doomsday clock on it. You can check there."

Daryl checked the doomsday clock. Apparently there had been a little up-tick in business. They were already at 27,000 orders, and it looked like they'd hit 30,000 by next quarter.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!