Error in filter expression

Hello,

Next code gives a error :

SELE FAKTUIT
SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND.
BONALG->(DBSEEK(FAKTUIT->BONNR)) )

Error description: Error BASE/1003 Variable does not exist: BONNR

The field FAKTUIT->Bonnr exists. It seems that the alias from BONNR
(FAKTUIT) is not seen by the program.

The ppo file looks correct :

dbSelectArea( "FAKTUIT" )
dbSetFilter( {|| ( FAKTUIT->Klnr="BAK " .AND.
BONALG->(DBSEEK(FAKTUIT->BONNR)) )}, '( FAKTUIT->Klnr="BAK " .AND.
BONALG->(DBSEEK(FAKTUIT->BONNR)) )' )

Frank Demont

I made a litle program to test , compiling it also with clipper. Both , xhb
and clipper gives no error . I don't understand why the same line gives a
error in the main projekt , not in this test program.

FUNCTION MAIN

USE BONALG
INDEX ON Bonnr TO TestFilt
USE FAKTUIT NEW
SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND.
BONALG->(DBSEEK(FAKTUIT->BONNR)) )
GO TOP
WAIT
CLOS ALL
RETURN

On Jan 22, 6:57*am, "Frank Demont" <demontfr...@scarlet.be> wrote:
> I made a litle program to test , compiling it also with clipper. Both , xhb
> and clipper gives no error . I don't understand why the same line gives a
> error in the main projekt , not in this test program.
>
> FUNCTION MAIN
>
> USE BONALG
> INDEX ON Bonnr TO TestFilt
> USE FAKTUIT NEW
> SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND.
> BONALG->(DBSEEK(FAKTUIT->BONNR)) )
> GO TOP
> WAIT
> CLOS ALL
> RETURN

I don't see how it worked in the first place, using an index
expression in a filter (filter moves sequentially through the active
index, dbseek moves the index pointer again, which means records could
be missed... it seems to me).

But I'd guess that either the index in your main code was not opened
(SET AUTOPEN), or the "BONNR" index was not active in FAKTUIT. For
example, CDX indexes when opened, have no order (order 0) as default
(which also can be changed with a flag).

David A. Smith

David ,

The filter expression was first only ( FAKTUIT->Klnr="BAK " ) , it works ,
no error . After expanding it whith ' .AND.
BONALG->(DBSEEK(FAKTUIT->BONNR))' i got the error on this line. If your
sugestions where right , it should also fail on the original filter
expression. I have contoled error.log and the indices are activated as
expected.

I am sorry , but for me it seems to be a bug from xharbour which i can't
reproduce in a litle testprogram.



"dlzc" <dlzc1@cox.net> schreef in bericht
news:659db95b-21ac-4dac-903f-26ff1246b2a2@e9g2000prn.googlegroups.com...
On Jan 22, 6:57 am, "Frank Demont" <demontfr...@scarlet.be> wrote:
> I made a litle program to test , compiling it also with clipper. Both ,
> xhb
> and clipper gives no error . I don't understand why the same line gives a
> error in the main projekt , not in this test program.
>
> FUNCTION MAIN
>
> USE BONALG
> INDEX ON Bonnr TO TestFilt
> USE FAKTUIT NEW
> SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND.
> BONALG->(DBSEEK(FAKTUIT->BONNR)) )
> GO TOP
> WAIT
> CLOS ALL
> RETURN

I don't see how it worked in the first place, using an index
expression in a filter (filter moves sequentially through the active
index, dbseek moves the index pointer again, which means records could
be missed... it seems to me).

But I'd guess that either the index in your main code was not opened
(SET AUTOPEN), or the "BONNR" index was not active in FAKTUIT. For
example, CDX indexes when opened, have no order (order 0) as default
(which also can be changed with a flag).

David A. Smith

Dear Frank Demont:

On Jan 22, 2:58*pm, "Frank Demont" <demontfr...@scarlet.be> wrote:
> The filter expression was first only ( FAKTUIT->Klnr="BAK " ) ,
> it works , no error . After expanding it whith ' .AND.
> *BONALG->(DBSEEK(FAKTUIT->BONNR))' i got the error
> on this line. If your sugestions where right , it should also
> fail on the original filter expression. I have contoled error.log
> and the indices are activated as expected.
>
> I am sorry , but for me it seems to be a bug from xharbour
> which i can't reproduce in a litle testprogram.

Which means it is not a bug in xHarbour, but in your assumptions about
the state of the data tables (relations, scopes, SET ORDER TO, etc.)
when you execute it in your main program. That is why it works in the
test program, and not in your production code. Why don't you splice
your test code into the production code, at the same place? Then if
it works, you'll know where to look next...

David A. Smith

David ,

This code works :
SELE FAKTUIT
SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND. BONALG->(FOUND()) )
SET RELATION TO FAKTUIT->Bonnr INTO BONALG

This doesn't. I prefer to not use RELATION's (only when necessary) . Note
that it does exact the same as with the relation

SELE FAKTUIT
SET FILT TO (FAKTUIT->Klnr="BAK " .AND. BONALG->(DBSEEK(FAKTUIT->BONNR)))

When Bonnr is not recognised as a field (error : Variable does not exist:
BONNR ) , then FAKTUIT must be out of scope , closed ?? How can a DBF be out
of scope ? But FAKTUIT->Klnr is recognised in the same line , why not
FAKTUIT->BONNR ?

Also SET FILT TO BONALG->(DBSEEK(FAKTUIT->BONNR)) gives the same error .

Frank











I can not understand why
"dlzc" <dlzc1@cox.net> schreef in bericht
news:6d2a5671-aed7-465e-b5fa-5cb1ba1e4539@u18g2000prh.googlegroups.com...
Dear Frank Demont:

On Jan 22, 2:58 pm, "Frank Demont" <demontfr...@scarlet.be> wrote:
> The filter expression was first only ( FAKTUIT->Klnr="BAK " ) ,
> it works , no error . After expanding it whith ' .AND.
> BONALG->(DBSEEK(FAKTUIT->BONNR))' i got the error
> on this line. If your sugestions where right , it should also
> fail on the original filter expression. I have contoled error.log
> and the indices are activated as expected.
>
> I am sorry , but for me it seems to be a bug from xharbour
> which i can't reproduce in a litle testprogram.

Which means it is not a bug in xHarbour, but in your assumptions about
the state of the data tables (relations, scopes, SET ORDER TO, etc.)
when you execute it in your main program. That is why it works in the
test program, and not in your production code. Why don't you splice
your test code into the production code, at the same place? Then if
it works, you'll know where to look next...

David A. Smith

Dear Frank Demont:

On Jan 23, 4:35*am, "Frank Demont" <demontfr...@scarlet.be> wrote:
....
> This code works :
> SELE FAKTUIT
> SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND. BONALG->(FOUND()) )
> SET RELATION TO FAKTUIT->Bonnr INTO BONALG

No, actually it doesn't. Found() cannot be redirected into other work
areas, as your filter has tried to do. DbInfo( DBI_FOUND ) can do
that, however.

> This doesn't. I prefer to not use RELATION's (only when
> necessary) . Note that it does exact the same as with
> the relation

I think you'll find major differences, if you only count records. And
relations use indexes, or direct record-by-record synchronization.
Faster than filters.

That you didn't have to manually move the record pointer, that you
don't like things to be automatic, is at the heart of this issue.

> SELE FAKTUIT
> SET FILT TO (FAKTUIT->Klnr="BAK " .AND. ;
> BONALG->(DBSEEK(FAKTUIT->BONNR)))
>
> When Bonnr is not recognised as a field (error :
> *Variable does not exist: BONNR ) , then FAKTUIT
> must be out of scope , closed ?? How can a DBF be out
> of scope ?

Because of your multiple indirection. Compiler saw BONALG->,
indirection was still in force, and "BONALG" does not have a field
BONNR.

>*But FAKTUIT->Klnr is recognised in the same line , why not
> FAKTUIT->BONNR ?

Because you hadn't closed the initial parens, would be my guess.

How about substituting this fragment:
BONALG->(DBSEEK(FAKTUIT->(BONNR))))

> Also SET FILT TO *BONALG->(DBSEEK(FAKTUIT->BONNR))
> gives the same error .

I hold little hope that will work, but when playing "black magic
games", one never knows.

David A. Smith

"dlzc" <dlzc1@cox.net> ha scritto nel messaggio
news:abbfe753-3cf0-4ff4-ac9e-379598e709ac@k9g2000pre.googlegroups.com...

> Found() cannot be redirected into other work areas

Why not?

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic

"Enrico Maria Giordano" <e.m.giordano@emagsoftware.it> ha scritto nel
messaggio news:4d3c8003$0$2046$4fafbaef@reader1.news.tin.it. ..

> > Found() cannot be redirected into other work areas
>
> Why not?

Ops, I just answer myself. :-)

Obviously, Found() is the result of a Seek operation in a specific work
area.

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic

On 22 Sty, 14:26, "Frank Demont" <demontfr...@scarlet.be> wrote:
> Next code gives a error :
>
> SELE FAKTUIT
> SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND.
> BONALG->(DBSEEK(FAKTUIT->BONNR)) )
>
> Error description: Error BASE/1003 *Variable does not exist: BONNR
>
> The field FAKTUIT->Bonnr exists. It seems that the alias from BONNR
> (FAKTUIT) is not seen by the program.

Hi Frank,
What RDD you are using and which xHarbour version?
Can you add to your code before above SET FILTER ...
this line:
( FAKTUIT->BONNR )
Just to check if the problem can be exploited outside
RDD code and filter evaluation.
In general it can be caused by 4 different reasons:
1. FAKTUIT area does not have BONNR field.
2. Some filter optimization in used RDD wrongly stripped
current alias FAKTUIT-> from the expression what is
illegal in above example because it's used inside
other alias expression.
3. Symbol table of module with above code is wrongly
generated by compiler or registered in HVM
4. Internal HVM dynamic symbol table is corrupted.

Above test should eliminate 2-nd condition if it fails
in the line:
( FAKTUIT->BONNR )
To say sth more about other possible reasons I will
have to see .c file generated by xharbour compiler for
the .PRG file having above code with -gc2 compiler
switch.

best regards,
Przemek

David

No, actually it doesn't. Found() cannot be redirected into other work
areas, as your filter has tried to do. DbInfo( DBI_FOUND ) can do
that, however.

I don't agree. Each workarea has a flag indicating the result from the last
search command in that workarea . BONALG->(FOUND()) shows the result in area
BONALG.

The used filter worked as expected : only the records which i wanted are
visible

Frank

"dlzc" <dlzc1@cox.net> schreef in bericht
news:abbfe753-3cf0-4ff4-ac9e-379598e709ac@k9g2000pre.googlegroups.com...
Dear Frank Demont:

On Jan 23, 4:35 am, "Frank Demont" <demontfr...@scarlet.be> wrote:
....
> This code works :
> SELE FAKTUIT
> SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND. BONALG->(FOUND()) )
> SET RELATION TO FAKTUIT->Bonnr INTO BONALG

No, actually it doesn't. Found() cannot be redirected into other work
areas, as your filter has tried to do. DbInfo( DBI_FOUND ) can do
that, however.

> This doesn't. I prefer to not use RELATION's (only when
> necessary) . Note that it does exact the same as with
> the relation

I think you'll find major differences, if you only count records. And
relations use indexes, or direct record-by-record synchronization.
Faster than filters.

That you didn't have to manually move the record pointer, that you
don't like things to be automatic, is at the heart of this issue.

> SELE FAKTUIT
> SET FILT TO (FAKTUIT->Klnr="BAK " .AND. ;
> BONALG->(DBSEEK(FAKTUIT->BONNR)))
>
> When Bonnr is not recognised as a field (error :
> Variable does not exist: BONNR ) , then FAKTUIT
> must be out of scope , closed ?? How can a DBF be out
> of scope ?

Because of your multiple indirection. Compiler saw BONALG->,
indirection was still in force, and "BONALG" does not have a field
BONNR.

> But FAKTUIT->Klnr is recognised in the same line , why not
> FAKTUIT->BONNR ?

Because you hadn't closed the initial parens, would be my guess.

