BPSoftware.com

A few months back I made a couple of posts (Part 1, Part 2) regarding Microsoft’s LogParser. Since that time I have been getting my fair share of use from it. Recently, I had the need to analyze the Event Logs on a number of machines. There is the EventLog Snap-In for MMC; however this really doesn’t allow you to do more than basic viewing or broad filtering of events. (One thing I will give it is that it allows for the connection to the event logs on remote machines. Admittedly, I do have a saved console with about 5 or so machines that I browse through the logs of often.) Once again this Free Gem came to my rescue. One of the input sources of LogParser is the EventLog (EVT) Input Format. With LogParser you can select EventLog data (using a SQL like syntax) from a local or remote EventLog and output it to one of LogParser’s output format.

The EVT fields available for selection are EventLog, RecordNumber, TimeGenerated, TimeWritten, EventID, EventType, EventTypeName, EventCategory, EventCategoryName, SourceName, Strings, ComputerName, SID, Message and Data.

With these fields a number of data extractions can be put together rather quickly. Here are a couple of basic ones (The charts are the actual charts created by LogParser):

I have found the LogParser help file quite useful. There are plenty of examples, of which one explains how to do percentages.

I have also created an app using the EventLog Class that allows me to work with logs. This was my maiden voyage with this class and hopefully I’ll post on my experience shortly. I also hope to tighten it up for a more ‘universal use’ and post it for download.

The other day I had probably one of the better conversations I’ve had in a long time. The topic of the conversation was software development. This is one topic I could talk about non-stop and it also tends to bring out the conversationalist in me. The dialog was a friendly exchange was with a software developer that works primarily with development environments different from the ones I use (The opportunity to broaden horizons and discuss another viewpoint is one that I will rarely pass up).

In an effort to keep this short, the gist of the conversation focused on the concept that learning/understanding a development language (syntax) is similar to learning/understanding spoken language. This is a concept that I feel strongly about and fortunately, the other participant of the conversation felt as strongly as I do, leading to a very pleasant, yet intense conversation. Although it is possible, one does not typically memorize spoken language, rather they understand it, live it and feel it to a point where it becomes completely natural. Having an understanding of the concept of nouns, verbs and adjectives and the underlying knowledge of expression (a natural understanding of why and what to express) allows for the fluid ad hoc building of sentences and dialog. The ability to broaden one’s vocabulary also becomes easier. Memorizing what to say would result in a painfully drab and yet often out of place conversation.

Everyone has a ‘native tongue’, however the understanding and feeling of the basic concept of how to express oneself in certain situations allows for the cross-over of expression in other languages. Again, understanding (almost naturally) the concept of what to say allows one to figure how to translate that into another language for communication and expression of the concept. After all, most languages are similarly related and tend to result in the communication of expression. This same concept can be easily applied to software development environments/languages. Having a baseline conceptual (logical) understanding of what one is looking to achieve and how it all works is the foundation of developing an application; achieving a desired result, that can be built upon. With the understanding of the overall concept of what needs to be done (logically), a developer can generally search out the concept and find away to express that in another development language, whether it is Delphi®, Visual Basic, C, ASP, T/SQL, P/L SQL or whatever. After all, a development language is just that, isn’t it?

Well, enough of my rambling (I hope this makes enough sense to get some point across) for today I am off to play with some .NET EventLog stuff.

I've always liked those corny 'Easter Eggs'. In fine fashion some posts just can't go unreferenced. Take bring them back home! for example.