invalid argument system runtime error on line with variable lookup

[Brian K. White]

----- Original Message ----- 
From: "Bruce Easton" <bruce at stn.com>
To: "filepro list" <filepro-list at lists.celestial.com>
Sent: Thursday, October 25, 2007 2:34 PM
Subject: RE: invalid argument system runtime error on line with variable 
lookup


> 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?
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.

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.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!