CPU Auslastung

[Martin Altmann]

Hallo Manfred,
wie sieht denn cArbeit nach dem Aufrufen dieser Zeile aus? Schau Dir das doch mal im Debugger an und poste mal hier den Inhalt von cArbeit. Ergänzt um die Felddefinitionen in der Datenbank für das betreffende Feld...

Viele Grüße,
Martin

[Manfred]

Hi Martin,

im fertigen Codeblock sieht es nachher so aus (1)->feld.

Das ist ja dann numerisch.

[Manfred]

Hi Martin,

wir haben uns überschnitten....

es sieht nachher so aus:

beim Lesen
objekt:id := (1)->id

beim Schreiben
(1)->id := objekt:id

beides ist richtig und beide sind numerisch und beide haben 0 als Wert stehen laut Debugger.

Ich habe mal als Test nicht vom Anfang der Felder angefangen, sondern erst ab dem 2.Feld. Das gleiche Ergebnis. Die Membervar ist richtig und hat den gleichen Wert wie das Feld.

Ich schätze mal, ich mache irgendwo einen Denkfehler und sehe ihn einfach nicht. Anfangs dachte ich, die Membervars müßten erst initialisiert und von NIL befreit werden, aber beim Schreiben ist das ja schon der Fall, dass alle Membervars mit irgendeinem richtigen Wert belegt sind.

Ich kann mit der Fehlermeldung nichts anfangen.

Es wird wieder bestimmt was ganz blödes sein, wie immer.

[Martin Altmann]

Hallo Manfred,

Es wird wieder bestimmt was ganz blödes sein, wie immer.

wahrscheinlich - ich kann hier nämlich nichts fehlerhaftes entdecken...
Naja - bei dem schönen Wetter werde ich jetzt eh' erstmal auf den Weinberg der nördlichsten für den Qualitätsweinanbau zugelassene Reblage der Welt steigen und es mir gut gehen lassen...

Bis heute abend,
Martin

[Manfred]

Hi Martin

viel Spaß

hier ist Aprilwetter.

[brandelh]

Hallo Manfred,

zu deinem Objekt im Codeblock, der aus einem String zusammengebastelt und dann mit & übersetzt wird, kann ich nur vermuten, dass das was dabei rauskommt kein gültiges Objekt mehr ist. Sowas habe ich nie gemacht und damit auch keine Erfahrung.
Objekte verwende ich in Codeblöcken immer nur direkt: {|| ::SLE:index ...} und da gab es nie Probleme.

Aber ich möchte dich nochmals auf meinen Vorschlag hinweisen:

statt je Feld eine IVAR zu nutzen, wäre ein protected array mit { feldname, feldinhalt } sinnvoller.

Dann könntest du statt oDB:&(cFeldname) einfach oDB:getFeld(cFeldname) oder nFeldNummer etc nutzen.

[Manfred]

Hi Hubert,

das mit dem Array verstehe ich im Moment nicht. Ich kann Dir nicht folgen, tut mir Leid.

Das mit dem Objekt, sollte doch so wurscht sein. Es klappt wenn ich es mit & Operator verbinde. So steht es auch in der Anleitung. Wenn ich es über einen Codeblock mache, dann steht es genau so, als wenn ich die Var direkt angebe. Ich vermute einfach, dass irgendwo ein Denkfehler vorliegt.

Ich hatte in einem ähnlichen "Codeblock" die gleiche Fehlermeldung. Dabei hatte ich aber die || Zeichen vorher vergessen. Ich kenne mich einfach nicht gut genug mit den Codeblöcken aus, als das ich darauf kommen könnte.

Wobei sich mir jetzt allerdings die Frage stellt, ob die Sache mit dem Codeblock als Ersatz für das Macro einen Tempogewinn bringt. Das wollte ich eigentlich nur testen. Die Routine Lesen und Schreiben von feldern wird doch recht häufig aufgerufen. Es wäre Schade, wenn dadurch die Performance leiden würde.

[brandelh]

Hallo Manfred,

ich vermute deine Init sähe bei einer DBF mit 3 Feldern so aus:

Code: Alles auswählen

var Name // -> 1. Feld der DBF
var PLZ    // -> 2. Feld der DBF
var Ort     // -> 3. Feld der DBF

und in den Methoden füllst du dann die ivar Feldvariablen

Code: Alles auswählen

oDB:Name :=  nDB->Name ...

du könnstest statt dessen 2 Arrays vorhalten:

Code: Alles auswählen

protected:
var aStruktur // da wird die Struktur gespeichert dbstruct()
var aRecord   // da kommt der Inhalt der Felder rein

in der INIT würdest du aRecord mit der Anzahl der Felder anlegen und dem Typ aus aStruktur vorbelegen (Blankdatensatz).

