DbScope Irritation [erledigt]

[Klaus Schuster]

Moin,

in ScopeTest.dbf befindet sich ein Datensatz mit zwei IDs und einem Datum (u.a.). K_Id = 63, EO_Id = 4. E_Datum hat den Wert 20.08.2023.
Es wird ein CDX-Index mit DToS( field->E_Datum ) + field->K_Id + field->EO_Id erstellt.

K_Id = 63, EO_Id = 4

scopetest->( dbSetScope( SCOPE_TOP, '20230801' + cK_Id + cEO_Id ))
scopetest->( dbSetScope( SCOPE_BOTTOM, '20230831' + cK_Id + cEO_Id ))

scopetest->( dbSetScope( SCOPE_BOTH, '20230820' + cK_Id + cEO_Id )) OK

K_Id = 63, EO_Id = "" // EO_Id ist leer!

scopetest->( dbSetScope( SCOPE_TOP, '20230801' + cK_Id + cEO_Id ))
scopetest->( dbSetScope( SCOPE_BOTTOM, '20230831' + cK_Id + cEO_Id )) Fehler: Satz wird trotz leerer EO_Id gefunden

scopetest->( dbSetScope( SCOPE_BOTH, '20230820' + cK_Id + cEO_Id )) OK

// Mit abweichenden Daten TOP 20230819 BOTTOM 20230820: OK
// Mit abweichenden Daten TOP 20230819 BOTTOM 20230820: OK
// Mit abweichenden Daten TOP 20230820 BOTTOM 20230821: Fehler
// Mit abweichenden Daten TOP 20230819 BOTTOM 20230821: Fehler

Ich habe das Projekt angefügt. Vielleicht hat jemand Zeit/Lust damit zu testen.

[komnick]

K_Id = 63, EO_Id = "" // EO_Id ist leer!

scopetest->( dbSetScope( SCOPE_TOP, '20230801' + cK_Id + cEO_Id ))
scopetest->( dbSetScope( SCOPE_BOTTOM, '20230831' + cK_Id + cEO_Id )) Fehler: Satz wird trotz leerer EO_Id gefunden

Hallo Klaus,

du suchst nach dem Datensatz mit Such-Key "20230820"+"63"+"4", also
"20230820634". In der Varainte EO_Id="" setzt du SCOPE_TOP auf
"2023080163" und SCOPE_BOTTOM auf
"2023083163".

Dein Satz wird gefunden (weil
"20230820634" zwischen
"2023080163" und
"2023083163" liegt).
Das scheint mir ein korrektes Programmverhalten.
Du schreibst an diese Zeile "Fehler: Satz wird trotz leerer EO_Id gefunden".
Richtig ist aber: "Kein Fehler: Satz wird gefunden, weil er im Bereich liegt".

Beste Grüße
Martin

[Klaus Schuster]

Danke für Deine Antwort. Leider war mein Text unkorrekt. Ich habe die 63 und di4 4 ohne Hochkomm geschrieben und nur zur Illustration gemeint. Tatsächlich wird es so geschrieben 'JJJJMMTT' + Padl( K_Id, 10 ) + Padl( EO_Id, 10 ). Du kannst es im Quellcode nachvollziehen.
Claudia, Peter haben es soeben mit dem ADS Architekten versucht und sind auf die gleichen Irritationen gestoßen.

[Martin Altmann]

Probiere es mal mit strzero() statt padl. Paranoia: Mach noch ein alltrim() drumherum:

Code: Alles auswählen

'JJJJMMTT' + alltrim( stzero( K_Id, 10 ) ) + alltrim( stzero( EO_Id, 10 ) )

Viele Grüße
Martin

[komnick]

Ob mit oder ohne PADL(), das ändert nichts an meiner Antwort.
Ich denke, das Programm arbeitet korrekt und nur deine Erwartung ist falsch.

"20230820"+PADL("63",10)+PADL("4",10)
wird zwischen
"20230801"+PADL("63",10)
und
"20230831"+PADL("63",10)
einsortiert.
Deshalb wird der Satz gefunden.

Oder auch:
"20230820"+PADL("63",10)+PADL("4",10)
wird zwischen
"20230801"+PADL("63",10)+PADL("",10)
und
"20230831"+PADL("63",10)+PADL("",10)
einsortiert.
Deshalb wird auch so der Satz gefunden.

[komnick]

