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
