On one of the primary web applications I maintain we have real-time help available to clients through an online chat application.  Usually when one of the chat line workers gets an interesting bug report they IM me and I try to fix the problem.

For weeks now I have occasionally been getting questions about our date validation. Specifically, we have people entering today's date and getting told that the date they have to enter must be today or earlier.  We have about 35 places where you can enter a date and the business requirement actually is that the date entered be 'today' or earlier.  We validate this on the server side, but also on the client using the JavaScript function show below.

//Validate Past date

//---------------------------------------------//

function validatePastDate (control, sFieldName) 

{

    var c = document.getElementById(control);

    if (c != null ) 

    {

    //validate hasDate and isDate snipped//

        var d = new Date();

        var now = new Date();

        if(d.setTime(Date.parse(c.value, "n/j/y")) > now) 

        {

          sErr = sFieldName + " '" + c.value + "' must be a date earlier than today. \n"; 

        }

    }

    return sErr;    

}

 

Since the bug was opened in our issue database four different testers have tried to replicate it and none have been successful.  Yesterday I got pinged on IM and told that the 'funny date thing' was happening again.

I dropped everything and decided it was time to fix this once and for all.  I poured over the code, looking at the function and everywhere it was called.  No luck.  I ran it from my development box and from the beta server.  No dice.  I fired up an ancient desktop box that was kicking around and all of a sudden...ERROR!

Then I looked in the bottom right hand corner of the screen and noticed that it was 3:06 AM.  Bingo!  When I double-clicked the clock I discovered that the system date on that computer was 4/1/09, not 4/6/09.  It's clear now, but we all overlooked that

 

var now = new Date(); 

would report the client's system time to the client side validation...

I typically find myself using the Window Search all the time. It does a great job of finding files and documents by name, filtering the criteria by date or size, and I like having results in the graphical file explorer where I can sort by several attributes. If it could find my keys at 5:30 in the morning it would be the primary function on my laptop.

My recent experience with Search has been less satisfactory. I recently inherited several thousands of lines of HTML, asp, VB 6 and JavaScript code in hundreds of files that makes up a major portion of my employers web site. At the same time our database admins rolled out a new version of one of our primary databases that serves as a back end for several desktop and web applications. Unfortunately the web site wasn't checked thoroughly for dependency on the old database, nor compatibility with the new one. (That should be a topic for a whole separate stream of posts.)

Needless to say, this week has been one composed of frantic scrambling trying to figure out what was up and what was broken, and why. In a little bit of serendipity, I found that most of the applications used one particular configuration file in which was stored the connection information tagged with a label like 'ORA_CONNECT' (Nice job, previous developers.) When an application needed to connect it would call to the root config file and get the connection information by passing the label. Pretty standard stuff.

So, my first thought was to use the Windows Search to see if I could find all files that contained the string "ORA_CONNECT". So navigated to the root directory, fired up search, entered the parameters and waited with eager expectation after clicking on search. A long list of files came up, but shockingly it did not include the three files I had looked at by hand to determine what connection was being used.

Puzzled, I set up a little test. I created a directory with two subdirectories. In the root I put a text doc, and in the subdirectories I placed an HTML, ASP and MS Word file. Each file included text that contained the string ORA_CONNECT.

I ran search on that directory, and it found everything EXCEPT the use in the ASP page. I even went back and made sure that the All Files and Include Subdirectories options were enabled. Clearly Search was not reliable.

What will I FIND

I IM'd a co-worker about what I was tying to do, and he sent me a string using the FIND command. Ah Ha! Good old find! I had forgotten that since the last time I spent hours writing MS-DOS 5 batch files years ago. Oh No! Bad FIND...


As you can see from the image, access was denied to the subdirectories. FIND does not recurse. I knew I could write a batch to recurse the directories, and save the output to a file, etc, etc; but who has that kind of time?

FINDSTR /i /s ss64.com *.*

It was then that I remembered reading somewhere that there was a 'find' in windows that supported regular expressions like grep. I quick check of my links turned up the excellent site ss64.com - a command line reference site for SQL Server and Oracle, which just happens to have an XP/NT section.

The page on the FINDSTR command had just exactly what I needed:

Check out the command reference on ss64.com for other options, like printing the line and line number that match, and outputting the results to a text file.

This post was originally published on geekcyclist.blogspot.com on 10/5/2007