BASE/1003 Variable does not exist - Very weird!
Craig Jarvis
Hi All
This one REALLY has me!
I have an app which has been compiled in Clipper 5.2e, then 5.3, then
5.3a. All of a sudden, code which has been working fine for years
suddenly gives the above error.
The code is as follows: SET FILTER TO ModType=mType
The error: BASE/1003 Variable does not exit: MTYPE
mType is a local variable. The error messages guide talks about local
or static variables in a macro. Does this also apply to codeblocks? I
know that the pre-processor turns the SET FILTER into a DBSETFILTER and
codeblock. If the code IS actually wrong, then why has it been working
fine for so long?
The thing that worries me is that I have a lot of other code which will
be wrong as well, so code changes don't seem to be a viable solution.
I have not changed the compiler switches. The only change that I have
made recently is that I moved to the DBFCDX driver.
If I HAVE to change the code, what would I change it to? Would I have
to make mType a PRIVATE variable? YUK!!!
Any ideas? Any would be appreciated.
Regards
Craig Jarvis
Cape Town, South Africa
Dave Pearson
On Thu, 22 May 1997 18:54:32 +0200, Craig Jarvis <craig....@datamax.co.za> wrote:
> The code is as follows: SET FILTER TO ModType=mType
>
> The error: BASE/1003 Variable does not exit: MTYPE
>
> mType is a local variable.
That's your problem.
> If the code IS actually wrong, then why has it been working fine for
> so long?
What else have you changed in the move from 5.2 to 5.3?
> I have not changed the compiler switches. The only change that I
> have made recently is that I moved to the DBFCDX driver.
Bingo! I bet that is the difference. This probably all comes down to
the difference in which DBFNTX (I assume you were using that before)
and DBFCDX create a filter. For example, I had a friend call me up
with the exact same problem the other day but in this case using
SIXNSX. He was calling m6_SetFilter() and passing a code block (so the
use of the local was valid) and the string version of the filter
(which, IIRC, SIx uses to optimise the filter).
It appeared that SIx was having a problem because it was doing
something with the string version of the filter and, obviously, it
couldn't handle the name of a local in the string. In the case of
m6_SetFilter() I got round it for him with:
m6_SetFilter( {|| Foo->Bar == dBaz },;
"Foo->Bar == stod( '" + dtos( dBaz ) + "' )" )
I assume that DBFCDX uses dbSetFilter()? If so, and if you don't want
to have to worry about saving filter expressions or getting at them
with dbFilter(), you could re-code the SET FILTER command with your
own #command so that it doesn't pass the <cCondition> value to
dbSetFilter() (see the Norton Guide, it's optional). For example,
it could look something like:
#command SET FILTER TO <x:&> ;
=> if ( Empty(<(x)>) ) ;
; dbClearFilter() ;
; else ;
; dbSetFilter( <{x}> ) ;
; end
WARNING: I've not tested this, and I've never used DBFCDX as an RDD,
this should work, but it might not.
> If I HAVE to change the code, what would I change it to? Would I
> have to make mType a PRIVATE variable? YUK!!!
That would be another way of doing it. :-) Like I say, if the above
works and you don't use dbFilter() to get at a filter expression
then it should work ok.
> Any ideas? Any would be appreciated.
Hope this helps.
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ | ng2html - The NG to HTML converter.
Also available in the UK: | eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ | dgscan - DGROUP scanner for Clipper.
Craig Jarvis
Hi Dave
Dave Pearson wrote:
> What else have you changed in the move from 5.2 to 5.3?
Nothing! I simply recompiled. I was using the DBFCDX driver in 5.2e as
well and it worked. I only changed from 5.2e to 5.3 because I was told
(in this group) that the 5.2e DBFCDX was broken. I know that the 5.2e
DBFCDX came from a different company from the 5.3 one, so maybe the
answer lies in that.
> #command SET FILTER TO <x:&> ;
> => if ( Empty(<(x)>) ) ;
> ; dbClearFilter() ;
> ; else ;
> ; dbSetFilter( <{x}> ) ;
> ; end
I was hoping for an "easy" solution like this, but my gut feeling is
that I should change the code. I don't like changing Clipper commands.
> Hope this helps.
It certainly does. Much appreciated.
Dave Pearson
On Fri, 23 May 1997 09:52:28 +0200, Craig Jarvis <craig....@datamax.co.za> wrote:
> > What else have you changed in the move from 5.2 to 5.3?
>
> Nothing! I simply recompiled. I was using the DBFCDX driver in
> 5.2e as well and it worked. I only changed from 5.2e to 5.3 because
> I was told (in this group) that the 5.2e DBFCDX was broken. I know
> that the 5.2e DBFCDX came from a different company from the 5.3 one,
> so maybe the answer lies in that.
Am I correct in thinking that the 5.3 CDX driver is totally different
to the 5.2 driver? I'm not too sure myself never having used 5.3.
> > #command SET FILTER TO <x:&> ;
> > => if ( Empty(<(x)>) ) ;
> > ; dbClearFilter() ;
> > ; else ;
> > ; dbSetFilter( <{x}> ) ;
> > ; end
>
> I was hoping for an "easy" solution like this, but my gut feeling is
> that I should change the code. I don't like changing Clipper
> commands.
If you need a quick fix then consider it just to get things working.
After that, yes, it's a good idea to change the code and revert the
command back to it's "normal" state. I guess this all depends on the
number of lines of code you will have to change.
Miguel Oliveira
Hi,
I惴 afraid that this is one of Clipper愀 5.3a "undocumented features".
You can愒 use local variables in a SET FILTER TO condition. The same thing
happens whit conditional indexes : you cant use local variables in those
conditions.
We had the same problem when we upgraded from 5.3 to 5.3a.
Hope this helps,
Miguel Oliveira
------------------------------------
Craig Jarvis <craig....@datamax.co.za> wrote in article
<33847A48...@datamax.co.za>...
> Hi All
>
> This one REALLY has me!
>
> I have an app which has been compiled in Clipper 5.2e, then 5.3, then
> 5.3a. All of a sudden, code which has been working fine for years
> suddenly gives the above error.
>
> The code is as follows: SET FILTER TO ModType=mType
>
> The error: BASE/1003 Variable does not exit: MTYPE
>
> mType is a local variable. The error messages guide talks about local
> or static variables in a macro. Does this also apply to codeblocks? I
> know that the pre-processor turns the SET FILTER into a DBSETFILTER and
> codeblock. If the code IS actually wrong, then why has it been working
> fine for so long?
>
> The thing that worries me is that I have a lot of other code which will
> be wrong as well, so code changes don't seem to be a viable solution.
>
> I have not changed the compiler switches. The only change that I have
> made recently is that I moved to the DBFCDX driver.
>
> If I HAVE to change the code, what would I change it to? Would I have
> to make mType a PRIVATE variable? YUK!!!
>
> Any ideas? Any would be appreciated.
Stefano Costagli
I have had exactly the same problem switching from DBFNTX to DBFCDX always using
Clipper 5.3a. I simply don't pass the [cCondition] to the dbSetFilter()
function.
Regards
Stefano
Craig Jarvis
Hi Dave
Dave Pearson wrote:
> Am I correct in thinking that the 5.3 CDX driver is totally different
> to the 5.2 driver? I'm not too sure myself never having used 5.3.
Yes. My understanding (from Carl Zebrooker & Steve Quinn) is that CA
licensed a cut down version of Comix to use in 5.3, instead of repairing
it themselves.
> If you need a quick fix then consider it just to get things working.
> After that, yes, it's a good idea to change the code and revert the
> command back to it's "normal" state. I guess this all depends on the
> number of lines of code you will have to change.
I did a search on "set filt" and found many matches. But most did not
reference a local or static variable. Where necessary I simply assigned
a private variable to the local variable, then used the private.
Luckily this was only necessary in 3 or 4 places. Problem solved.
Here's an interesting one, though. There are some filters which use
local arrays, but do not give any problem. I know that arrays are
simply pointers, but interestingly it does not have a problem with a
local numeric variable which designates the subscript:
set filter to upper(DescripEng)==aStaff[mStaffNum]
aStaff is a local array. mStaffNum is a local variable. This works
fine!!!
I assumed that the new CDX driver uses the second (string) parameter in
the dbSetFilter() in a macro, but surely the above would give the same
problem.
Anyway, for now I am satisfied that it works, even though I don't know
why.
Thanks to all for their replies.
Dave Pearson
On Sun, 25 May 1997 11:02:17 +0200, Craig Jarvis <craig....@datamax.co.za> wrote:
> set filter to upper(DescripEng)==aStaff[mStaffNum]
>
> aStaff is a local array. mStaffNum is a local variable. This works
> fine!!!
>
> I assumed that the new CDX driver uses the second (string) parameter in
> the dbSetFilter() in a macro, but surely the above would give the same
> problem.
Hmm, well, it would only be a problem if it attempts to macro compile
the string. Perhaps, for some reason, it isn't in this case. With the
CDX driver in 5.3, is it an "optimising" filter? If so, it might be
worth checking the docs for the rules of when it will optimise and
when it won't.