OK, so today I confirmed that you can in fact export data from the 
Windows event log into a plain CSV file. Which is great.

(Unfortunately, sometimes event descriptions contain line breaks, which 
is not so great.)

Anyway, I wrote a small Haskell program that deletes any multi-line 
events, and then another which grabs only the events I care about and 
does some trixy parsing of the event description to pull out the data I 
actually want. The result is a big CSV file containing a list of printer 
events - date, time, user, printer and page count.

(There is *one* event in the log that says something like "document %4 
was printed on %6, byte count: %7, page count: %8". Which is really not 
especially helpful...)

So now I have a CSV file that contains the date, time, user, printer and 
page count. Just import that into Access and produce some stats, right?

Wrong! Access apparently can't parse any of the dates. Despite them all 
being perfectly valid dates (and it even *detects* that this column 
should be a date column), it fails to parse every single last one. >_<

So I used Haskell (which is really the wrong tool) to produce some 
statistics the hard way - by manually scanning the CSV file, reparsing 
the data and writing the results into yet *another* CSV file.

And now, finally, I have a chart showing me how many pages each printer 
printed on a given day. Which is all I wanted in the first place!

Mmm, apparently that printer in the corner hasn't printed a single 
damned page since July... Yep, it's definitely spare. :-)

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4b16914f$1@news.povray.org...
> OK, so today I confirmed that you can in fact export data from the Windows 
> event log into a plain CSV file. Which is great.
>
> (Unfortunately, sometimes event descriptions contain line breaks, which is 
> not so great.)
>
> Anyway, I wrote a small Haskell program that deletes any multi-line 
> events, and then another which grabs only the events I care about and does 
> some trixy parsing of the event description to pull out the data I 
> actually want. The result is a big CSV file containing a list of printer 
> events - date, time, user, printer and page count.
>
> (There is *one* event in the log that says something like "document %4 was 
> printed on %6, byte count: %7, page count: %8". Which is really not 
> especially helpful...)
>
> So now I have a CSV file that contains the date, time, user, printer and 
> page count. Just import that into Access and produce some stats, right?
>
> Wrong! Access apparently can't parse any of the dates. Despite them all 
> being perfectly valid dates (and it even *detects* that this column should 
> be a date column), it fails to parse every single last one. >_<
>
> So I used Haskell (which is really the wrong tool) to produce some 
> statistics the hard way - by manually scanning the CSV file, reparsing the 
> data and writing the results into yet *another* CSV file.
>
> And now, finally, I have a chart showing me how many pages each printer 
> printed on a given day. Which is all I wanted in the first place!
>
> Mmm, apparently that printer in the corner hasn't printed a single damned 
> page since July... Yep, it's definitely spare. :-)

Have you tried importing your CSV file into Excel first, then moving it to 
Access? I've found that it sometimes does better with external data. It's an 
extra step, but it may give you cleaner data, and may make the process 
easier to do the next time, if there is one.

--
Jack

Post a reply to this message

>> So now I have a CSV file that contains the date, time, user, printer and 
>> page count. Just import that into Access and produce some stats, right?
>>
>> Wrong! Access apparently can't parse any of the dates. Despite them all 
>> being perfectly valid dates (and it even *detects* that this column should 
>> be a date column), it fails to parse every single last one. >_<
> 
> Have you tried importing your CSV file into Excel first, then moving it to 
> Access? I've found that it sometimes does better with external data. It's an 
> extra step, but it may give you cleaner data, and may make the process 
> easier to do the next time, if there is one.

I did notice that Excel apparently had no difficulty with the date 
column - or indeed any other column for that matter. So maybe that would 
work...

Post a reply to this message

Invisible wrote:

