so hier mal paar Zitate von "offenen" PDRs
5457 Spontaneous Program Termination (SPT), Strategies
Possible causes due to open PDRs or known problems:
o Use SET OPTIMIZE OFF to avoid any problems with the
Xbase++ expression optimizer
5133 SET FILTER raises IDSC if alias name is invalid
If the alias name in a filter expression is invalid and
it is used in a function like EMPTY(), an IDSC is raised
instead of an error "unknown/invalid name of alias
SET OPTIMIZE OFF
5116 IDSC on Seek using UDF in Filter and Index expression
If a user defined function (UDF) is used in an index expression and the
same UDF is used in a filter expression at the same time, then
an IDSC (internal data structures corrupted) error may occour.
Use
SET OPTIMIZE OFF
5024 PRIVATE vars in optimized filter expression not supported
Setting a filter condition with embedded LOCAL variables and using the
new optimization technique of Xbase++ version 1.70 may not reflect
the correct record set as in the example below:
PROC main()
PRIVATE A_Position := 6
dbCreate( "Test", "Name", "C", 20, 0)
USE Test NEW EXCLUSIVE
dbAppend()
Field->Name := "Frank++"
dbAppend()
Field->Name := "Bill"
dbCommit()
dbGotop()
Browse()
set filter to ( substr( Name, A_Position, 1) = "+")
// set filter to ( substr( Name, 2, 1) = "+") // this works
dbGotop()
Browse() // this is an empty record set although it should
Either switch off SET OPTIMIZE OFF or change the filter expression
to an expression with no LOCAL variable embedded such as i.e.
set filter to ( substr( Name, 2, 1) = "+")
from the sample above
5023 dbSetFilter()/dbClearFilter() eats up memory
Each
dbSetFilter(|| Status == 1,'Status == 1')
dbGoTop()
dbClearFilter()
or
dbSetScope(0xff,'32')
dbClearScope()
cycle seems to eat up a bit of the available memory.
Please switch SET OPTIMIZE OFF !
5008 SET FILTER with negated compound expression fails
A compound filter expression that is negated as complete expression
or each expression part itself returns a wrong result set.
1) SET OPTIMIZE OFF
2) instead of
set filter to !( cNr1 = "A" ) .and. !( cNr2 = "B" )
use
set filter to cNr1 != "A" .and. cNr2 != "B"
5007 SET FILTER with a substr() in the expression ignores .NOT.
SET FILTER where the left side of the expression is a substring of a
field returns a wrong result if the expression is denied. It behaves
the same as if the denial isn't used.
For example :
SET FILTER TO !(substring(field->x,2,1)=="2")
would result in
SET FILTER TO substring(field->x,2,1)
1) SET OPTIMIZE OFF
2) change the sides of the expression like :
SET FILTER TO !("2"==substr(field->x,2,1))
3) do not deny the complete expression, use :
SET FILTER TO substring(field->x,2,1)!="2"
5001 SET FILTER with a substring of the indexed field fails
SET FILTER, where the left side of the filter expression is a
substring of the indexed field fails.
Example (to make my words clear) :
...
index on field->artikel to test
...
set filter to left(field->artikel,2)=field->nummer
1) SET OPTIMIZE OFF
2) Turn around the filter expression like :
set filter to field->nummer=left(field->artikel,2)
4971 DbSkip(0) might hang the application
DbSkip(0) might hang the application if a filter is set.
This does not mean it hangs the application with every database,
on some databases it works and on some others not. The only precondition
is the database must have deleted record.
Do not use DbSkip(0)
or
SET OPTIMIZE OFF
4657 LOCAL vars in optimized filter expression are not supported
see PDR 5024
also viele Gründe warum man bei Cl*pper Code sich mit Xbase++ auf den "kleinsten" gemeinsamen Nenner einigen sollte also im "Zweifel" alle Xbase++ Future "abschalten" wenn die Cl*pper Application läuft und Xbase++ nicht.
wir könnten ja auch noch harbour mit seiner RDD einbeziehen welches "Verhalten" dem von Cl*pper unter *.NTX wohl am nächsten kommt.
p.s. ich gebe ja zu das es unter Cl*pper Sachen gab/gibt wo ich nicht glauben wollte das solche Konstruktionen funktionieren ... BUG oder Futures
