January 7, 2020 at 12:00 am
Comments posted to this topic are about the item A tale of updating a legacy system bug
January 7, 2020 at 5:31 am
This was removed by the editor as SPAM
January 7, 2020 at 8:44 am
I've had a few of these. The worse one was a deployment pipeline that rewrote the SQL scripts that it executed while attempting to police what it would and wouldn't allow.
As if that wasn't bad enough it enforced a 10,000 character limit on scripts.....most times. Different branches through the code had different script size limits. It was a pleasure to deprecate.
So many problems are caused by hard coding values into code. File locations are the worst. CPU cores are the worst too. Then anything else is a bit of a decline.
January 7, 2020 at 2:08 pm
My tale is not about SQL Server, but it's a similar story. About 30 years ago I added some new features to a Fortran program, "SLIDE 3 version# 1.9", that had been written by someone else. The first thing the program did when it was run was to print out the CHARACTER(20) variable that stored the program name and version#. Besides testing the new functionality, I ran a complete set of regression tests, fixed a few bugs I had introduced, and ultimately got it ready for production. Just prior to deployment, my boss told me to increment the version number to 1.10. I think you can see where this is going. I went ahead and changed the version number to 1.10 and deployed it to production without any further testing. After all, I only changed the version number. What could go wrong? Well it crashed the production computer due to a memory fault caused by a buffer overflow. The one extra character I introduced increased the size of the string from 20 to 21.
January 7, 2020 at 2:59 pm
I think that how one can be so greedy by not setting this field as, say, varchar(100) - so that you can be sure it's really enough.
that's why I just use varchar(max) for everything
[/sarcasm]
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
January 7, 2020 at 3:22 pm
Many years ago, SQL Server changed the definition of the bit data type from {0, 1}, which is what most of us older computer types would think a bit is, to an SQL definition {0, 1, NULL}. In our language. All datatypes have to allow a NULL. My client upgraded to the new release and his old code depended on the original bit definition, which would default to a one or zero. The code looked like very simple, very straightforward SQL, but now it was defaulting to NULL. This was a particular problem in anything that tried to do a COUNT().
Please post DDL and follow ANSI/ISO standards when asking for help.
January 7, 2020 at 3:29 pm
Yeah, that's what I always do /s
January 7, 2020 at 4:07 pm
Yeah, that's what I always do /s
Well in that case you must be working at a company which name starts with A and ends with ccenture, because I've seen some of your work at a client a few years back. 🙂 Up to that day I thought that " A<Company>ccenture only does nvarchar(max)" was a joke until I discovered it wasn't :-/
January 7, 2020 at 4:13 pm
What about the more insidious dependencies like the finance sql query that hard coded the product type and now one of the financial numbers is getting reported up understated but no one has assumed the number is wrong so no one reported it to IT. These can last for months and some are never found. Some can cause legal liability later when it’s discovered that the numbers have been wrong. Assumptions about the safety of a change like this are unwise. Gather the data before making the change. At least set up a query audit for the table and make a more comprehensive list of what downstream dependencies may exist and research them. It’s worth the time to do it right because the cost of NOT doing this is unpredictable.
January 7, 2020 at 4:15 pm
sektor81 wrote:Yeah, that's what I always do /s
Well in that case you must be working at a company which name starts with A and ends with ccenture, because I've seen some of your work at a client a few years back. 🙂 Up to that day I thought that " A<Company>ccenture only does nvarchar(max)" was a joke until I discovered it wasn't :-/
Ha-ha)) It was a sarcasm, of course)) But I really do not understand why you didn't like my answer??? I didn't offer using varchar(max), but just to make it a bit longer, which wouldn't hurt the database. D'ya agree? 😉
January 7, 2020 at 8:02 pm
I've only been in IT for 15 years and at the ripe age of 48, I know that's a very short time for many of you, but I've learned way too many times that there's rarely such a thing as a "quick and easy" change. It's awesome when they work immediately and it's even kind of fun to track down the ones that only cause a small problem (kinda like you describe in your article) but when it's a live system and things aren't working, it's just WAY too much stress. I've learned to overthink everything before I pull the trigger and even then I miss things.
Edit: Good story, BTW. Thanks for sharing. Good to know I'm not alone in the trenches.
Edit2: LOL, reread the first edit and I might as well have said, "misery loves company". 😛
January 8, 2020 at 8:53 pm
>> I've only been in IT for 15 years and at the ripe age of 48, I know that's a very short time for many of you,.
LOL! I have socks that are older than you! And God help me. I'm still wearing them! My first paying job in IT was in 1965.
>> but I've learned way too many times that there's rarely such a thing as a "quick and easy" change. <<
Oh, grasshopper, you are wise beyond your years << insert yoda face>> 🙂
Actually, this is one of the basic laws of systems engineering, which is usually phrased as, "in the system. You cannot change just one thing." It is based on the fact that a complex system, things are interrelated.
Please post DDL and follow ANSI/ISO standards when asking for help.
January 9, 2020 at 1:25 pm
>> I've only been in IT for 15 years and at the ripe age of 48, I know that's a very short time for many of you,.
LOL! I have socks that are older than you! And God help me. I'm still wearing them! My first paying job in IT was in 1965.
>> but I've learned way too many times that there's rarely such a thing as a "quick and easy" change. <<
Oh, grasshopper, you are wise beyond your years << insert yoda face>> 🙂
Actually, this is one of the basic laws of systems engineering, which is usually phrased as, "in the system. You cannot change just one thing." It is based on the fact that a complex system, things are interrelated.
Joe,
Thanks for the confirmation. It's always comforting hearing that I'm "on track" with my thinking, especially from one of the big names in the career field. I appreciate what you do...maybe even as much as you appreciate well-worn socks. 🙂
January 9, 2020 at 2:14 pm
Gold toe, always go for the gold toe
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply