|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Leave positive messages for yourself to see regularly I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
To Inifinity and Beyond With 1=1 There is one thing that Aaron Bertrand won't get mad at me for doing and that's creating an infinite loop with a WHILE (1=1) pattern. He wrote about this recently in a tip, noting that it's easy to create an infinite loop with code like this, something that never ends well. I have written infinite loops in the past. A long, long time ago Radio Shack would put out TRS-80s on display, and a few of us would type a quick BASIC program to perform some math work on the screen over and over with an infinite loop. It often crashed at some point with an overflow, but for awhile it would look neat on the screen. Less neat to the salespeople who weren't always sure how to stop it and demonstrate something else without resetting the machine. I've also created infinite loops by accident at various jobs. Those experiences have left me a little concerned about any loop that doesn't have a defined time to end. I usually use a technique similar to Aaron, with a call that might repeat the entire process if more data needs to be updated when my current loop ends. There are plenty of people who spotted the error in the code and think they wouldn't create that problem in their looping code. However, I think few of us work alone on code for an employer, across time. Often someone else comes in to refactor or "improve" our code. The next person that adjusts this loop might join back to the main table and not realize they are creating an infinite loop. You'd hope they'd test this and find the problem, but I continue to see lots of "little fixes" deployed without being tested. This is one reason I want a DevOps style process for database code, complete with automated testing. If you write a piece of code, you are responsible for including a test in the pull request so that the CI system can verify your code passes the test. This isn't a perfect system and it might not prevent all bugs, but at least a test will exist and someone can then check both the code and test and perhaps use the issue as a teaching moment. We try and avoid loops in SQL Server, but that isn't always possible. As with most techniques in programming, we should strive to learn the best ways to use them, know the weaknesses, and avoid building code that has major flaws now. Maybe we also ought to add that we should ensure our code doesn't lead less experienced developers in the future to make simple mistakes. I'd say the 1=1 looping code does this and should be avoided. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
