|
|
It may be so that it lacks essential info to be able to extract useful info. For example, I use bytes sent and bytes received a lot. If it's possible to send me some example log files you're having problems with, I could take a look at the reason why it fails.
Not everybody has the same IIS logging settings, that's why SFWR uses the DLR to support this. Nevertheless, there were certain reports that threw exceptions and caused processing to halt because they expect certain data to be present (mainly bytes sent and bytes received). v1.3 uses a little Aspect Oriented Programming (AOP) to make sure all report calculation errors are handled. If you care to check it out again, I assume it works now.
There may have been another reason: SFWR is not able to deal with changed log formats within a single log file. For example, you're logging IIS data in one way, and then decide to remove some fields and add a couple of other ones. You can test this by running sfwr on a specific log file that you know didn't change it's format.
Just run it like this from the command prompt: sfwr.exe 100 c:\temp\logs If that doesn't work, there might be something special with your log files, and I'd be interested to take a closer look at them.
You're absolutely right. In a couple of days I'll create an update that corrects this issue.
The following reports no longer treat the user names as case sensitive: - Requests/User - Requests/User/Month - Requests/User/W eek - Unique Visitors