OrdCondSet, [<cForCondition>] muss sein [erledigt]
Moderator: Moderatoren
- Klaus Schuster
- Foren-Administrator
- Beiträge: 371
- Registriert: Do, 24. Jan 2008 10:01
- Wohnort: 90762 Fürth
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 9 Mal
OrdCondSet, [<cForCondition>] muss sein [erledigt]
Hallo Leute,
laut Hilfe ist [<cForCondition>] optional. Die Angabe von <bForCondition> allein (ohne eine Eintrag in [<cForCondition>]), bringt jedoch nichts. Wird eine ForCondition benötigt, so muss diese in <cForCondition> eingetragen werden, <bForCondition> kann leer bleiben. Wozu dient dann <bForCondition>?
laut Hilfe ist [<cForCondition>] optional. Die Angabe von <bForCondition> allein (ohne eine Eintrag in [<cForCondition>]), bringt jedoch nichts. Wird eine ForCondition benötigt, so muss diese in <cForCondition> eingetragen werden, <bForCondition> kann leer bleiben. Wozu dient dann <bForCondition>?
Zuletzt geändert von Klaus Schuster am Di, 01. Mai 2018 8:32, insgesamt 1-mal geändert.
Gruß Klaus
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2832
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 98 Mal
- Danksagung erhalten: 13 Mal
Re: OrdCondSet, [<cForCondition>] muss sein
Hallo, Klaus -
ich würde mal auf Kompatibilität tippen.
Die FOR-Bedingung wird als Klartext in die Index-Datei eingetragen, und darum muss sie m.E. auch so vorliegen.
OrdCondSet() ist m.E. bereits eine Clipper-Funktion, daher muss die Kompatibilität zu Clipper gewahrt bleiben.
Aber die Dokumentation schweigt sich manchmal über solche Zusammenhänge aus.
ich würde mal auf Kompatibilität tippen.
Die FOR-Bedingung wird als Klartext in die Index-Datei eingetragen, und darum muss sie m.E. auch so vorliegen.
OrdCondSet() ist m.E. bereits eine Clipper-Funktion, daher muss die Kompatibilität zu Clipper gewahrt bleiben.
Aber die Dokumentation schweigt sich manchmal über solche Zusammenhänge aus.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Re: OrdCondSet, [<cForCondition>] muss sein
Hallo Klaus
es gibt einige Funktionen bei denen die "Doppelangabe" der gewünschten Funktion als Block-String "C" oder/und als Block "B" möglich ist.
Ich meine, dass es mit der Rückgabe der Infos beim debugging zu tun hat.
Ob Du beim Aufruf den "B" oder den "C"-Parameter verwendest ist egal.
Wenn es geht gebe ich beides mit - mann weiß nie wozu das gut ist...
es gibt einige Funktionen bei denen die "Doppelangabe" der gewünschten Funktion als Block-String "C" oder/und als Block "B" möglich ist.
Ich meine, dass es mit der Rückgabe der Infos beim debugging zu tun hat.
Ob Du beim Aufruf den "B" oder den "C"-Parameter verwendest ist egal.
Wenn es geht gebe ich beides mit - mann weiß nie wozu das gut ist...
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: OrdCondSet, [<cForCondition>] muss sein
siehe dir mal den PPO Code von INDEX ON ... FOR an
es wird also beides benötigt ... und frag mich nicht warum es ein _EarlyBoundCodeblock() sein soll
unter Xbase++ gibt es noch eine (interessante) offene PDR 6215
wenn bei Bedingungen das Ergebnis nicht dem erwarteten Resultat entspricht kann das an der Xbase++ "Optimierung" liegen. vor allen SET OPTIMZE sollte man dann mit OFF versuchen
Code: Alles auswählen
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. )
unter Xbase++ gibt es noch eine (interessante) offene PDR 6215
Anmerkung :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().
wenn bei Bedingungen das Ergebnis nicht dem erwarteten Resultat entspricht kann das an der Xbase++ "Optimierung" liegen. vor allen SET OPTIMZE sollte man dann mit OFF versuchen
gruss by OHR
Jimmy
Jimmy
- Klaus Schuster
- Foren-Administrator
- Beiträge: 371
- Registriert: Do, 24. Jan 2008 10:01
- Wohnort: 90762 Fürth
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 9 Mal
Re: OrdCondSet, [<cForCondition>] muss sein
Danke, Leute,
@Roland: Nein, es ist nicht egal, welchen Wert B oder C Du angibst. C funktioniert alleine, B ohne C nicht. Ergo, ist C zwingend nötig. B ist wohl wie Georg schrieb nur aus Kompatibilitätsgründen, oder nach Jimmy für Debugzwecke vorhanden. C muss sein.
@Jimmy: Weißt Du, was _EarlyBoundCodeblock() macht?
@Roland: Nein, es ist nicht egal, welchen Wert B oder C Du angibst. C funktioniert alleine, B ohne C nicht. Ergo, ist C zwingend nötig. B ist wohl wie Georg schrieb nur aus Kompatibilitätsgründen, oder nach Jimmy für Debugzwecke vorhanden. C muss sein.
@Jimmy: Weißt Du, was _EarlyBoundCodeblock() macht?
Gruß Klaus
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: OrdCondSet, [<cForCondition>] muss sein
Bruce Anderson
16. August 1999
archived.xbase++.beta17
EarlyBoundCodeblocks
Antwort
Charles Cremer <support@krsenterprises.com>
8. Juni 2000
public.xbase++.bugreport
_EarlyBoundCodeBlock() is not doc'ed
Antwort
Wolfgang Müller <wm@de.alaska-software.com>
9. Juni 2000
16. August 1999
archived.xbase++.beta17
EarlyBoundCodeblocks
Antwort
****************************************************************************************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:
In SL1, the FILTER command was preprocessed toCode: Alles auswählen
cFilter := "My filter condition" SET FILTER TO &cFilter
Due to the late binding feature, the filter expression was then macro-compiledCode: Alles auswählen
DbSetFilter( {|| &cFilter }, cFilter )
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.:This is basically what _EarlyBoundCodeBlock() is good for.Code: Alles auswählen
cFilter := "My filter condition" bFilter := &( "{||" + cFilter +"}" ) DbSetFilter( bFilter, cFilter )
--
With best regards
--
Your Xbase++ Public Beta Team
Charles Cremer <support@krsenterprises.com>
8. Juni 2000
public.xbase++.bugreport
_EarlyBoundCodeBlock() is not doc'ed
Antwort
Wolfgang Müller <wm@de.alaska-software.com>
9. Juni 2000
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
gruss by OHR
Jimmy
Jimmy
- Klaus Schuster
- Foren-Administrator
- Beiträge: 371
- Registriert: Do, 24. Jan 2008 10:01
- Wohnort: 90762 Fürth
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 9 Mal