Strange View behavior

[k2a]

Hi there,
In an application a report no longer runs, probably caused by a system crash. I trace the problem down to a view used by this report.
In that view, a filter variable “?vp_periode” is used which causes the following error message: “operator/operand mismatch°, but if that variable is changed to such as “?vp_period” the view works correctly.
Any idea what might cause this strange behavior?
Regards Klaus

 

[Olaf Doschke]

View variables have to be declared and set to a value as necessary for how they are used before you USE the view.

If this worked you would always have a variable vp_periode defined. If rephrasing the view SQL to vp_period works, then you must have changed the names of variables you create before view usage.

And just by the way, a view does not define variables, it makes them to prerequisites. As you say a report uses this view, they might be report variables but could also be variables in the code running the report.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[k2a]

Yes, I know that, but I forgot to mention that the view was executed in the View Designer and there you type in the value. In the mean time I found out that the index of the table used in the view was corrupted. The view run fine now with 'vp_periode'.
Unfortunately my report still doesn't work. If used in the report designer the value for 'vp_periode' is requested, but after the input the error appears "variable 'VP_PERIODE' is not found".
As far as I know is it not possible to debug a report with the debugger. Any idea to investigate the report?
Regards Klaus

 

[Olaf Doschke]

Well, the report asking for the variable value with a popup like the view designer is surely never intended.

This report only works, if you define the variable before you do the report. That's all to it.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Some afterthoughts:

If you think defining the variable in the designer makes it part of the view definition: That's not the case, that's always just temporary. If a view is parameterized the variables have to be set before each single usage.

And as it's very unlikely the code worked previously without doing that, the only reason I see is a nam change with a replcement too, maybe with code references, that didn't go into the view definition itself, because they are not searched by that tool.

And I don't see how the report could purge a variable you predefine, but there can potentially be s code in the data environment methods and events if there is something as stupid as RELEASE ALL predefining variables doesn't help.

The scope of the variable could also play a role. Though I know some frameworks based on views do ask you to create private variables for their larger scope and visibility, views and a report can actually see local variables, too, though they are not part of the calling code, local variables are added to the scope of a report run. You can define these varaibles private to be sure they are visible to the report and view used by the report. To fail with "variable not found" then would be quite impossible to fail, if it's not addressing somehting else, like a field name that changed recently. When SQL does not find a field in a table you also sometimes get the misleading variable not found. Based on the name concept of VFP addressing fields like variables with a simple name, without alias/tablename prefix like table.field.

And as you had that strange thing working with vp_period instead of vp_periode that looks to me like there was some effort to rename things in the whole project. Bad idea, even with the full project search code references is. Some things are out of reach like view SQL definitions.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name