Code Error

You know, in the world of programming, there are things that are nothing short of frustrating. I know that people who don't dig into computer code find it to be something daunting, but once you know one language, they all kind of fall into place, and work almost exactly the same way. It's all about simple logic. When you find situation A, do action B. The trick comes in finding the perfect logic that works every single time, and making sure you know the code you're writing in so that the program reading it understands what the heck you're trying to say.

In this particular instance, I had run up against a very strange error in which a date was being run through a subroutine that changed a blank field into the date 01002000, or January 0, 2000. Well, when a file containing this date went through an import process into another program, it caused the whole process to break down because that's clearly an invalid date, and the importing program knew it.

I know I just gave the whole problem, but finding the date was a needle in a haystack to begin with because that particular record was hidden deep within a file containing many, many other records, most with perfectly valid dates. Once the date was discovered, it was yet more research to figure out where it came from, and I eventually figured out that the system we were pulling the information from had a blank field where a date SHOULD have been.

So now, it came to finding out why something like this would happen. We knew it happened fairly often because this particular client had these import failures on a weekly (and sometimes more often) basis, and after they observed some of claims associated with these dates, they discovered that a date WOULD appear eventually, so we had to basically tell the system to make these records run again if this date came up.

After I found that I couldn't just pass a blank in that field, I decided to just use the date and set the record for pending, but then I had another problem. Once I coded in to set the claim for pending, I had some kind of code error. Now, this system uses a sort of "bastardized" BASIC language, which is the language I grew up on, but this thing was fussing about something invalid about the statement I'd put in there.

I read it and re-read it. I compared it to the rest of the file making sure everything in it was used somewhere else. I checked every character to make sure there was nothing funny about what I'd put in there, but it was all in vain. The stupid thing wouldn't run at all. What made it that much worse was I was controlling someone else's desktop, so they can watch me as I sit idle on this file. I had Optimus take a look. Still nothing.

Then I saw it. Foolishness washed over me. It was so simple that I should have seen it, but it was so easy to overlook. Here's what I wrote:

IF ($PaidDate == "01002000") THEN
SETSTATUS(Claims, PENDED, , , S12345)
//Back out and get the next claim
IF ( 0 == @ReturntoMainMenu() ) THEN
RETURN(0)
ENDIF
RETURN(1)
END IF

Can you see it? The comparison is right there. I'd even cut and pasted the "back out and get the next claim" part from elsewhere in the same file. The solution here is something that anyone with some simple observancy skills should be able to pick up on, and when I reveal the magic answer, if you haven't figured it out yet, you'll kick yourself. It's like a riddle where no knowledge of the subject matter is required for the solution.

Here's the correct version:

IF ($PaidDate == "01002000") THEN
SETSTATUS(Claims, PENDED, , , S12345)
//Back out and get the next claim
IF ( 0 == @ReturntoMainMenu() ) THEN
RETURN(0)
ENDIF
RETURN(1)
ENDIF

See it yet? All right, look at the ENDIF at the end of both of them. The first one has a space between the END and IF, which is correct for regular old BASIC, but remember that someone bastardized this verion, and the BASIC "END IF" is now ENDIF, as in one word, no space.

See? Now wasn't that a fun game? Stare at it for another fifteen minutes before it hits you, and then it's not fun anymore. Still kicking myself.