invalid argument system runtime error on line with variable lookup

[Bruce Easton]

Brian K. White wrote Thursday, October 25, 2007 4:28 PM:
> ----- Original Message -----
> From: "Bruce Easton" <bruce at stn.com>
>
> > Kenneth Brody wrote Thursday, October 25, 2007 2:17 PM:
> >>
> >> Quoting Bill Akers (Thu, 25 Oct 2007 12:33:08 -0500):
> >>
> >> > Bruce Easton wrote:
> >> >> I'm getting a filepro runtime error:
> >> >>
> >> >>  *** A System Error has occurred ***
> >> >>  on file: \dvr/filepro/DEUDAS/map
> >> >>  Line: 1407  invalid argument
> >> >>
> >> >> from an rclerk process (Windows fp ver. 5.07)
> >> >>
> >> >> where line 1406 and 1407 in the processing are:
> >> >>
> >> >>   If:
> >> >> Then: fileq = filen{"@"{qual{""
> >> >> ----- -  -  -  -  -  -  -  -  -  -  -  -
> >> >
> >> > This line with qual blank should be giving you fileq = 'filen@'.
> >> > You are probably looking for fileq = 'filen' without the @ symbol.
> >> > Some kind of conditional probably should be set to prevent the '@'
> >> > symbol from being set when qual is blank or perhaps to add '""'
> >> > after the '@' symbol when qual is blank.
> >> [...]
> >>
> >> A lookup to
>  "filen@" and one to "filen" are not the same thing.
> >>
> >> The former looks up to the non-qualified "filen" file, whereas the
> >> latter looks up to the current qualifier in the "filen" file.
> >>
> >
> > That was my understanding as well.  This particular program is
> > never called (from my scripts lines) with a qualifier (against the
> > file that I am running from), therefore, in my variable named
> > lookup expression, I intentionally use the "@" after the filename
> > expression, and *sometimes* append a qualifier to it (for the
> > file that I am lookup up to).
> >
> > This has worked fine under Unix with fp5.14.
> >
> > Also, if this is the problem, then wouldn't clerk at least
> > wait until the program got to the line to evaluate the lookup
> > before coming up with a system error?  I didn't get a syntax
> > error for it.
> >
> > Bruce
> >
> > Bruce Easton
> > STN, Inc.
>
> The only questions as I see it are
>
> First, What do you actually want when qual is empty, unqualified
> or current
> qualifier?
> Neither is incorrect, just, which do you want?

As usual, Brian - I want it all.

The objective here is to have a lookup that, when executed,
will lookup to a file where in some cases, I will have a
qualifier in "qual" and in other cases, I will not.  In other
words this program depends on that flexibility.

As I stated before, I'm never calling this program, which runs
from a control file, *with* a qualifier (via -m).  So I want
the filename to always be stated to filepro as name@ when I want
a lookup to the unqualified key of name and I want the lookup
filename to be stated to filepro as name at qual when qual has
something in it (same program used for both runtime situations).

As I said, running under Unix with filepro 5.0.14 allows me to
do this simply with:

fileq=filen{"@"{qual
lookup readd = (fileq)  r=rv -n

Sometimes qual contains "client"; sometimes it is blank -
no complaints from filepro under Unix w/filepro 5.0.14.

This only came up when I ported this software to Window
running 5.0.07.


> Then we can make sure that that and only that happens every time.
> The fact that "current qualifier" just happens to be unqualified at those
> times is irrelevant.

I do not call this process with a qualifier.

>
> Then, Assuming you want unqualified, does "fileq" have a declared length?
> As in, might (fileq) resolve out to ("file@    ") ?
> I'd insert a msgbox "fileq=\""&fileq&"\"" just before the lookup.
> Does lookup ... (fileq{"") ... fix it ?
> Even though you sucked in the spaces when filling fileq, if fileq
> itself has
> a length, then you may need to suck in the spaces also when you use fileq.

My original post does show that I could have (only) trailing spaces from:

filen{"@"{qual

but I have also tried previously filen{"@"{qual{""
and that produced no difference (still an error on 5.0.07 Windows and
still success on Unix 5.0.14).

Bruce

Bruce Easton
STN, Inc.