Suchen / Filter ??

[Jan]

Hast Du mal einen Breakpoint eingebaut, der bei den fraglichen Datensätzen stoppt? Damit Du Dir die Situation im Debugger ansehen kannst?

Jan

[Rolf Ramacher]

Hi Jan,

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.

[Jan]

Rolf,

daher nimm mal den Debugger. Geh Satz für Satz durch. In VX kannst Du auch commands abschicken, um z. B. Datenbankfunktionen abzuschicken oder Variablenbelegungen abzufragen. Ohne das wirst Du meiner Meinung nicht weiter kommen. Egal was Du machst - es ist immer nur ins Blaue geraten. Nur über den Debugger wirst Du wirklich das Problem finden können, erst recht in akzeptabler Zeit.

Jan

[Scarmo]

Hallo Rolf

Ich denke eher, dass bei Dir die Bedingung "cGrpSuch$lower(TmpAdr->grpname)" sein sollte... Oder kannst Du mal ein Beispiel machen, welche Werte in TmpAdr->grpname und in der Variablen "cGrpSuch" sind?

Gruss
Marco

[Rolf Ramacher]

Hallo Marco

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

[brandelh]

Hinweis nochmal cGrsuch ist eine Textzeile die in tmpadr->Grpname vorkommen kann. grpname ist c 3000 - kann es daran liegen ?

Dann Schau dir mal genau die Hilfe an !
Du verwechselst Daten mit Suchbegriff

// lies cGrpSuch ist enthalten in TmpAdr->grpname, also müsste es so heisen:

TmpAdr->(DbSetFilter( {|| cGrpSuch $ alltrim(lower(TmpAdr->grpname)) } ))

// einfacher:

OK: "b" $ "abc" => .t.
nicht so: "abc" $ "b" => .f.

[Jan]

Hatten wir diese Diskussion, was nach links und was nach rechts gehört, nicht schon viel weiter oben? Manchmal muß man auch mal die Antworten auf seine Frage auch mal durchlesen und beachten.

Jan

[AUGE_OHR]

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

[brandelh]

wenn die DBF nur 2 Sätze hat, würde ich keinen Filter nehmen

[Rolf Ramacher]

Hallo Hubert,+

das ist hier bei mir in meinem Test-System. Draussen beim Kunden sind es natürlich viel mehr.

[Tom]

Dieser Code findet exakt 2 Datensätze - so, wie es sein sollte. Ohne irgendwelche Einstellungen.

Code: Alles auswählen

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

SET EXCLUSIVE ON

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

DbCommitAll()

MyAlias->(DbSetFilter({||Trim(MyAlias->(grpname)) $ cVergleich}))
MyAlias->(DbGoTop())

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

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

CLOSE

RETURN NIL

Funktioniert mit und ohne Alias im Filter.

[Tom]

Und für die Besserwisser zum Ausprobieren - dieser Code findet 0 Datensätze, wenn der Alias im Filter NICHT verwendet wird:

Code: Alles auswählen

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

SET EXCLUSIVE ON

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

USE test2 NEW ALIAS My2Alias
APPEND BLANK
REPLACE grpname with 'Otto'

DbCommitAll()

? WorkSpaceList()

MyAlias->(DbSetFilter({||Trim(MyAlias->(grpname)) $ cVergleich})) // "MyAlias->(DbSetFilter({||Trim(grpname) $ cVergleich}))" findet 0 Datensätze
MyAlias->(DbGoTop())

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

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

CLOSE DATA

RETURN NIL

[brandelh]

Hallo Tom,

viele Grüße vom Besserwisser

Falls in einer Workarea eine Filterbedingung definiert ist, wird diese durch die Funktion DbFilter() ermittelt.
Wenn die Funktion ohne Aliasoperator verwendet wird, wird die Filterbedingung in der aktuellen Workarea zurückgegeben.

daraus folgt, dass der vorangestellte Alias auch in der Filterbedingung gelten muss ... LEIDER IST DA ABER EIN FEHLER IN XBASE++

Dein Code beweist, dass DBSetFilter() auch innerhalb des codeblocks einen Alias benötigt.
Wieder ein Grund warum ich keinen Filter nehme

Dieser Code ist schneller und sicherer. Er zeigt wie sich eine Funktion mit vorangestelltem Alias / Selectbereich zu verhalten hat:

Code: Alles auswählen

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

SET EXCLUSIVE ON

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

USE test2 NEW ALIAS My2Alias
APPEND BLANK
REPLACE grpname with 'Otto'

DbCommitAll()

