Tuesday, February 05, 2013 2:25 PM
Set objFile = objFSO.OpenTextFile(strPath & "\Agg_Data.csv", ForReading) Do Until objFile.AtEndOfStream strLine = objFile.ReadLine If Mid(strLine, 1 , 1) = ">" and Mid(strLine, 1, 5) <> ">,SN#" Then RecordCount = RecordCount + 1 LineSplit = Split(strLine, ",") If IsDate(LineSplit(1)) and LineSplit(1) > LastStamp Then LastStamp = LineSplit(1) End If ' If Not IsDate(LineSplit(1)) Then ' MsgBox "WTF?" ' End if End If Loop
I thought this was simple, I'm blown away this doesn't work.
I Dim Laststamp, and assign it a value of "01/01/2008" knowing this is earlier than the data in the csv could possibly be.
The csv is a logfile each record consists of 3 lines I structured specifically to work with parsing tools I wrote.
The records start with a record header:
The next line is the line containing the date, and looks like this:
">,1/9/2013 9:50:35 AM,data,data,data,<"
The last line contains more data, but looks like this so you can see why the code above is written like it is above...
Looking at the code above you can see I reject the header since it doesn't start with ">", and I reject the last record line since that DOES start with ">,SN#".
The commented out part was a test to see if the LineSplit(1) was EVER not a date. All 551 records past this test, if I append any alpha to the front of the date it "breaks the date recognition anf give me the WTF? messagebox, so I KNOW my dates are solid...
The intent is to run this against the csv, and see in milliseconds if there has been a record generated since the last time I processed the data.
And, it works perfectly until the next record has a date that is older than the last date, in which case it appears to bypass all subsequent processing and goes straight to the end. It counts the records perfectly, it just stops updating "LastStamp" the first time a new record is older than the last update.
Example dates: (Held in LineSplit(1))
1/7/2013 9:39:47 AM
1/7/2013 9:41:12 AM
1/7/2013 9:45:43 AM
1/9/2013 10:01:23 AM
1/9/2013 10:19:03 AM <-- this ends up being the "final" record timestamp, even though there are records up through 2/4/2013 further down the log!
1/8/2013 11:39:17 AM <-- this "older" record appears to break all further processing, it doesn't see the record below this one.
2/4/2013 10:13:29 AM
So, I'm completely lost. Any clues?
Thanks in advance...
- Edited by Win7Tester Tuesday, February 05, 2013 2:29 PM clarification
Tuesday, February 05, 2013 3:14 PM
Comparing strings and comparing dates is not the same thing. Try this variant of your code:Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("d:\test.txt", 1)
LastStamp = CDate("01/01/2008")
RecordCount = 0
Do Until objFile.AtEndOfStream
strLine = objFile.ReadLine
If Left(strLine,1)=">" And Left(strLine,5)<>">,SN#" _
Then RecordCount = RecordCount + 1
LineSplit = Split(strLine, ",")
If IsDate(LineSplit(1)) And CDate(LineSplit(1))>LastStamp then LastStamp=CDate(LineSplit(1))
- Edited by OberwaldMicrosoft Community Contributor Tuesday, February 05, 2013 3:15 PM
- Marked As Answer by Win7Tester Tuesday, February 05, 2013 3:37 PM
- Edited by OberwaldMicrosoft Community Contributor Tuesday, February 05, 2013 4:14 PM
- Edited by OberwaldMicrosoft Community Contributor Tuesday, February 05, 2013 4:15 PM
- Edited by OberwaldMicrosoft Community Contributor Tuesday, February 05, 2013 4:16 PM
Tuesday, February 05, 2013 3:16 PM
Clear as mud.
Why not just state what you are trying to do. Forget about how, Just a simle statement of function.
Tuesday, February 05, 2013 3:28 PMModerator
The code seems to work for me, using your sample data. I personally would convert the dates to datetime values, using the CDate function, to avoid comparison as strings or numbers. However, the code still worked, possibly because the time values forced VBScript to convert into datetime values. The string "1/1/2008" would otherwise be interpreted as a number, where "/" means divide.
Richard Mueller - MVP Directory Services
Tuesday, February 05, 2013 4:09 PM
Thanks Oberwald! (and to Richard for reinforcing the CDate determination).
I was prepared for a simple solution (it being little more than a huge oversight on my part) but when it worked for the first 37 records I thought I was golden with the original code.