>>> So now I have a CSV file that contains the date, time, user, printer and
>>> page count. Just import that into Access and produce some stats, right?
>>>
>>> Wrong! Access apparently can't parse any of the dates. Despite them all
>>> being perfectly valid dates (and it even *detects* that this column
>>> should be a date column), it fails to parse every single last one. >_<
>> 
>> Have you tried importing your CSV file into Excel first, then moving it
>> to Access? I've found that it sometimes does better with external data.
>> It's an extra step, but it may give you cleaner data, and may make the
>> process easier to do the next time, if there is one.
> 
> I did notice that Excel apparently had no difficulty with the date
> column - or indeed any other column for that matter. So maybe that would
> work...

If all you have is Haskell, every problem starts looking like an erm... that 
self-functor (or whatever) thingy.

-- 
Stefan Viljoen

Post a reply to this message

>> I did notice that Excel apparently had no difficulty with the date
>> column - or indeed any other column for that matter. So maybe that would
>> work...
> 
> If all you have is Haskell, every problem starts looking like an erm... that 
> self-functor (or whatever) thingy.

Well, it *did* solve the problem, didn't it? :-P

I could have spent more time fiddling with Access to coax it into 
working, or I should do what I did: produce a solution that works right now.

Now, if I knew a lot about Access and very little about Haskell, the 
most efficient solution might have been different... ;-)

Post a reply to this message

Invisible wrote:

>>> I did notice that Excel apparently had no difficulty with the date
>>> column - or indeed any other column for that matter. So maybe that would
>>> work...
>> 
>> If all you have is Haskell, every problem starts looking like an erm...
>> that self-functor (or whatever) thingy.
> 
> Well, it *did* solve the problem, didn't it? :-P

Haha yes, granted, a solution that works is what you want. :)
 
> I could have spent more time fiddling with Access to coax it into
> working, or I should do what I did: produce a solution that works right
> now.

Exactly!
 
> Now, if I knew a lot about Access and very little about Haskell, the
> most efficient solution might have been different... ;-)

Probably, though as another poster said, the first thing I'd have tried is 
"piping" the file through Excel.

-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen wrote:

>> Now, if I knew a lot about Access and very little about Haskell, the
>> most efficient solution might have been different... ;-)
> 
> Probably, though as another poster said, the first thing I'd have tried is
> "piping" the file through Excel.

And that would have been because I don't know squat about Haskell. 

After that, (if Excel didn't solve it) I'd have tried a commandline PHP 
script. Again the "hammer-nail" paradigm. I guess most people will use the 
tool or language they know best to solve a problem in the quickest, most 
direct way.
-- 
Stefan Viljoen

Post a reply to this message

Invisible wrote:
> I did notice that Excel apparently had no difficulty with the date 
> column - or indeed any other column for that matter. So maybe that would 
> work...

It would seem to me that the appropriate solution is to add up the columns 
appropriately using excel.  Adding up columns is kind of what it does best, 
after all.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> I did notice that Excel apparently had no difficulty with the date 
>> column - or indeed any other column for that matter. So maybe that 
>> would work...
> 
> It would seem to me that the appropriate solution is to add up the 
> columns appropriately using excel.  Adding up columns is kind of what it 
> does best, after all.

Well, I'd like to be able to sort and filter the data and so forth - 
Access is specifically designed to be able to do that kind of thing, 
whereas Excel makes it a bit tedous.

By the way... I just realised. While you *can* move data between Excel 
and Access easily enough, there isn't actually a way to run a query in 
Access and get a chart as the result. I never thought about it before. 
But you'd have to run the query, copy the data, paste it into Excel and 
then fiddle about with chart options. There isn't a button in Access 
that says "please plot this as a pie chart" or something...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Stefan Viljoen wrote:

> After that, (if Excel didn't solve it) I'd have tried a commandline PHP 
> script. Again the "hammer-nail" paradigm. I guess most people will use the 
> tool or language they know best to solve a problem in the quickest, most 
> direct way.

And, no doubt, you actually have the PHP interpretter installed, whereas 
I only have a Haskell interpretter. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message