Aber:
"20230820"+PADL("63",10)+PADL("4",10)
wird NICHT zwischen
"20230819"+PADL("63",10)+PADL("",10)
und
"20230820"+PADL("63",10)+PADL("",10)
einsortiert [sondern liegt hinter "20230820"+PADL("63",10)+PADL("",10)].
Deshalb wird HIER der Satz NICHT gefunden.

[AUGE_OHR]

hi,

ich habe alles mal als ZAHL dargestellt

2023081900000000630000000000
2023082000000000630000000003
2023082000000000630000000004
2023082000000000630000000004

damit liegt alles im Bereich 20230801xxx - 20230831xxx

Frage : ist das Datum in Index "notwendig"

p.s. die FELDer field->K_Id und field->EO_Id würde ich numerisch wählen da Type "C" auch linksbündig sein könnte

[Klaus Schuster]

Guten Morgen,

Danke!

@Martin Altmann: Leider unverändert.
@Jimmy: Mit dem Datum schränke ich die Auswahl auf ein bestimmtes Monat ein

Euere Antworten würde ich verstehen, wenn ich als Scope-Wert nur DtoS() (8 Zeichen) angeben würde. Ich gebe aber als Bedingung (zum besseren Verständnis nun mit '0' statt ' ' , auch in der Datenbank, ergänzt) die Zeichenfolge "2023081900000000630000000000" (28 Zeichen, wie im Indexschlüsselwert) an. Im Index steht "2023081900000000630000000004". Da beide gleich lang sind, jedoch unterschiedlich sind, gehe ich davon aus, dass nichts gefunden wird. Etwas anderes wäre es, wenn ich als Bedingung "202308190000000063000000000" (27 Zeichen) angegeben hätte. Dann muss "2023081900000000630000000004" gefunden werden, da die ersten 27 Zeichen in "2023081900000000630000000004" mit der Bedingung übereinstimmen.

@Martin Komnick: Deine Antworten erklären mir auch nicht, warum sich Scope mit _BOTH wie ich erwarte verhält.

[AUGE_OHR]

hi Klaus,

@Jimmy: Mit dem Datum schränke ich die Auswahl auf ein bestimmtes Monat ein

mit deinem SCOPE schränkst du ALLES auf einem einem Monat ein

es ist völlig EGAL was im 2nd FELD (K_Id) oder 3rd. FELD (EO_Id) steht

---

angenommen das 1st FELD wäre "Stunden", 2nd FELD "Minuten" und 3rd FELD "Sekunden"
wenn der SCOPE auf 08:00 - 09:00 steht ist es völlig EGAL was die "Minuten" oder "Sekunden" angeht

[Klaus Schuster]

Yupp, das ist so gewollt

[komnick]

Hallo Klaus,

zu verstehen, wo genau dein Problem liegt, würde leichter fallen, wenn du an deine Tests nicht nur "OK" oder "Fehler" geschrieben hättest, sondern jeweils dein Ergebnis (z.B. "wurde gefunden") und deine Erwartung (z.B. "hätte nicht gefunden werden dürfen"). Dann könnte ich vermutlich besser erklären, warum deine Erwartung falsch ist.

Bei deinem Absatz "Euere Antworten würde ich verstehen..." habe ich leider die Übersicht verloren, über welchen Test du sprichst. Es würde mir helfen, wenn du für diese Tests auflistest:

• SCOPE_TOP=
• SCOPE_BOTTOM=
• Suchkey des Datensatzes=
• Ergebnis des Tests=
• das von dir erwartete Ergebnis des Tests=

Beste Grüße
Martin

[komnick]

Kann es sein, dass du von SCOPE eine Art Filterfunktion erwartest, die SCOPE aber nicht leistet?
SCOPE_TOP= "Abfall"
SCOPE_BOTTOM= "Unfall"
"Anfahrt" würde gefunden werden, obwohl es an 3. bis 6. Stelle nicht "fall" hat, weil es im Lexikon zwischen "Abfall" und "Unfall" einsortiert ist.

[Klaus Schuster]

Hallo Martin,

Danke! für Deinen Einsatz!

Ich habe die Main.Prg so überarbeitet, wie Du dies gewünscht hast. Es werden drei Fälle überprüft. Jeder Fall prüft zwei Varianten von EO_Id. Eine mit EO_Id = '0000000004' und eine zweite mit EO_Id = '0000000000'.

