Suchen / Filter ??

[brandelh]

Hallo Tom,

mein DBEVAL() Beispiel oben hat die Anzahl der Treffer ermittelt und diente als Ersatz für das Filterbeispiel, wobei ich zusätzlich noch Infos ausgegeben habe.
DBEVAL() ist nach meinen Erfahrungen 10 bis 20% schneller als eine do while skip enddo Kombination, bei gleicher Tätigkeit !

Sicherer ist es, weil durch den führenden ALIAS genau eine DBF bearbeitet wird, egal welcher Selectbereich eingestellt ist !

Aber Rolfs Problem wird er erst lösen, wenn er durchliest was ich schon 2 mal geschrieben habe und dir kürzere Suchvariable vor das $ bringt.

Ich werde diesen Thread jetzt ignorieren und mich um meine Probleme kümmern

[Tom]

Hallo, Hubert.

Mmh. Nach dem, was er schreibt, steht in der Variablen ein konkatinierter String ("Meier, Müller") und im Feld jeweils eine Ausprängung davon ("Meier" ODER "Müller"). Der Ausdruck in seinem letzten Beispielcode ist also richtig:

Code: Alles auswählen

TmpAdr->(DbSetFilter( {||  trim(TmpAdr->grpname) $ cGrpSuch}  )) // "grpname" enthält "Meier" ODER "Müller", "cGrpSuch" "Meier, Müller"

So viel zum genauen Durchlesen von Postings.

[Jan]

cGrpSuch steht drin "test1", in tmpadr->Grpname - test1,xing,

So viel zu: Was steht in welchem String/Feld. Rolfs eigene Aussage.

Also stimmt lt. dem hier die Aussage von Hubert. Die sowohl er als auch ich wiederholt haben, die aber von Rolf geflissentlich ignoriert wird. Von daher kann ich verstehen wenn Hubert sich aus diesem Thread zurück zieht - wenn der Fragesteller nicht macht, worauf man ihn hinweist, dann ist ihm halt nicht mehr zu helfen.

Jan

[Tom]

@Jan und Hubert: Oi, ich hatte gedacht, das hätte Marco geschrieben. Schulljung. So herum kann es in diesem Fall natürlich nicht funktionieren.

Aber so arbeitet man auch nicht. Wenn es beispielsweise Kundengruppen gibt und Kunden mehrere Kundengruppen zugewiesen werden können, erzeugt man eine Tabelle, die diese Verbindungen enthält. Also jeweils eine Referenz auf die Kundengruppe (Nummer der Kundengruppe) und dann beispielsweise Kundennummern. Damit fiele auch dieser Filterquatsch weg, denn auf diese Tabelle könnte man einfach einen Scope setzen und parallel eine Relation auf die Kundentabelle. Das wäre auch mit > 100.000 Datensätzen schnell.

[brandelh]

So viel zum genauen Durchlesen von Postings.

was soll ich dazu sagen ... ich finde genau 2 Aussagen von Rolf über den Inhalt der beiden Variablen ... und viele Anfragen nach genaueren Angaben

Rolf Ramacher Betreff des Beitrags: Re: Suchen / Filter ?? Verfasst: Do, 30. Jan 2014 15:44
=> Hinweis nochmal cGrsuch ist eine Textzeile die in tmpadr->Grpname vorkommen kann. grpname ist c 3000 - kann es daran liegen ?

Rolf Ramacher Betreff des Beitrags: Re: Suchen / Filter ?? Verfasst: Do, 30. Jan 2014 19:58
=> cGrpSuch steht drin "test1", in tmpadr->Grpname - test1,xing,

[Tom]

Hallo, Hubert.

Ich hatte ja schon "Schulljung" geschrieben.

In seinem ersten Posting schreibt Rolf allerdings das hier:

bei der Kundensuche können gruppen in ein sle-Feld eingegeben werden mit komma getrennt. danach sollen dann nur die Kunden angezeigt werden,
bei denen die Gruppen oder einige Gruppen eingetragen sind.

Wenn ich das richtig verstehe, wobei ich, wenn Rolf etwas erklärt, nie ganz sicher bin, gibt es einerseits im SLE (Suchfeld) die Möglichkeit, Gruppen kommagetrennt für die Suche einzugeben, und zusätzlich die Möglichkeit, dass solche Gruppennamen im fraglichen Tabellenfeld ebenfalls auf diese Weise erfasst sind. Es ist also möglich, dass als Suchbegriff "Gruppe 1, Gruppe 2" vorkommt, und dass bei Kunden beispielsweise "Gruppe 1, Gruppe 3" eingetragen ist. In diesem Szenario würden alle hier geschilderten Lösungsansätze teilweise scheitern.

Statt der Möglichkeit, im Suchfeld (Rolfs "SLE") irgendwas einzutippen, müsste es also eine Combobox oder ein Browse geben, in dem man einen oder mehrere Einträge auswählen kann, so dass die Suchfunktion beispielsweise ein Array bekommt ({'Gruppe 1','Gruppe 2'}). Erst dann hätte ein Lösungsansatz für die hier geschilderte Problematik überhaupt einen Sinn.
Ergänzung: Oder man frickelt in der Suchfunktion die Eingabe auseinander, wobei man sich aber darauf verlassen muss, dass der Anwender wirklich kommasepariert eingegeben hat. In beiden Fällen müsse man aber eine gesonderte Vergleichsfunktion schreiben.

[Wolfgang Ciriack]

Also ohne dass ich jetzt alles haargenau gelesen habe, würde ich denken,
es liegt an dem lower(). Sind denn im Feld alle Gruppen in Kleinbuchstaben ?
Sonst sollte man evtl. auch lower(..) suchen.

[brandelh]

Hallo Wolfgang,

Rolf hat oben seinen code mit lower() ausgestattet, wobei ich und JAN darauf hingewiesen haben, dass man das in der Schleife nur für das sich änderne Feld und nicht für den fixen Vergleichstest machen sollte (diesen einmalig vorab umwandeln).
Dabei kamen wir auf die Beispiele von TOM, die tatsächlich ohne lower() sind, aber die Schreibweise der Wort bleibt gleich und daher funktioniert es beim ersten aber nicht bei den anderen ...

Wenn man mehrere Suchbegriffe in ein SLE eingeben kann, dann muss man vor der Schleife zunächst die einzelnen Suchbegriffe trennen und eine kombinierte Abfrage ( .and. / .or. ? ) erstellen.
Beispiel:

Gesucht werden alle Zeilen mit einem der Gruppen:

cSuch := "Gruppe1, Gruppe2" => in Array aufspalten (aSuch[1] := "gruppe1" , aSuch[2] := "gruppe2") und gleich lower(alltrim()) anwenden.
Das kann man z.B. mit den TOKEN Funktionen von Pablo erledigen.

Dann HIER .OR. verknüpfen, da eine der Gruppen reichen soll ... viele Treffer

Code: Alles auswählen

cBedingung := "{ || aSuch[1] $ "+cAlias+"->feldname "
for x := 2 to len(aSuch)
    cBedingung += ".OR. aSuch[x] $ "+cAlias+"->feldname "
next
cBedingung += " }"
bSuche := &(cBedingung)

ODER wenn man nur die haben will die alle enthalten .AND. !

[Tom]

Oder, etwas eleganter, so:

Code: Alles auswählen

FUNCTION Main()
LOCAL aDbStruct := {{'GRPNAME','C',20,0}}, nZaehler := 0, cVergleich := 'Meier, Müller'
LOCAL aVergleich := {}

SET EXCLUSIVE ON

IF "," $ cVergleich
  DO WHILE "," $ cVergleich
    aAdd(aVergleich,GetTextFromCommaText(@cVergleich))
  ENDDO
  ELSE
ENDIF
aAdd(aVergleich,AllTrim(Lower(cVergleich)))

? aVergleich


DbCreate('test.dbf',aDbStruct)
USE test NEW ALIAS MyAlias
APPEND BLANK
REPLACE grpname with 'Meier, Meinard'
APPEND BLANK
REPLACE grpname with 'Otto, Müller'
APPEND BLANK
REPLACE grpname with 'Meinard, Otto, Schulz'

MyAlias->(DbSetFilter({||RolfSuche(MyAlias->grpname,aVergleich)}))

MyAlias->(DbGoTop())

DO WHILE !MyAlias->(Eof())
  nZaehler ++
  MyAlias->(DbSkip(+1))
ENDDO

MsgBox(AllTrim(Str(nZaehler))+' Datensätze gefunden')

CLOSE DATA

RETURN NIL

FUNCTION RolfSuche(cFeldInhalt,aVergleich)
LOCAL aSuchFelder := {}, i, n
IF "," $ cFeldInhalt
  DO WHILE "," $ cFeldInhalt
    aAdd(aSuchFelder,GetTextFromCommaText(@cFeldInhalt))
  ENDDO
ENDIF
aAdd(aSuchFelder,AllTrim(Lower(cFeldInhalt)))
n:=Len(aSuchFelder)
FOR i := 1 TO n
  IF Lower(Trim(aSuchFelder[i])) $ aVergleich
    RETURN .T.
  ENDIF
NEXT
RETURN .F.

FUNCTION GetTextFromCommaText(c)
LOCAL cRetText := Lower(AllTrim(Left(c,At(",",c)-1)))
c := SubStr(c,At(",",c)+1)
RETURN cRetText

Das findet, so lange wirklich Kommas in Suchbegriff und Feld verwendet werden, alle einzelnen Suchbegriffe in allen Feldern, in denen sie mindestens einmal vorkommen.

[Tom]

Da sind noch ein, zwei AllTrim(Lower())s zu viel drin, aber es antwortet auch bei 100.000 Datensätzen (lokal, aktuelles 64-Bit-System, HDD) innerhalb von 1,4 Sekunden.
Korrektur. 0,4 Sekunden.

[brandelh]

aber ohne gleichzeitigen Index oder ?

[AUGE_OHR]

Frage an Rolf : sind die Begriffe mit .AND. verknüpft ?

wenn ja schon mal mit OrdWildSeek() probiert ?

Code: Alles auswählen

OrdWildSeek("*filter*optimize*")

[brandelh]

Soweit ich mich erinnere durchsucht OrdWildSeek() den Textindex, wenn also keiner da ist geht es nicht.

[AUGE_OHR]

Soweit ich mich erinnere durchsucht OrdWildSeek() den Textindex, wenn also keiner da ist geht es nicht.

YUP ... aber man könnte ja einen anlegen der über "alle" Felder geht in denen man was suchen möchte.
zu beachten ist jedoch die IndexKey() Länge : 120 / 240

[brandelh]

in meiner Testumgebung existieren nur 2 Datensätze - der DbSetfilter ist das Problem was nicht funkt. er findet keinen Datensatz, aber ich weiß nicht warum dbsetfilter nicht greift.

versuche mal

Code: Alles auswählen

SET OPTIMIZE OFF

das hat der Support auch empfohlen, die "OPTIMIERUNG" der CODEBLÖCKE führt zu falschen Ergebnissen.

Eigentlich müsste sich nämlich SetFilter() genauso verhalten wie wir es beschrieben haben, der vorangestellte ALIAS müsste als DEFAULT Wert gelten.
und so ist es, alles wird ordnungsgemäß dargestellt.

Code: Alles auswählen

WorkSpaceList() {MYALIAS, MY2ALIAS}

Aktiver Alias MY2ALIAS select:          2
MyAlias ... auch im CodeBlock
Treffer:           2

Aktiver Alias MY2ALIAS select:          2
MyAlias ... NICHT im CodeBlock
Treffer:           2

Nun Selectbereich verbessern auf 'MyAlias'

Aktiver Alias MYALIAS select:          1
MyAlias ... NICHT im CodeBlock
Treffer:           2

GANZ ohne Alias ...
Aktiver Alias MYALIAS select:          1
Treffer:           2

PS: an der fehlerhaften Filterbedingung ändert das natürlich nichts.
Für die Bestimmung der Trefferanzahl wäre COUNT TO schneller und sinnvoller oder dbEval().

[Rolf Ramacher]

so nachdem nun dbsetfilter hierbei nicht zum gewünschten Erfolg zu führen scheint. habe ich es etwas umgebaut und suche mit AT - auch alles soweit OK

Code: Alles auswählen

Function KdGruppe(cGrp)
	Local cGrpSuch:=alltrim(lower(cGrp)), aSatz:={}

	If empty(cGrp)
		Return Nil
	Endif

	TmpAdr->(Dbgotop())
	Do while TmpAdr->(!eof())
		If At(cGrp,TmpAdr->Grpname) >0
			AAdd(aSatz,tmpadr->(Recno()) )
		Endif
		TmpAdr->(DbSkip(+1))
	Enddo

msgbox(var2lchar(aSatz))

Nur hat jemand eine Idee wie ich dieses dann nach der Satznr. sortiere und im xbpbrowse korrekt anzeigen kann ??

[Tom]

[Bertram Hansen]

Aller liebster Rolf,

wie wäre es denn, wenn Du uns nachher in Leverkusen dein Problem mal vorführst. Friedhelm freut sich bestimmt.

[Jan]

Tom,

wie gut ich Dich doch verstehen kann...

Jan

[Jan]

Was ist denn jetzt gestern auf dem XUG-Treffen als Lösung gefunden worden?

Jan

[Tom]

Äh, Rolf.

In Deinem neuen Code suchst und findest Du nunmehr nur noch eine einzelne "cGruppeSonstwas" - oder zufällig die gleiche Reihenfolge. Suchst Du also nach "Gruppe 1, Gruppe 2" und der Kunde hat "Gruppe 1, Gruppe 2, Gruppe 3", dann findest Du diesen. Hat er aber "Gruppe 1, Gruppe 3, Gruppe 2", findest Du ihn nicht. Und Du findest ihn auch nicht, wenn er nur "Gruppe 1" hat. Das ist allerfeinstes Garbage-Programming. Hast Du eigentlich irgendeine der vielen Nachrichten gelesen, die andere hier gepostet haben, um Dir zu helfen?

Nur hat jemand eine Idee wie ich dieses dann nach der Satznr. sortiere und im xbpbrowse korrekt anzeigen kann ??

Eine Tabelle ist nach Satznummer sortiert, wenn sie keinen führenden Index hat. "SET ORDER TO 0" (<- Null) vor dem Refresh/Aufbau des Browses sollte das bewirken. Was, mit Verlaub, in Deinem Kletipleticode sonst noch passiert, weiß ich allerdings nicht und will es, um ehrlich zu sein, eigentlich auch nicht wissen. Und warum man überhaupt all das tun sollte, was Du da zu tun versuchst. Also beispielsweise eine Tabelle nach Satznummern anzeigen, was dem Kunden nicht viel sagen/helfen/bringen dürfte. Falls wir überhaupt über dasselbe sprechen.

Mich wiederholend:

[Tom]

in meiner Testumgebung existieren nur 2 Datensätze

Ganz großes Tennis.

[Jan]

Hallo Tom,

so sehr ich Deinen Aussagen vorher bezüglich "endlich mal lesen und machen, was da steht", auch voll und ganz zustimme: Zumindest DAS ist für mich irgendwie nachvollziehbar. Wenn irgendeine Funktion nicht läuft wie sie sollte, dann schafft man sich manchmal eine Testumgebung, die so einfach wie möglich ist. Man muß sich dann natürlich Schritt für Schritt an die Real Life-Bedingung rantasten um zu sehen, wo der Fehler liegt. Daß das letztendlich nicht der wahre Jakob ist, ist klar. Aber manchmal ist das der einzige Weg.

Jan

[Tom]

Hallo, Jan.

Wenn irgendeine Funktion nicht läuft wie sie sollte, dann schafft man sich manchmal eine Testumgebung, die so einfach wie möglich ist.

Fraglos. Man schafft aber auch eine Testumgebung, die möglichst alle Fälle, die in der späteren Realumgebung auftreten können, abbildet. Mit zwei Datensätzen ist das im hier von Rolf geschilderten Szenario schlicht unmöglich. Er aber frickelt so lange herum, bis seine beiden Datensätze irgendwie gefunden werden, aber das heißt längst noch nicht, dass die Funktionen auch richtig arbeiten. Wie seine neue "Lösung" ja zeigt - vorausgesetzt, ich habe nach einigem Hin und Her verstanden, was er eigentlich zu erreichen versucht. Wenn das der Fall ist, ist sein jüngster Code (der auch noch Fehler enthält - so wird zwar auf den Suchbegriff ein "Lower" gesetzt, aber auf die Feldinhalte nicht), schlicht und ergreifend falsch - und enthält, davon abgesehen, keinen Fortschritt. Er kann jetzt zwar mit der falschen Abfrage ein paar Datensätze im Array sammeln, weiß aber mit diesem Array nichts anzufangen.

Rolf. Schau Dir mal den letzten ausführlichen Code an, den ich hier gepostet habe (mit der Funktion "RolfSuche"). Der macht exakt das, was Du machen willst. Und er macht es richtig.

[Jan]

Er aber frickelt so lange herum, bis seine beiden Datensätze irgendwie gefunden werden, aber das heißt längst noch nicht, dass die Funktionen auch richtig arbeiten.

OK, da stimme ich Dir absolut zu. Man muß nicht eine Lösung finden, die nur in dem minimalistischen Testumfeld funktioniert, sondern generell. Aber gerade deswegen schrieb ich ja, das man sich von einer funktionierenden Lösung aus der minimalen Testumgebung langsam hochabreiten muß, bis man im Real Life angekommen ist. Auf dem Weg kann man dann erkennen, ob man nur eine "funktioniert irgendwie mit der Testumgebung, ich weiß aber nicht wirklich warum" gebaut hat, oder eine korrekte.

Aber es ist müßig, das hier zu diskutieren. Solange Rolf hier Fragen stellt, sich dann aber nicht wieder anmeldet (das letzte mal gestern früh), wird er die Vorschläge nicht lesen können. Und leider ist es ja auch so, das er es zwar vermutlich irgendwie (quer)liest, aber nicht umsetzt. Da können wir uns hier den Mund fuselig reden, es wird für Rolf nie eine lauffähige Lösung geben können. Wenn man fragt muß man halt auch mal zuhören.

Jan