in der Methode würdest du dann folgendermaßen den Datensatz in die Felder schreiben:

Code: Alles auswählen

for x := 1 to len(::aStruktur) // jedes Feld lesen
     ::aRecord[x] := nDB->(fieldget(x))
next

Du bräuchtest je eine Methode FieldGet / FieldPut die dann auch Feldnamen akzeptiert und in Feldnummern umsetzt:

Code: Alles auswählen

method oDB:FieldGet(xVar)
     local nFeldNum,xInhalt
     nFeldnum := 0
     do case 
         case ValType(xVar)="N"
              nFeldNum := xVar
         case ValType(xVar)="C"
              xVar = upper(alltrim(xVar))
              nFeldNum := ascan(::aStruktur,{|cFeld| cFeld == xVar}) 
     endcase
     if nFeldNum > 0 .and. nFeldNum <= len(::aStruktur)
        xInhalt := ::aRecord[nFeldNum]
     else
        xInhalt := NIL
        ... Fehlermeldung ?
     endif
return xInhalt      

Ich denke dieser Ansatz würde die & Ersetzung unnötig machen und damit das Ganze deutlich übersichtlicher. Deine Klasse könnte ohne Änderungen mit allen DBF zurechtkommen.

[Manfred]

Hi Hubert,

ich habe bisher immer Variablen zwischen den Feldern einer DB gesetzt, damit ich bei GETs nicht direkt in die DB geschrieben habe. Das ging mir irgendwann auf die Nerven, weil man die einzelnen VAR immer mitschleppen mußte usw. Jetzt benutze ich Membervar und brauche nur noch das Objekt mitzunehmen. So wie ich Deinen Vorschlag sehe, ist der Vorteil doch dann weg?

[brandelh]

Hallo,

du hast weiterhin ein Objekt deiner DB Klasse, welche aber keine iVar pro Feld definiert (eine eigene Klasse pro DBF) sondern diese Werte in 2 Arrays intern hält - also versteckte Arrays in dieser Klasse.

Das Einzige was sich extern ändert ist der Zugriff darauf:

statt

oDB:&(cFeldname) // was ja Ärger verursacht

dies verwenden

oDB:getFeld(cFeldName) // oder wie die Funktion immer heißen soll.

Aber wenn du keinen Vorteil darin siehst, spar dir die Arbeit.
Ich kann von hier aus nicht beurteilen wo mehr Probleme lauern.

Nur weil ich es so machen würde, muss es für dich nicht richtig sein.

[Manfred]

Stop, Stop, Stop,

jetzt sehe ich glaube ich unser Mißverständnis.

das Objekt:&(cField) macht keine Probleme, das klappt ja.

also hier nochmal:

Code: Alles auswählen

objekt:&(cField) := (alias())->(fieldget(nI))

das klappt. Aber durch das Macro war/bin ich der Meinung, das es nicht das maximale Tempo erreicht.

Was bei mir Probleme macht, ist das hier:

Code: Alles auswählen

cArbeit := "{|objekt| objekt:"+cField+" := ("+alltrim(str(nAlias))+")->"+cfield+"}"

sobald das über eval (wie anfangs zu sehen) ausgwertet wird, kommt die Fehlermeldung.

[brandelh]

Aber durch das Macro war/bin ich der Meinung, das es nicht das maximale Tempo erreicht.

Die Geschwindigkeit ist doch nur bei einer großen Anzahl Aufrufen pro Arbeitsschritt wichtig. Und die codeblock Bildung über String, dann Umwandlung über & und danach eval ... mit einigen Funktionsaufrufen, dürfte kaum messbar - wenn überhaupt - schneller sein.

[Manfred]

Das wollte ich ja austesten.

Bei jedem Skip z.B. wird diese Routine aufgerufen zum Lesen und zum Schreiben.

Aber so wie es aussieht wird es keinen Test geben.

[Manfred]

Tach auch,

da ich ja eine Nervensäge sein kann, habe ich mal wieder gesägt. Siehe da, dass Problem scheint gelöst:

Hallo Herr Kunz,

Sie führen ein Eval() mit einem Codeblock durch, der einen Parameter
erwartet. Versuchen sie doch mal:

FOR nI := 1 TO LEN(aKopieren)
EVAL(aKopieren[nI], object)
NEXT

Bitte sparen sie sich auch noch den Funktionsaufruf von Len(). Der muss
sonst bei jeder Iteration ausgeführt werden:

nLen := LEN(aKopieren)
FOR nI := 1 TO nLen
EVAL(aKopieren[nI], object)
NEXT

Man kann sich noch die loop sparen, was aber vielleicht garnicht so
dramatisch viel ausmacht:

AEval( aKopieren, {|b| Eval(b, object) } )

Wenn Sie den Code unlesbar machen wollen oder sicherstellen wollen, dass
er von keinem mehr gelesen werden kann, dann machen sie:

aStruct := DbStruct()
AEval( aStruct, {|str| Eval(&("{|o| o:"+str[1]+" := (ALIAS())->"+str[1]+"}"), object) } )

Falls letzteres nicht funktioniert, verweigere ich aber Hilfe, den Fehler zu finden

Ich habe ihr Codefragment übrigens nicht ausprobiert. Wenn das Problem
nicht behoben ist, dann melden sie sich nochmals.

Mit freundlichen Grüssen,
Andreas Herdt
Alaska Technical Support

bestellt Andreas Herdt mal schöne Grüße von mir, wenn ihr den auf der DevCon demnächst sehen solltet.

Ich hoffe er hat nichts dagegen, wenn ich das hier poste. Ist ja schließlich für alle Xbase++ler interessant.

[Jan]

Manfred, bitte gib nicht so viele Probleme an Alaska. Mit jeder Frage, die Andreas Dir beantworten muß, wird 1.9 noch später ausgeliefert.

Jan

[Manfred]

Hm,

sorry, wird nicht wieder vorkommen



Dann dürfen die aber auch nicht zu den Cowboys fahren.....

[Manfred]

noch ne Kleinigkeit,

Code: Alles auswählen

FOR nI := 1 TO nFcount 
      cFeld   := (oZiel:nArea)->(FieldName(nI))
      cArbeit := "{|oZiel,oQuelle| (oZiel:nArea)->"+cFeld+" := oQuelle:"+cFeld+"}"
       bArbeit := &(cArbeit)
       AAdd( aKopieren, bArbeit)
NEXT

AEval( aKopieren,{ |b| Eval( b, oQuelle, oZiel ) } )

Ich habe jetzt mal zwischendurch das Problem, dass bei dem Aeval eine Fehlermeldung produziert wird. Weil angeblich ein Feld keine Datenbankfeld ist. Was aber auf jeden Fall nicht sein kann.
Wie kann ich denn jetzt herausfinden, an welcher Stelle das Aeval gerade steht, um evtl. Fehler abzufangen?

Es ist jetzt nur ein kurzer Ausschnitt, aber das Aeval steht in einem Begin Sequence. Bisher hatte ich cFeld abgefragt, aber wie mir dann in einem lichten Moment aufgefallen ist, steht in cFeld immer das Letzte, was oben in der Schleife eingetragen wurde. Das heißt dann, mit dem Wert kann ich nichts anfangen.

jetzt habe ich Aeval ein bisschen erweitert:

Code: Alles auswählen

AEval( aKopieren,{ |b| nX++, Eval( b, oQuelle, oZiel ) } )

wenn jetzt ein Fehler auftaucht, weiß ich zumindest in welchem "Satz" von aKopieren es passiert ist. Aber was kann ich dann damit anfangen? Wie müßte ich jetzt vorgehen, um die direkte(n) Vars, oder Felder anzupacken, die gerade in der Abarbeitung sind?

ich bekomme ja aKopieren[nx] zurück und darin steht in diesem Falle

aKopieren[nX] {|oZiel, oQuelle| (oZiel:nArea)->feldname := oQuelle:varname}

[Martin Altmann]

Moin Manfred,

jetzt habe ich Aeval ein bisschen erweitert:

Code: Alles auswählen

AEval( aKopieren,{ |b| nX++, Eval( b, oQuelle, oZiel ) } )

Warum so umständlich? Bei AEval wird im zweiten Parameter des Codeblocks automatisch der Zähler (Schleifendurchlauf) mitgegeben!

Code: Alles auswählen

AEval( aKopieren,{ |b, nX| Eval( b, oQuelle, oZiel ) } )

Viele Grüße,
Martin

[Manfred]

Hi Martin,

das stimmt, aber wenn ein Fehler in Aeval() auftritt, dann springt das Programm da raus. Und so wie ich meine festgestellt zu haben, ist dann der Zähler nicht mehr bekannt. Und genau dann brauche ich ihn um die Arrayposition zu sehen, wo es passiert ist.

[Martin Altmann]

Ah - OK!
nun gut - übergib den Zähler als Parameter Deiner Funktion und setze darin den Breakpoint...

Aber egal, wenn es nur zum Debuggen gebraucht wird...

Viele Grüße,
Martin

[Manfred]

Hm,

was ich damit noch alles zaubern kann, weiß ich noch nicht, aber es dient hauptsächlich meiner Datenbankklasse zum Lesen/speichern der Felder. Da ist dann ein Begin Sequence drum und eine eigene Fehlerroutine. Die bekommt dann das Errorobjekt. Mal sehen, da ich ja weiß, woher das kommt, könnte man so auch direkt das Feld lokalisieren, falls man den Fehler im Testsystem nicht simulieren kann/könnte.