Probleme mit DbSeek() [Erledigt]

[Jan]

Irgendwo stecke ich mal wieder in der Schleife im Kopf fest.

Ich arbeite mit einer DBF, deren dazugehöriger Index so aufgebaut wird: AllTrim(feld1) + AllTrim(feld2) + AllTrim(feld3) + AllTrim(feld4). Die Felder sind Character, der Inhalt sind immer Ziffern.

Die vier Felder sollen eine Hierarchie aufbauen. Mit Punkten als Trenner würde das also so z. B. aussehen:
1
1.1
1.1.1
1.1.1.1
1.1.1.2
1.1.1.3
1.1.2
1.1.2.1
1.1.2.2
1.1.2.3
1.2
usw.

Wenn ich jetzt den Wert 1355 suche (1.35.5), dann gibt DbSeek() mir immer ein .T. zurück. Obwohl es definitiv keinen Satz gibt, der das beinhaltet. Noch merkwürdiger, der steht immer auf Satz 1 mit dem Indexeintrag 1. Egal ob Softseek .T. oder .F.

Wo ist da mein Gedankenfehler?

Jan

[Markus Walter]

Hi,

ohne es probiert zu haben: Das könnte mit SET EXACT, bzw. mit der Art, wie dbseek auf Gleichheit prüft, zu tun haben. Gerade bei unterschiedlichen Längen von Strings verhalten sich == oder = unterschiedlich (in Abhängigkeit von SET EXACT). Ich verwende nie trim in Index-Ausdrücken.

[UliTs]

Hallo Jan,

bei Indizes muß man meines Erachtens immer mit festen Schlüssellängen arbeiten!
Versuch mal

Code: Alles auswählen

Left( AllTrim(feld1) + AllTrim(feld2) + AllTrim(feld3) + AllTrim(feld4)+space(40),40 )

als Schlüssel (Länge bei Bedarf kürzen oder erweitern).

Klappt das zu Deiner Zufriedenheit?

Uli

[Jan]

Hallo Ihr Beiden,

ja klar! Ich Dösbaddel. Werd ich sofort ausprobieren.

Jan

[brandelh]

Ich zitiere mal aus dem Handbuch:

Ein Indexausdruck muß stets einen Wert von konstanter Länge liefern. Eine Indexierung von Zeichenwerten mit Hilfe der Funktion RTrim() führt zu einem defekten Index, da die resultierenden Werte eine unterschiedliche Länge haben, wenn sie Leerzeichen am Ende besitzen.

leider steht das nur beim Befehl INDEX und nicht auch bei OrdCreate() ...

[Jan]

Hallo Hubert,

ansich ist mir absolut klar, das ein Indexausdruck immer die gleiche Länge haben muß. Da aber der schon bestand, habe ich einfach nicht daran gedacht, den mal zu überprüfen oder zu überdenken.

Abgesehen davon: Sooo einfach ist das nicht. Denn wenn ich das mache wie Uli das vorgeschlagen hat (was dann auch einfacher über PadR(..., 40) hätte erstellt werden können): Das funktioniert natürlich nicht. Denn der sortiert dann die 35 vor die 4. Da ja die 3 kleiner als die 4 ist, egal was dahinter noch so alles kommen mag. So klappt das dann aber: PadL(AllTrim(feld1), 3) + PadL(AllTrim(feld2), 3) + PadL(AllTrim(feld3), 3) + PadL(AllTrim(feld4), 3). Dann habe ich immer die gleiche Länge, und die Sortierung passt auch wieder. ist halt das alte Problem: Wie sortiere ich numerische Einträge, die als String zur Verfügung stehen?

Danke für Euren eindeutigen Hinweis.

Jan

[AUGE_OHR]

bei Indizes muß man meines Erachtens immer mit festen Schlüssellängen arbeiten!

was sich auf Type "C" bezieht aber nicht auf Type "N" ... oder ?

[AUGE_OHR]

Code: Alles auswählen

PadL(AllTrim(feld1), 3) + PadL(AllTrim(feld2), 3) + PadL(AllTrim(feld3), 3) + PadL(AllTrim(feld4), 3)

wie wäre es mit STRZERO() ?

Wie sortiere ich numerische Einträge, die als String zur Verfügung stehen?

ohne "." dazwischen ?

Code: Alles auswählen

INDEX ON VAL(String) TO MyIndex

[brandelh]

bei Indizes muß man meines Erachtens immer mit festen Schlüssellängen arbeiten!

was sich auf Type "C" bezieht aber nicht auf Type "N" ... oder ?

Die gleiche Schlüssellänge gilt zwingend IMMER
INDEX on NUMFELD ... wird aber NUMFELD automatisch immer gleich anlegen (vermutlich intern mit str(,nFeldLen) ).

[Jan]

Jimmy,

StrZero() ist eine gute Idee. Der Rest ist nicht zu gebrauchen. Ich hatte z. B. niemals angedacht, einen "." in den Indexauftrag aufzunehmen. Die hatte ich in meiner Aufstellung nur eingefügt, um den Zweck der vier Felder zu versinnbildlichen.

Jan

[AUGE_OHR]

(vermutlich intern mit str(,nFeldLen) ).

"fast" getroffen

Num_Index.PNG (16.44 KiB) 5937 mal betrachtet

scheint STRZERO() zu sein

[brandelh]

STR() oder STRZERO() sind beide gleich gut für den Index, solange man kein alltrim()/trim() einsetzt
Führende Blanks und führende Nullen sind kleiner als die anderen Zahlen, somit stimmt die Sortierung
Auch deine Punkte sind kein Problem, solange du die Stellen beachtest und natürlich muss der Suchbegriff entsprechend stimmen ...

Wenn du nach "1" suchst, aber vorher Str(1,3) bzw. StrZero(1,3) verwendest, wirst du nie etwas finden ...

Bei komplexen Indexbegriffen eignen sich Funktionen besser, zum Indizieren und zum Suchen:

Code: Alles auswählen

function MeinIndex( nKapitel, nUnterkapitel, ..., )
return str(nKapitel,3)+str(nUnterkapitel,3)....   // hier muss man genau rechnen oder großzügig Platz lassen.

Beim Suchen (und nur dort) kann man dann mit RTrim(MeinIndex( nKapitel, nUnterkapitel, ..., )) den ersten Eintrag suchen.
Falls die Felder (Kapitel, Unterkapitel) nicht in eigenen Feldern stehen, muss man das Indexfeld mit dieser Funktion replacen und direkt indizieren.

[UliTs]

(vermutlich intern mit str(,nFeldLen) ).

"fast" getroffen

Num_Index.PNG

scheint STRZERO() zu sein

Und die Länge und Anzahl der Nachkommastellen wird vom Feld genommen, über das der Index läuft .
-
Spannend wird es aber, wenn man Ausdrücke verwendet, z.B. Field->LagerNr*100+Field->LagerPosNr+Field->LagerUNr/100 .

Uli

P.S. Spätestens dann sollte man den Index über einen Stringausdruck aufbauen

[georg]

Hallo,


... oder den absurden Gedanken fassen, auf SQL umzusteigen.

SQL kann nämlich mit numerischen/alphanumerischen Werten in der SELECT-Anweisung oder einem INDEX umgehen.

[brandelh]

Ja wenn wir es denn endlich einmal hätten

[georg]

Hallo, Hubert -


wir haben's doch, wenn wir mit SQLExpress oder mit Hector's MySQL oder PostgreSQL Klasse arbeiten.

Wer allerdings alles ohne Änderungsaufwand umstellen will, der wird wohl noch eine kleine Weile warten müssen. Vielleicht bringt's ja der Weihnachtsmann?