Calc Field validates but data table doesn't display due to non-mandatory in view
Resolved
This issue occurs when the table is not made mandatory. I'm clearly using it in a calculated field. When I checked "Mandatory" checkbox it worked.
Files:
Weird Calc Fiel...
Hi Larry,
Unfortunately this is expected functionality. If the table is not forced into the report's SQL in some way, a syntax error will be thrown.
Your other option is to include a field in this report that is from the table being referred to in your query, so that the table is automatically included in the FROM clause.
Bit of an explanation:
Standard calculated fields have a lot more functionality underlying them, which allows the report builder to say "okay, this function refers to these two fields, which means that these tables are needed so lets make sure that is reflected in the query"
Freehand is more open ended, so all that happens behind the scenes is:
"okay they gave me a statement that works so I am going to throw it into the current SQL query and assume they knew what they were doing enough that it will work on its own"
The potential complexity of freehand calc fields means that a lot could go wrong if we did try to parse out used tables, so I am doubtful this will change in the near future.
Let me know if this makes sense, and sorry for the troubles.
Nathan
Hi Larry,
Unfortunately this is expected functionality. If the table is not forced into the report's SQL in some way, a syntax error will be thrown.
Your other option is to include a field in this report that is from the table being referred to in your query, so that the table is automatically included in the FROM clause.
Bit of an explanation:
Standard calculated fields have a lot more functionality underlying them, which allows the report builder to say "okay, this function refers to these two fields, which means that these tables are needed so lets make sure that is reflected in the query"
Freehand is more open ended, so all that happens behind the scenes is:
"okay they gave me a statement that works so I am going to throw it into the current SQL query and assume they knew what they were doing enough that it will work on its own"
The potential complexity of freehand calc fields means that a lot could go wrong if we did try to parse out used tables, so I am doubtful this will change in the near future.
Let me know if this makes sense, and sorry for the troubles.
Nathan
Replies have been locked on this page!