February 23, 2025 at 3:39 pm
Interesting story, Ryan, although a bit long. It reminds me of where I work, however often without a happy ending. We have a lot of applications which were written 10+ years ago. Many of these apps represent security risks because they rely on software packages that are out of date and some of those represent serious security risks. However, for some reason management isn't interested in upgrading these apps, leaving them as security risks. Management never says why they don't want to mitigate the security risks. And most of the developers aren't interested in upgrading them either. I get very concerned over these situations, but oh well, nothing changes for years. And when I offer to upgrade the vulnerable packages, I am ordered to leave everything alone.
So, it's like watching Trigger on the ground, knowing that he's going to die. Frustrating.
Kindest Regards, Rod Connect with me on LinkedIn.
February 23, 2025 at 5:34 pm
I once worked with an application that had only a few lines of code in a stored procedure that inserted a data item into a database table. There was then a chain of triggers, that updated just about every table in the database, there were so many triggers firing the database used to stagger while all the records were updated. The system had been around for several years and nobody in the company understood how it worked, but they continued to use it until something better came along.
February 24, 2025 at 10:05 am
Oh wow man. That's harrowing, at best. Fingers crossed for you and Trigg both.
And database triggers (mostly) suck.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 25, 2025 at 11:59 pm
I enjoyed the story and I didn't think it was long at all. It was just right. Thank you. 🙂
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply