Inoffizielles deutsches Xbase-Forum

INDEX ON FIELD->TEST TO XXXTEST FOR FIELD->TEST = "AAA"

ordCondSet( 'FIELD->TEST = "AAA"', _EarlyBoundCodeblock({|| FIELD->TEST = "AAA"}) ,, , ,  , RECNO(), , , , , , ,  ) ;
ordCreate( "XXXTEST", , "FIELD->TEST", _EarlyBoundCodeblock({|| FIELD->TEST}), , .F. )

For example the <lWhileCondition> in INDEX ON clearly documents that the index is created starting with the current record.
This hint is missing in the documentation for OrdCondSet().

In the course of identifying all places of performance improvements we have
analyzed common command syntax and resolved two issues that originated from the
early vs. late binding of macro expressions in code blocks. As you know, Xbase++
uses always the late binding approach. This has led to some confusion when
Clipper code was compiled since Clipper uses early binding in command syntax. To
explain what's happening, let us look at this code snippet:

Code: Alles auswählen

   cFilter := "My filter condition"
   SET FILTER TO &cFilter

In SL1, the FILTER command was preprocessed to

Code: Alles auswählen

   DbSetFilter( {|| &cFilter }, cFilter )

Due to the late binding feature, the filter expression was then macro-compiled
each time the code block was eval'ed. No need to do that, since the filter
expression is unlikely to change while a database is skipped, and we get a
performance increase when using early binding (=the filter expression is
macro-compiled once only, when the code block is created). Since Clipper does it
the same way, we have the advantage that there is no longer a performance hit
when using legal Clipper command syntax.

Since you are using functional syntax, you are not likely to need to change your
code if you are aware of the early vs late binding issue. When using macro
expressions in a code block, early binding can always be enforced by creating a
macro-compiled code block, e.g.:

Code: Alles auswählen

   cFilter := "My filter condition"
   bFilter := &( "{||" + cFilter +"}" )
   DbSetFilter( bFilter, cFilter )

This is basically what _EarlyBoundCodeBlock() is good for.
--
With best regards
--
Your Xbase++ Public Beta Team

PRIVATE, PUBLIC variables or FIELDS are evaluated when the code
of the codeblock is executed.
We call this behaviour late binding.
In contrast to late binding the value of PRIVATE, PUBLIC variables
or FIELDs can be evaluated at the time the codeblock is created.
We call this behaviour early binding.
Early bound codeblocks with PRIVATEs, PUBLICs or FIELDs execute
faster since the value is evaluate at creation time and doesn't
have to be evaluated each time the codeblock is executed.

_EarlyBoundCodeBlock(<bLate>) -> <bEarly> replaces all PRIVATE,
PUBLIC or FIELDS with their corresponding values and returns an
early bound codeblock.


HTH,
Wolfgang
Alaska Software GmbH