? alias()
? select()
? WorkSpaceList()

MyAlias->(DbEval( {|| qout(select(),alias(),recno(),grpname ), nZaehler++ } ,;
                  {|| Trim(grpname) $ cVergleich} ))

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

CLOSE DATA

RETURN NIL

Ergebnis 2 Treffer:

Code: Alles auswählen

D:\TEMP\test>test
MY2ALIAS
         2
{MYALIAS, MY2ALIAS}
         1 MYALIAS               1 Meier
         1 MYALIAS               2 Müller
D:\TEMP\test>

[Tom]

Ohne Alias im Filter funktioniert es nicht einmal, wenn man die Tabelle explizit vorher selektiert.

@Hubert - Fehler oder nicht, Ergebnisse zählen. Nach meinem Verständnis ist es jedoch richtig, wenn ein Codeblock auch wissen muss, woher die Daten stammen sollen, die er auszuwerten hat. DbSetFilter mit vorangestelltem Alias nimmt keine explizite Selektion der Workarea vor, sondern etabliert für die Datensatznavigation eine Bedingung. Damit diese Bedingung unter allen Parametern zutrifft, muss sie wissen, was sie auszuwerten hat. Tatsächlich könnten in der Filterbedingung ja auch ganz andere Workareas oder Memvars referenziert werden.

Mich verblüfft nur die energische Behauptung einiger hier, sie hätten ihren Code "verbessert", indem sie solche Referenzen ausgebaut hätten. Vermutlich haben sie ihn verschlimmbessert.

[Jan]

Hallo Tom,

da ich der Einzige bin der behauptet, er habe Probleme gehabt wenn der Alias in der Filterbedingung steht: Das ist schon eine Weile her, das ich das Problem hatte. Die exakten Umstände sind daher nicht mehr so ganz präsent. Aber seitdem benutze ich in den sehr seltenen Fällen, in denen ich doch mal ein DbSetFilter() einbaue, die Filterbedingung grundsätzlich ohne Alias. Und es funktioniert. Lahmarschig zwar wie Filter nun mal sind, aber es geht.

Ich werde das noch mal gegentesten, ob ich meine Erfahrungen von irgendwann früher mal rekonstruieren kann.

Jan

[Manfred]

OK,

ich benutze grundsätzlich immer den Alias davor. Und es gab niemals Probleme. Wenn es welche gab, waren die in der Regel vor dem PC zu finden.

[brandelh]

@Hubert - Fehler oder nicht, Ergebnisse zählen. Nach meinem Verständnis ist es jedoch richtig, wenn ein Codeblock auch wissen muss, woher die Daten stammen sollen, die er auszuwerten hat.

natürlich muss er das wissen, aber wie die Beschreibung im Handbuch und das Verhalten von DBEVAL() zeigt, bestimmt der vorangestelle ALIAS genau den DEFAULT SELECT-Bereich.

Tatsache ist, dass sich DBSetFilter() sehr seltsam verhält und man damit leben muss.

[Jan]

So, ich habe das jetzt mal getestet. Und muß mein Aussage revidieren: Es funktioniert auch mit Alias. Aber ich muß auch Tom widersprechen: Es funktioniert auch ohne Alias. Beide male das exakt gleiche Ergebnis.

Jan

[Manfred]

Also ich verstehe das immer so: Wenn nichts davor steht, wird generell immer der aktive Bereich genommen. Wenn man vor dem Dbeval, oder sonstwas einen Alias jetzt, dann wird der genommen, der angegeben wird, wenn aber in der weiteren Bedingung nichts mehr steht, dann wird der Bereich genommen, der aktiv ist und das kann ein anderer sein. Es können ja auch Variablen sein, die gemeint sind. Weiterhin wird zuerst angenommen, dass Dateifelder gemeint sind. Und dann wird erst auf Variable gegriffen. So habe ich das immer verstanden und meine es auch so gesehen zu haben, bei einem Test.

Deshalb ist ja auch so wichtig (Übersicht usw) dass alles klar definiert wird. Das erleichtert alles ungemein. War ja auch schon oft genug ein Thema hier im Forum.

[Tom]

Zum Verständnis.

