OrdCondSet, [<cForCondition>] muss sein [erledigt]

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Antworten
Benutzeravatar
Klaus Schuster
Foren-Administrator
Foren-Administrator
Beiträge: 366
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]

Beitrag von Klaus Schuster »

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>?
Zuletzt geändert von Klaus Schuster am Di, 01. Mai 2018 8:32, insgesamt 1-mal geändert.
Gruß Klaus
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: OrdCondSet, [<cForCondition>] muss sein

Beitrag von georg »

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.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
DelUser01

Re: OrdCondSet, [<cForCondition>] muss sein

Beitrag von DelUser01 »

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... :-)
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: OrdCondSet, [<cForCondition>] muss sein

Beitrag von AUGE_OHR »

siehe dir mal den PPO Code von INDEX ON ... FOR an

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. )
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
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().
Anmerkung :
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
Benutzeravatar
Klaus Schuster
Foren-Administrator
Foren-Administrator
Beiträge: 366
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

Beitrag von Klaus Schuster »

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?
Gruß Klaus
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: OrdCondSet, [<cForCondition>] muss sein

Beitrag von AUGE_OHR »

Bruce Anderson
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:

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
****************************************************************************************

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
Benutzeravatar
Klaus Schuster
Foren-Administrator
Foren-Administrator
Beiträge: 366
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

Beitrag von Klaus Schuster »

Danke, Jimmy!
Gruß Klaus
Antworten