Would not it be nice, instead of writing your own log parser? Now it is possible! We took ORF’s reliable log parser from the Log Viewer, packaged into an OLE DB database provider and now you can read ORF logs as database tables from ADO or ADO.NET.
What it is good for? That only depends on you. You can import the parsed logs into SQL databases, generate weekly reports for the end users about blacklisted emails, write custom email notifications, use the logs as a feed for a custom blacklist, etc.
The provider is shipped with detailed documentation and examples in 12 languages/technologies:
- Microsoft® Visual C#®
- Microsoft® Visual Basic.NET®
- Microsoft® Visual C++®
- Classic ASP (VBScript/JScript)
- ASP.NET (C# and Visual Basic.NET®)
- VBScript (Windows® Scripting Host)
- JScript (Windows® Scripting Host)
- Borland® Delphi™
- PHP (Win32 only)
- Perl (Win32 only)
- Python (Win32 only)
- Ruby (Win32 only)
Get it today!
Thats pretty neat… But I think it might be a little more useful if it supported SQL statements.. Any possibily of just getting the log format in W3C or XML instead, and then LogParser would do all this and much much more. :)
What a coincidence, as it happens I was about to write a syslog listener service that would capture ORFEE logging to syslog and dump it into a DB. I would have set ORFEE to log to syslog.
Now what I will try do is to put the OLE DB into SQL Server as a linked data base. I will also resuse some C# compents I wrote that monitor the logging directory, and use directory update events to exec a stored proc that will copy the data into a DB table, and delete old log files once the stored proc catches up.
I have been getting ready for your proposed SQL Server option for configuration information.
I recently recycled a P4 computer after loading it up with 3gb of RAM and installing ISA Server 2006, ORFREE 4.0, SQL Server 2005 Express (chosen as it is free so what I develop can be shared).
SQL Server 2005 Express can be a replication subscriber for core configuration data that will reside on another SQL Server on the Exchange server box.
SQL Server 2005 Express cannot however act as a replication publisher for the Greylisting and Auto Sender Whitelist sets. It does however allow for merge replication back to the core SQL Server.
I will need to write something that broadcasts changes to these tables across to a peer running on another box as well as up to the core SQL Server. This will also resync the local SQL from the core on startup.
In summary I am looking at a service that does all of these things:
1. monitors change events in the log directory and fires a proc on the core SQL to upstream the logs.
2. detects when logs have been fully captured and delets them.
3. Subscribes to change events in the local SQL Server express then recovers the changes and broadcasts them to the peer as well as sending them up to the core.
4. Listens to changes from the peer and then inserts them locally.
5. Recovers missed changes from the core at startup.
Sorry for the late response.
Mike: SQL support could really make the provider better, however it would take enourmous amount of time (we need to write our own SQL parser) to develop and it would probably never be as powerful as even the Jet SQL dialect. What this provider is useful for is to import the data into an RDBMS and perform operations on the parsed data.
Allianz: Actually, configuration data will not be stored in SQL in 4.0, only specific databases (Auto Sender Whitelist and Greylisting).
I hope we can get Linked Data Source thing working, currently we are having some nasty threading model issues. I will contact you as soon as we find out something.
Pingback: Reading ORF logs using ADO/ADO.NET | Log Parser Watch
Pingback: Vamsoft Insider » ORF Log Provider Update (1.2 Beta)