Can't use SQL Filter on Custom Parser column


Author
Message
DavidL
DavidL
New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)
Group: Forum Members
Posts: 6, Visits: 26
I created a Custom Parser for my log file and it seems to work well, except when I try to add a SQL filter.  It never returns any results if I try to use a custom column in the WHERE clause.  The custom column does show up in the "Available Columns" tab when I'm editing the filter, but when I click on the "Execution Result" tab, I get a warning that says, "No data found for field '<CustomFieldName>'". The "Test" button tells me that the SQL statemen parsed correctly.

What am I missing?





Replies
DavidL
DavidL
New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)
Group: Forum Members
Posts: 6, Visits: 26
I rewrote the parser to remove any "optional" fields and ensured that every field had a value.  It seems to work better.

I had a couple thoughts.  If I define some columns, but treat them as optional, meaning for some log entries I add the appropriate number of strings, but others I don't add all the strings, could that result in the behavior I was seeing?

I would assume that if there is string data in the column, that all of data the column would be treated as strings.  Is this not the case?

What if the log file starts with a bunch of lines that don't parse using all the columns.  You said that LogViewPlus looks at the column data "statistically".  Could it look at the first bunch of lines, not see data in the columns and assume there is no data at all?

Related, but how does the SQL filter handle null or empty values?
Edited Last Year by DavidL
LogViewPlus Support
LogViewPlus Support
Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)Supreme Being (12K reputation)
Group: Moderators
Posts: 1.2K, Visits: 4.3K
Glad to hear the behaviour is looking better.

LogViewPlus doesn't really do anything fancy when trying to determine the data type.  It tries to identify numeric data which can be parsed as a double or integer.  If this check fails, the data will be treated as a string.  For each column, LogViewPlus will check up to 2000 column entries regardless of the size of the log file.  For large files, these entries will be checked randomly.  For small files, all entries should be checked.

If LogViewPlus finds a lot of empty data values, the data type will be assumed to be a string.  However, LogViewPlus tries to be fault tolerant.  If a small number (currently this would be less than 5%) of empty values are found, these will default to a value of zero rather than treating the entire column as string data.

I suspect the problem here is with how your custom parser is providing data for the 'optional' columns.  LogViewPlus makes a core assumption that columns are not optional and are consistent for a given parser configuration.  Trying to work around this limitation may be causing the issue.  I can suggest two alternatives to optional columns:

1. Provide a configuration flag to specify which columns should be included.
2. Include all columns for all requests.  Default data here should match a consistent data type of the column.  Data types should not change between instances.

Hope that helps,

Toby
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Login

Explore
Messages
Mentions
Search