Inoffizielles deutsches Xbase-Forum

Gerade hab ich etwas gefunden, von dem ich nicht weiß: Ist das Dämlichkeit von mir, ist das ein Denkfehler, oder ist das ein Bug? Es geht um folgende Zeile: Wenn ich das so codiere, dann rechnet die Zeile korrekt. Es wird gezählt, wie viele Datensätze es gibt, in denen im Feld "Feldname" der Wert "nWert" steht. Aber wenn ich statt "Feldname" schreibe: "cAlias->Feldname", dann wird praktisch ein LastRec() ausgeführt.

Wo liegt da der Fehler? Oder ist es heute Abend einfach nur schon zu spät?

Jan

Hallo Jan,
soweit ich weiß, unterstützen diese "alten" Befehle keine Alias-Angabe!
Dies müßte dann mit cAlias->(DbEval(.... gelöst werden.
Gleiches gilt auch für Delete, SUM, AVERAGE, TOTAL, pack, zap, .... - da gibt es dann auch entsprechende Pendants.

Viele Grüße,
Martin

Hallo Martin,

wenn das wirklich so ist, dann wäre meiner Meinung nach ein enstprechender Eintrag in der Dokumentation fällig. Wenn ich nicht genau gewusst hätte, was da hätte rauskommen müssen, woher hätte ich dann merken sollen, daß das Ergebnis falsch ist?

Jan

Hallo Jan,
so war das doch - glaube ich - schon unter Clipper, oder?
Da gab es nämlich diese Form der Adressierung nicht in dem jetzigen Umfang - nur für die Felder...
Dafür gibt es unter Xbase++ ja sowohl Datenbankbefehle als auch Datenbankfunktionen - erstere müssen nach einem Select der entsprechenden Workarea ausgeführt werden und letztere können die Workarea vorangestellt bekommen...

Viele Grüße,
Martin

Martin,

wie das unter Clipper war weiß ich nicht mehr. Da habe ich aber, soweit ich mich erinnere, auch nicht so streng mit Aliasen gearbeitet. Also war mir das damals wohl noch ziemlich egal.

Dennoch denke ich, es sollte einen entsprechenden Eintrag in die Doku geben. Denn es gibt weder einen Compilier- noch einen Laufzeitfehler. Einfach nur ein falsches Ergebnis.

Jan

Hi,

auch unter Clipper konnte man das Feld mit dem Alias ansprechen, aber genau überlegen was passiert:

use MyDBF alias DB1 NEW
use XYDBF alias DB2 NEW

* selectiert ist DB2 ...

count to ... for DB1->Name="TEst"

geskipt wird durch DB2 (= selectiert) aber verglichen mit Feld aus DB1.
Wehe wenn die Feldnamen gleich sind und keine Fehlermeldung erscheint.

Bei deinem Beispiel hattest du noch cAlias->Feld, das müsste (cAlias)->Feld lauten.

Hallo,

ich hatte vor kurzem mit dem Befehlt SUM ein ähnliches Problem. Hier kommt die Lösung.

http://www.xbaseforum.de/viewtopic.php?t=1639

Auszug aus der Doku zu SUM:
Beschreibung:
Der Befehl SUM berechnet die Summe eines oder mehrerer numerischer Ausdrücke aus den Werten der Datensätze in der aktuellen Workarea. Durch Angabe einer Bedingung oder der Anzahl von Datensätzen kann der Bereich für die Summierung eingeschränkt werden. Die Summe jedes numerischen Ausdrucks in <nExpression,...> wird einer Variablen in der Liste <VarName,...> zugewiesen.

Auszug aus der Doku zu COUNT:
Beschreibung:
Der Befehl COUNT zählt die Anzahl der Datensätze in der aktuellen Workarea, welche mit den angegebenen Bedingungen übereinstimmen. Der Zählbereich kann durch die Optionen NEXT oder REST eingeschränkt werden. Das Ergebnis wird der Variablen <VarName> zugewiesen.

genau das wollte ich sagen, er arbeitet immer in der aktuellen, auch wenn man in der FOR Bedingung auf eine andere verweißt. Somit wird für die Bedingungsprüfung eine andere Workarea verwendet, die Ergebnisse mehr oder minder vom Zufall bestimmt.

Die Befehle sind halt etwas unflexibel, daher gibt es ja oft DB... Funktionen (SKIP -> DBSKIP() ) und die Funktion zum ersetzen der Datenbankbefehle ist DBEVAL()

Bertram,

ja, das habe ich auch gelesen.

Das Problem ist nur: Wenn man COUNT einsetzt MIT Alias, dann rechnet der Kommentarlos falsch. Das war ja mein Problem. Ich bin im korrekten Workarea, gebe aber dennoch den Alias an, und schon ist das Ergebnis falsch. Ohne irgendeine Rückmeldung, z. B. seitens des Compilers oder des Laufzeitsystems.

Jan

Jan,

ich bin mit SUM auch fast verzweifelt. Habe ich SUM mit Alias auf einem Datensatz ausgeführt der meiner FOR Bedingung entsprach, bekam ich ein Ergebnis. Dann habe ich nur die FOR Bedingung erweitert (der Datensatz auf dem ich SUM ausgeführt habe entsprach somit nicht mehr der FOR Bedigung) und als Ergebnis bekam ich den Wert 0.
Jetzt steht vor dem SUM ein dbselectarea("alias") und die Berechnung stimmt.
Ich wünsche mir Funktionen wie alias->(dbsum()) oder alias->(dbcount()).

Hallo Bertram,

Bertram Hansen hat geschrieben:Ich wünsche mir Funktionen wie alias->(dbsum()) oder alias->(dbcount()).

gibt es doch schon - im Prinzip
Schau Dir mal DbEval() an, damit kann man das umsetzen...

Viele Grüße,
Martin

Hey Martin,

dann können wir doch gleich die Hälfte (mindestens) aller XBParts rausschmeißen. Die sind ohnehin mit Xbase++ geschrieben. Kann also auch jeder gerne selber entwickeln.

Aber ich kann Bertram schon verstehen: Wenn möglich greife ich auch gerne auf die Funktionen zurück. Bei den meisten Befehlen geht das ja auch, insbesondere die ganzen Db...()-Geschichten. Nicht, weil ich gerne die neue, modernen Sachen nutze (eher ganz im Gegenteil). Aber es hat meist einen ganz praktischen Grund. Die ersetzenden Funktionen sind meist flexibler, und sie sind im Aufruf meist auch stringenter. Bei den Befehlen beschlich mich manchmal einfach das Gefühl, hier wird diese Reihenfolge genommen, dort eine andere.

Jan

Ist zwar ein ganz altes Thread, aber...
Es gibt anscheinend eine Funktion dbcount(), sie erwartet mindestens einen Parameter, es ist aber nicht klar, was für einen Typ er haben soll.
Zwar würde ich Martin im Normalfall Recht geben, dbeval() ist im Code ausreichend, aber im Debugger (Ausdruck-Inspektor) wäre dbcount() sehr hilfreich...

In der 2.0 Hilfe kann ich die nicht finden, eventuell im SYS ordner eine versteckte Funktion ?

Ich denke dass ein Suchbegriff sinnvoll wäre z.B. ein codeblock der die Suchbedingung festlegt, unter der die Funktion die Sätze zählt.
Oder war das nicht ein Beispiel für eine Anwendung zu dbeval() ?

brandelh hat geschrieben: ↑Mi, 06. Mai 2020 10:33 Oder war das nicht ein Beispiel für eine Anwendung zu dbeval() ?

Eben, man kann im Debugger keine Variable definieren wo das Codeblock das Ergebnis sammeln kann...

In der Hilfe von 2.0 unter DbRelease()
wird im Beispiel die FUNC DBCOUNT
erstellt mit dbeval()

bei komplexeren Sachen lege ich die in eine Funktion und die Funktion in den Codeblock, dann geht nicht nur der Debugger im Codeblock, sondern die Test sind auch einfacher zu machen (direkter Aufruf aus Testprogramm)

Klar könnte ich in jede Anwendung eine triviale Funktion wie unten einfügen - dafür bedarf es nicht mal ein Codeblock.
Es geht mir aber darum, z.B. spontan im Debugger nachschauen zu können, wieviele Datensätze in einem Workarea vorhanden sind (wenn irgendwo weit entfernt im Code vielleicht Filter, Scope, Indexbedingungen u.s.w. gesetzt wurden).
Alles nur "wäre schön wenn"...
Alaska könnte theoretisch so viel machen um den Debugger in dieser Hinsicht leistungsfähiger zu machen (von dynamisch deklarierten Variablen bis hin zu einem "Workarea Explorer"), aber ich sehe schon ein, dass sie andere Prioritäten setzten.