DbSetFilter() etabliert für das fragliche Workarea-Objekt eine Bindung, die ausgewertet wird, wenn Datensatznavigation stattfindet (das Setzen eines Filters löst keine Datensatznavigation aus). Die Memvars und Felder (was für Xbase++ grundsätzlich dasselbe ist) werden im Moment der Navigation ausgewertet - der Aliasoperator vor dem DbSetFilter hat hiermit aber nichts zu tun, denn er bestimmt lediglich, für welches Workarea-Objekt die Bedingung etabliert werden soll. Ob die Bedingung zutrifft, hängt von den Parametern ab, die im Moment ihrer Auswertung gelten. Arbeite ich ohnehin in der Workarea, selektiere sie also vorher, wenn ich navigiere, dürfte das in den meisten Fällen funktionieren. Habe ich aber Feldnamen ohne Alias verwendet und zufällig eine Tabelle mit gleichen Feldnamen selektiert (oder sogar zusätzlich eine Memvar dieses Namens), wird diese ausgewertet. Das ist kein Fehler, sondern richtig. Ich nehme an, dass bei Navigationsarbeiten simpel ein Eval() auf dem Filter-Codeblock stattfindet, und wenn das so ist, erklärt sich das vermeintliche Fehlverhalten dadurch, das eben keines ist: Genau so würde ich das auch erwarten.

ROLF - hast Du's mal mit Alias in der Filterbedingung ausprobiert?

[Tom]

Meine Ausführungen kann man sehr schön nachvollziehen, indem man im Beispielcode die Definition von "cVergleich" aus dem LOCALS-Statement entfernt und hinter den Filter setzt:

Code: Alles auswählen

MyAlias->(DbSetFilter({||Trim(MyAlias->(grpname)) $ cVergleich}))
cVergleich := 'Meier, Müller'
MyAlias->(DbGoTop())

Dieser Code funktioniert, denn es gibt die Variable "cVergleich" zwar noch nicht, während die Filterbedingung gesetzt wird, aber da ist sie auch irrelevant. Erst mit dem "DbGoTop()" wird die Bedingung erstmals geprüft. Setze ich sie dahinter, bekomme ich natürlich einen Laufzeitfehler.

[Rolf Ramacher]

so sieht der code jetzt aus

Code: Alles auswählen

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

	If empty(cGrp)
		TmpAdr->(DbClearFilter()) 
		Return Nil
	Endif
	TmpAdr->(DbSetFilter( {||  trim(TmpAdr->grpname) $ cGrpSuch}  ))
	TmpAdr->(Dbgotop())
	do while !Tmpadr->(eof())
		AAdd(aSatz,TmpAdr->(Recno()) )
		TmpAdr->(DbSkip(+1))
	Enddo
	TmpAdr->(Dbgotop())
msgbox(var2lchar(aSatz))

das Array ist leer

[Tom]

Nimm mal das hier in Deinen Code, vor dem Setzen des Filters. Deine Tabelle ist wahrscheinlich weg oder Du hast eine ganz andere als die erwartete im Alias:

Code: Alles auswählen

? TmpAdr
? TmpAdr->(DbInfo(DBO_FILENAME))
TmpAdr->(DbClearFilter())
TmpAdr->(DbGoTop())
DO WHILE !TmpAdr->(Eof())
  ? TmpAdr->grpname
  TmpAdr->(DbSkip())
ENDDO

Wahrscheinlich bekommst Du überhaupt nichts - oder Daten aus einer ganz anderen Tabelle.

[brandelh]

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

sorry, aber hier gibt ROLF an, dass in tmpadr->Grpname - test1,xing und in cGrpSuch "test1" steht, die Reihenfolge bei der $ Abfrage ist vertauscht

Kurzer String $ Langer String

Langer String = Kurzer Teil String

[Tom]

Hallo, Hubert.

Dieser Code ist schneller und sicherer.

Das mag sein, wenn man wissen will, wie viele Treffer es gibt (obwohl ich eigentlich beidem widersprechen wollen würde - vielleicht ist es ein bisschen schneller, aber warum es "sicherer" sein sollte, dafür bleibst Du die Erklärung schuldig). Willst Du jedoch die Datensatzmenge ermitteln/zurückerhalten, ist dieser Code sinnlos. Genau darum geht es Rolf aber.

Ich würde auch keinen Instring-Filter auf eine Tabelle setzen, die im Netz hängt und > 100.000 Datensätze enthält. Auf Tabellen mit weniger als tausend Datensätzen kann man Filter aber durchaus so verwenden, da die GUI meistens sowieso langsamer als die Massenspeicherhardware ist.

Der Ansatz ist bei einer so großen Datenmenge nur dann praktikabel (also für den Kunden verwendbar), wenn die zu untersuchende Datenmenge auf andere Art begrenzt wird. Um hierbei zu helfen, müsste man aber mehr über die Daten, Indexe und sonstigen Bedingungen wissen.