Variante 1. Einsatz von SCOPE_BOTH exakt auf den Indexwert '2023082000000000630000000004'
Variante 2. SCOPE_TOP und SCOPE_BOTTOM exakt auf den Indexwert '2023082000000000630000000004'
Variante 3. SCOPE_TOP '2023080100000000630000000004' (BoM), SCOPE_BOTTOM '2023083100000000630000000004' (EOM)

Die Rahmendaten mit Ergebnis werden angezeigt.

Ich suche übrigens keinen bestimmten Wert, sondern möchte einfach alle zutreffenden Sätze ermitteln.

[Tom]

Ich habe nicht alles gelesen, was hier in diesem Thread ausgeführt wird, aber ich schließe mich den letzten Stellungnahmen bezüglich der Ursachen der Irritation an. Es wird ein anderes Ergebnis erwartet als auf diese Weise erzeugt werden kann. Möglicherweise ändert sich das, wenn das Datum ans Ende der Ausdrücke genommen wird.

[Klaus Schuster]

Hallo Tom,

wenn sich SCOPE_BOTH nicht so verhalten würde wie ich es erwarte, würde ich euere Sichtweise teilen. Die Tabelle enthält exakt einen Eintrag mit dem Index-Eintrag '2023082000000000630000000004'. Warum kommt BOTH in BIld 2 zu einem anderen Ergebnis als Bild 3?

[Tom]

Warum kommt BOTH in BIld 2 zu einem anderen Ergebnis als Bild 3?

Deine Erwartung ist falsch. Der Wert liegt dazwischen und wird richtigerweise gefunden.

Edit: Die 2 an 7. Stelle des Indexwerts liegt zwischen 0 und 3 in den beiden Scope-Werten und ist damit ein Treffer. Was im Ausdruck danach kommt, ist irrelevant.

Du bekommst die von Dir gewünschten Ergebnisse, wenn Du das Datum ans Ende Deiner Ausdrücke nimmst.

[Klaus Schuster]

Guten Morgen Tom,

und Danke. Ich habe nun das Datum nach hinten verschoben und das Ergebnis gibt Dir recht.

Dennoch kann ich nicht verstehen, warum die 0 am bisherigen Ende keine Auswirkung hatte. Meine Erwartung war/ist, dass alle Zeichen in den beiden SCOP_ Angaben jeweils von links nach rechts über die gesamte Anzahl ausgewertet wird. Sie scheint tatsächlich falsch zu sein.

[Tom]

Hallo, Klaus.

Kannst Du denn so jetzt arbeiten? Diese Art des Scopings erlaubt es Dir jetzt, für die beiden nunmehr vorderen Kriterien feste Werte zu wählen und den Datumsbereich variabel zu wählen. Du kannst aber nicht beides gleichzeitig, also z.B. für das zweite Kriterium einen Bereich wählen und zugleich für das Datum, weil das Datum dann nur für den ersten Treffer des zweiten Kritieriums relevant wäre.

Meine Erwartung war/ist, dass alle Zeichen in den beiden SCOP_ Angaben jeweils von links nach rechts über die gesamte Anzahl ausgewertet wird. Sie scheint tatsächlich falsch zu sein.

Es findet ein lexikalischer Vergleich alphanumerischer Werte statt. Die Ziffern sind letztlich Buchstaben. 0 kommt vor 1, A kommt vor B. Wenn - von links beginnend - irgendwo ein A gefunden wird, kann danach kommen, was will - diese Zeichenkette ist immer vor einer Zeichenkette, bei der an gleicher Stelle ein B wäre. Dabei spielt auch keine Rolle, ob die Zeichenketten unterschiedlich lang sind oder so.

[Klaus Schuster]

Ja, danke. Ich habe zwischenzeitlich einen workaround eingebaut, mit dem ich SCOPE nur für den Zeitraum einsetze und dann die paar hundert verbleibenden Datensätze in einer Schleife auf den Rest (Kunden, Ort) prüfe.

[Tom]

und dann die paar hundert verbleibenden Datensätze in einer Schleife auf den Rest (Kunden, Ort) prüfe.

Das geht dann auch bequem mit DbSetFilter(), weil der Filter tatsächlich nur noch die Datensätze anfasst, die dem Scope entsprechen. Scope setzen, ergänzenden Filter setzen, DbGotop() (wichtig!), feddisch.