The Danger of Do Loops

If you're going to write a Do Loop, don't forget to update whatever it is you're using to break out of said loop. And, oh yeah, save before testing!

The Danger of Do Loops

When using "Do Loops"--such as Do While ... Loops, Do ... Until Loops, or (the syntactically superfluous) While...Wend Loops--you need to be careful to avoid accidentally getting stuck in an infinite loop.  

Francesco--whose "Looping by Month" solution I referenced in yesterday's article--accidentally bumped into this himself when he was testing his function:

I appreciate the honesty, Francesco!  

Infinite loop fallout

Coincidentally, I did the same thing later that day while working on an entirely different piece of code.  In fact, it was the sample code I was writing for a different article about using a monthly lookup table to loop by month.  I had forgotten to add the .MoveNext line before I tested the function for the first time.

To make matters worse, there was nothing in the loop--such as a call to DoEvents--that was yielding any processor time.  That meant that it was impossible for me to break into my infinite loop.

Before writing an infinite loop and forcing yourself to kill the msaccess.exe process...SAVE YOUR CODE

Luckily for me, the only unsaved changes I had were to the looping code itself.  I took a screenshot of the code (now grayed out because Access was "Not responding") and killed the msaccess.exe process.  I then had to retype the function by hand (and add in the .MoveNext line!) before I could test it again.  

The simple mistake cost me maybe two minutes of my time. However, if I was four hours into a flowing code session where I was writing so much code so quickly that I wasn't even stopping long enough to eat, drink, blink, or, you know, save my code, then the same simple mistake could have cost me days of time.

(Wait a minute.  Days?!  After "only" going four hours without saving?
Yes. Days.  I'll write about why that is in a future article.)

Image by Mari Carmen Díaz from Pixabay