How about substituting this fragment:
BONALG->(DBSEEK(FAKTUIT->(BONNR))))

> Also SET FILT TO BONALG->(DBSEEK(FAKTUIT->BONNR))
> gives the same error .

I hold little hope that will work, but when playing "black magic
games", one never knows.

David A. Smith

Przemek

Thanks for the explanation

RDD : rddSetDefault( "RMDBFCDX" )
XHB : xHarbour build 1.1.0 Intl. (SimpLex) (Rev. 6220)

I already tryed to place a '? FAKTUIT->Bonnr' the line before , it gives no
problem

1. FAKTUIT area does not have BONNR field.
No , the field exists

2. Some filter optimization in used RDD wrongly stripped
current alias FAKTUIT-> from the expression what is
illegal in above example because it's used inside
other alias expression.

I made a little test program with the offending line , using the same RDD ,
no problem.
Can optimization work in this scenario , and not in the main program (has
more indexen) ?

I tryed also to use :

PRIVATE Bonnr

and becomes another error :

Error description: Error DBCMD/2001 Workarea not in use: DBSEEK

The problem seems to be that the program has not an active workarea ,
BONALG->(DBSEEK(FAKTUIT->Bonnr))

BONALG is not accepted as the workarea

To be sure , i tested als without PRIVATE Bonnr , and become as error :

Error description: Error BASE/1003 Variable does not exist: BONNR

When there is no active workarea , bonnr doesn't exist !

Note that the ppo-file is correct !

3. Symbol table of module with above code is wrongly
generated by compiler or registered in HVM
4. Internal HVM dynamic symbol table is corrupted.

Frank





"druzus" <przemyslaw.czerpak@gmail.com> schreef in bericht
news:677334d9-dab4-446f-9b35-d4589db88fc6@o8g2000vbq.googlegroups.com...
On 22 Sty, 14:26, "Frank Demont" <demontfr...@scarlet.be> wrote:
> Next code gives a error :
>
> SELE FAKTUIT
> SET FILTER TO ( FAKTUIT->Klnr="BAK " .AND.
> BONALG->(DBSEEK(FAKTUIT->BONNR)) )
>
> Error description: Error BASE/1003 Variable does not exist: BONNR
>
> The field FAKTUIT->Bonnr exists. It seems that the alias from BONNR
> (FAKTUIT) is not seen by the program.

Hi Frank,
What RDD you are using and which xHarbour version?
Can you add to your code before above SET FILTER ...
this line:
( FAKTUIT->BONNR )
Just to check if the problem can be exploited outside
RDD code and filter evaluation.
In general it can be caused by 4 different reasons:
1. FAKTUIT area does not have BONNR field.
2. Some filter optimization in used RDD wrongly stripped
current alias FAKTUIT-> from the expression what is
illegal in above example because it's used inside
other alias expression.
3. Symbol table of module with above code is wrongly
generated by compiler or registered in HVM
4. Internal HVM dynamic symbol table is corrupted.

Above test should eliminate 2-nd condition if it fails
in the line:
( FAKTUIT->BONNR )
To say sth more about other possible reasons I will
have to see .c file generated by xharbour compiler for
the .PRG file having above code with -gc2 compiler
switch.

best regards,
Przemek

On 27 Sty, 09:35, "Frank Demont" <demontfr...@scarlet.be> wrote:

Hi,

> RDD : rddSetDefault( "RMDBFCDX" )
> XHB : xHarbour build 1.1.0 Intl. (SimpLex) (Rev. 6220)

Quite old.
Can you try with "DBFCDX"?
It's possible that the problem is created by RMDBFCDX.

> I made a little test program with the offending line , using the same RDD,
> no problem.
> Can optimization work in this scenario , and not in the main program (has
> more indexen) ?

Yes. All indexes should be exactly the same. RMDBF* optimizations
depends on active indexes.

> I tryed also to use :
> PRIVATE Bonnr
> and becomes another error :
> Error description: Error DBCMD/2001 *Workarea not in use: DBSEEK
> The problem seems to be that the program has not an active workarea ,
> BONALG->(DBSEEK(FAKTUIT->Bonnr))

