I have to confess, I’ve no idea why today is called “Good Friday.” I’ve wondered that for years. But that’s another post for another blog, for another day, I suppose.
For now, I want to celebrate the joyous Easter coming.
And I have some reason to celebrate. Yesterday at work, I had some cool things happen, and only one bummer thing.
See, on Wednesday I had someone come to me and ask me if I could adjust one of the legacy intranet pages because it showed serial numbers for our return requests from customers. Some of our manufacturing divisions require a serial number before they’ll authorize a return. When we put that data into our system, it’s called up when we do prints of the requests. Long story longer, no matter how many serial numbers you enter, it shows up ten times. And, if you put in more than one, only the first one shows up…ten times.
An interesting conundrum. I found it more interesting when I learned my predecessor had been informed of the matter but never resolved it.
When I looked at the print page, I saw the matter. A loop was the problem.
(Aside: In programming-ese, a “loop” is a block of code which is executed multiple times, so instead of writing the code over and over again, you write it once and instruct the program to do it over and over until a condition is either satisfied or stops being satisfied.)
See, the loop was told to execute ten times. A counter was set to 1, and the loop was set to run until the counter became 11 (incrementing ten times). That same counter was used to extract the index number of the serial number data. So let’s say there are five serial numbers for five units being requested for return. The counter (called “x” in this case) was set to 1, like so: x=1 (complex programming code, eh?) Then the loop was told to run until x=11, like so: Do Until x=11 (wow! Can you handle that technical jargon there?!).
Okay, then the serial numbers were selected by saying “Put the serial numbers in this HTML table cell where the serial number = SN(x).” Then the counter gets incremented by one (“x=x+1”, more super-intense computer code), and the loop repeats. Got it?
So, for some reason (and I’m still not precisely sure why), the code never worked correctly. Instead of getting serial number index “x” like it was supposed to, it got the first one it came to and then repeated that cycle over and over again.
I knew what to do, though. And damned proud of myself I was for knowing! I changed the loop to say, “Do this stuff UNTIL THERE ARE NO MORE SERIAL NUMBERS, regardless of how many there might be.”
This is called a “Do Until” loop. Instead of saying “Do this until the counter is incremented ten times” (and ten wasn’t random; the page in which serial numbers are entered only has slots for ten of them), my code says “Do this until you don’t have any more records in the serial number spot” and then finishes. Got one serial number? It goes through the code once. Got ten? It goes through ten times. And, should I ever improve the page, if you input 40, you’ll get 40 out.
So I made the alterations and tested the code. It failed. Programming error. I left on Wednesday night feeling pretty dejected and stupid. I woke up a couple of times on Wednesday night – as is my habit, due to bladder requests or thirst or whatever – and every time I did awake, this problem was running through my head. I have no idea how that happens, but it happens occasionally. So when I woke up Thursday, I went to work thinking about the problem and still didn’t have any clue why my loop didn’t work and his did.
Feeling sort of inferior and humbled, I looked at the problem again. And I noticed something… a missing piece of the code. When I altered the loop, I forgot to tell the computer code to advance to the next record, if there is one, and do it again. When I added the simple line “recordset.movenext” to the code just before I told it to loop through again, BAM! Success! The page loaded perfectly and ran flawlessly, and ONLY shows the existing serial numbers once!
And now, it shows ALL the serial numbers, not just the first one over and over.
Okay, great, on I go. I spent the better part of last week working on two things: a NAFTA database macro which would automatically perform some tasks rather than having to perform those tasks manually, and a page which shows the number of times one particular customer is changing their orders. (The sales team for that customer, and the quality representatives for that customer, will be in our location for what’s called a “Kaizen Event” to improve quality communications. We’re using it as a chance to provide ammunition to our sales team to get the customer under control. Long story, but it’s something we have to do; their people can’t keep up with the changes being made, how are we supposed to do so?)
Well, I got the new web page built using the new, “better” technology, and tested it repeatedly. Then I set it aside. I finished it about 4:30PM last Friday, and figured I’d deploy it this week. Well, I sorta forgot, so when it came up again, I scrambled to get it uploaded to the web server.
And it bombed.
For the next two hours, I cursed, banged my desk, pulled my rapidly-graying hair, and stormed to the bathroom to fume. The test server simply won’t provide me with the error messages and I can’t remember what I did in production to get it to happen. So, flustered, I deployed the new application to production to see if I could find the problem.
I almost screamed it was so simple. So, I quick-fixed the issue and BAM! Success!
VICTORY! …and I copied the fixed version to the test server as a back-up and they’re working fine. The requestor is very excited to arm our sales team with this data next week, and I’m pleased it worked as intended. Phew! Close one!
Finally, time to turn my attention to the NAFTA database macro.
I still don’t know what’s wrong with it. So, two wins and a loss. In the grand scheme of things, I suppose that’s not too bad.
There’s always next week.
I hope you have a happy and joyous Easter if you’re celebrating, and I’ll see you Monday or thereabout.
God bless you.