EViews.com

Hi,

EViews does an unexpected substitution using the fetch or copy commands with series in remote databases containing the '%' symbol (fortunately, such series are not very common), if it contains within it the name of a control variable. Best viewed through an example.

The following: Will generate an error message: USCEN::DSR"TEST"D.Q was not found in "FETCH(D=USCEN) DSR"TEST"D.Q".

The '%y' of 'dsr%yd.q' has unexpectedly been replaced by the value of '%y'. The same happens using the copy command instead. A similar error would happen if '%yd' = "test"' was used instead of '%yd = "test"', since '%yd' is also included in 'dsr%yd.q', but defining '%ya' would avoid the problem. Isolating the request in a local subroutine doesn't help.

The only "solution" I've found is to avoid using control variables' names that would be a part of such a series name in the whole program. Not a major bug since it's relatively easy to work around, but I found it worth to submit it nonetheless.

Best regards,

Étienne

I forgot to mention that this happens in both versions 7.2 and 8.

Have you tried:

Thanks, it leads to a better workaround than making sure control variables names are not part of the names of objects that could be fetched, because the following works: with no curly braces around %x.

In the real world, in my programs, object names to import are almost always part of a list (a string of space-separated object names). If I have multiple objects within the list, omitting the curly braces around the control variable name will cause an error. For example,
will return an error, saying USCEN::"GDPR.Q DSR%YD.Q" was not found in "FETCH(D=USCEN) "GDPR.Q DSR%YD.Q".

The workaround seems to be to make a loop and fetch items separately, so I can omit the curly braces. This gives: It's somewhat slower than a single fetch request, but more robust.

Best regards,

Étienne

How about: (I have no idea if that will help or not, just throwing things out there :D)

The latter did't work, but thanks anyway.

Étienne