Has FAKTUIT workarea active index when you are setting filter?

> BONALG is not accepted as the workarea
> To be sure , i tested als without PRIVATE Bonnr , and become as error :
> Error description: Error BASE/1003 *Variable does not exist: BONNR
> When there is no active workarea , bonnr doesn't exist !

BTW are you sure that you compiled your code without for single thread
without any xHarbour switches? You can check linked HVM using:
<yourapp> //INFO
It should show "MT:Off" at the status line.

> Note that the ppo-file is correct !

I know.

best regards,
Przemek

Hi,

Using the same index file(cdx) from the main aplication in the litle
testprogram (FAKTUIT) , i become the same error (RMDBFCDX)

With DBFCDX NO ERROR !!!!!

Frank Demont
"druzus" <przemyslaw.czerpak@gmail.com> schreef in bericht
news:761e2008-e5b9-40dd-9700-91a2427f67ed@s9g2000vbh.googlegroups.com...
On 27 Sty, 09:35, "Frank Demont" <demontfr...@scarlet.be> wrote:

Hi,

> RDD : rddSetDefault( "RMDBFCDX" )
> XHB : xHarbour build 1.1.0 Intl. (SimpLex) (Rev. 6220)

Quite old.
Can you try with "DBFCDX"?
It's possible that the problem is created by RMDBFCDX.

> I made a little test program with the offending line , using the same RDD
> ,
> no problem.
> Can optimization work in this scenario , and not in the main program (has
> more indexen) ?

Yes. All indexes should be exactly the same. RMDBF* optimizations
depends on active indexes.

> I tryed also to use :
> PRIVATE Bonnr
> and becomes another error :
> Error description: Error DBCMD/2001 Workarea not in use: DBSEEK
> The problem seems to be that the program has not an active workarea ,
> BONALG->(DBSEEK(FAKTUIT->Bonnr))

Has FAKTUIT workarea active index when you are setting filter?

> BONALG is not accepted as the workarea
> To be sure , i tested als without PRIVATE Bonnr , and become as error :
> Error description: Error BASE/1003 Variable does not exist: BONNR
> When there is no active workarea , bonnr doesn't exist !

BTW are you sure that you compiled your code without for single thread
without any xHarbour switches? You can check linked HVM using:
<yourapp> //INFO
It should show "MT:Off" at the status line.

> Note that the ppo-file is correct !

I know.

best regards,
Przemek

Hi,

Adding

SET OPTIMIZE off

To the code , no error !!!!!!


"druzus" <przemyslaw.czerpak@gmail.com> schreef in bericht
news:761e2008-e5b9-40dd-9700-91a2427f67ed@s9g2000vbh.googlegroups.com...
On 27 Sty, 09:35, "Frank Demont" <demontfr...@scarlet.be> wrote:

Hi,

> RDD : rddSetDefault( "RMDBFCDX" )
> XHB : xHarbour build 1.1.0 Intl. (SimpLex) (Rev. 6220)

Quite old.
Can you try with "DBFCDX"?
It's possible that the problem is created by RMDBFCDX.

> I made a little test program with the offending line , using the same RDD
> ,
> no problem.
> Can optimization work in this scenario , and not in the main program (has
> more indexen) ?

Yes. All indexes should be exactly the same. RMDBF* optimizations
depends on active indexes.

> I tryed also to use :
> PRIVATE Bonnr
> and becomes another error :
> Error description: Error DBCMD/2001 Workarea not in use: DBSEEK
> The problem seems to be that the program has not an active workarea ,
> BONALG->(DBSEEK(FAKTUIT->Bonnr))

Has FAKTUIT workarea active index when you are setting filter?

> BONALG is not accepted as the workarea
> To be sure , i tested als without PRIVATE Bonnr , and become as error :
> Error description: Error BASE/1003 Variable does not exist: BONNR
> When there is no active workarea , bonnr doesn't exist !

BTW are you sure that you compiled your code without for single thread
without any xHarbour switches? You can check linked HVM using:
<yourapp> //INFO
It should show "MT:Off" at the status line.

> Note that the ppo-file is correct !

I know.

best regards,
Przemek