LAE

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: skim

BRE version: v 4.00 Build 234 Preview Release 5

The str_val is "20070717".

When I output the string value then use another filter to convert the date, it works. However, if I try to convert after trimming the data within the same node I get the following error:

[code:1]Invalid century " ". Fixed-century format requires two digits.
invalid date value: ' '
cannot parse value ' ' with format 'CCYYMMDD'[/code:1]

Same thing happens with time conversion from string value.

On a similar note, for some reason conversion to numeric (i.e. integer, float, etc.) types error as well when I something similar. For example:

code:
int(str_val.substr(0,8))
error:
could not convert to integer: ' '

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: bsmith

It appears that you may not be trimming the field before trying to do the conversion. Try and do this and let me know if you are still having problems:

[code:1]myDate = str_val.trim().substr(0,8).date("CCYYMMDD"�������� )

or

myInt = str_val.trim().substr(0,8).int()

emit myDate, myInt[/code:1]

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: skim

The "bug" is not what it seemed. The cause of the error was coming from the fact that emit section is evaluated before where section. For example:
[code:1] emit
date(str_val.substr(3,8), "CCYYMMDD")
where
isDate(str_val, "CCYYMMDD")
[/code:1]
input:
[code:1] HDR v1.0[/li]
DAT20070111
[/code:1]
I had expected where would be evaluated first, hence the first row will not be evaluated, but that was not the case. emit section attempted to evaluate the first row (which is empty) and failed before reaching where section.

Perhaps this can be a bug, a feature, or user training issue.

Post edited by: skim, at: 2007/08/06 03:09

Post edited by: skim, at: 2007/08/06 03:10<br><br>Post edited by: skim, at: 2007/08/06 03:17

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: tczotter

The "where" statement is evaluated at the point it which it occurs. If you placed the "where" first, it would be evaluted first.

However, the order of evaluation is irrelevent here as you did not use any variables.

What you're really saying is that you thought that the "where" statement prevents other statements, particularly emit, from being evaluated. It does not. All that where does is decide whether or not the output row should be sent to the output. You still build the output row no matter what. This is because there could be external side-effects (such as the manipulation of files or database rows) during the evaluation of your emit expressions. Deciding not to deliver the computed values has no influence on whether they are computed or not.

If you really don't want to evaluate certain expressions, they should be guarded by an "if". Emit statements cannot be guarded, so any expressions which need to be guarded should happen before your emit statement, using variables to hold any results from those expressions that may be needed in subsequent emit statements.