Filtern von Daten

[Manfred]

Moin,

ich habe eine DBF, die mehrere Indexfelder hat. Zusätzlich zu den Indexfeldern gibt es noch eine Spalte, in der eine Nummer steht, nach der später auch gefiltert werden muß. Innerhalb jedes Index muß aber gesucht werden können. Kann man da etwas mit Scope machen? Set Filter dürfte wohl bei einigen 1000 Sätzen im Netzwerk etwas langsam werden. Aber wie Scoped man, wenn das Scopefeld erst an 2. Stelle steht? Theoretisch würde ich ja Index + Nummer setzen für den Schlüssel, aber wie geht man dann damit um?
Hat jemand eine Idee, die mir im Moment nicht kommt?

[Rolf Ramacher]

Hi Manfred,

d.h. du müßtest filtern, da immer die gleiche Nummer gebraucht wird. ? Ist das richtig ? -folgender vorschlag mache einen index drauf suche und mache ein do while. bis nicht mehr identisch und eof() - wenn du die Datenbank gleichzeitig mit einem anderen do while durchläufst mußt du dir diesen Satzzeiger natürlich in eine Variable sichern.

[AUGE_OHR]

ich habe eine DBF, die mehrere Indexfelder hat. Zusätzlich zu den Indexfeldern gibt es noch eine Spalte, in der eine Nummer steht, nach der später auch gefiltert werden muß.

grundsätzlich könnte man den Scope ja auch über mehrere Felder ziehen so wie auch den Index.

Innerhalb jedes Index muß aber gesucht werden können. Kann man da etwas mit Scope machen? Set Filter dürfte wohl bei einigen 1000 Sätzen im Netzwerk etwas langsam werden. Aber wie Scoped man, wenn das Scopefeld erst an 2. Stelle steht? Theoretisch würde ich ja Index + Nummer setzen für den Schlüssel, aber wie geht man dann damit um?

hm ... wenn ich dich jetzt richtig verstehe ist die zusätzliche Spalte mit Nummern "nicht" im Index enthalten ... warum ... ?

wenn das nun bei dir alle nicht geht würde ich die "Einschränkung" mittels Codeblock realisieren.
(siehe auch http://www.xbaseforum.de/viewtopic.php?f=31&t=5727 )
die Frage dabei ist "wie" Du es einsetzten willst : Browser "live" -> Skipblock oder beim "sammeln" innerhalb der Scope Schleife ?

[Tom]

Immer ein bisschen schade, auf einem Hauptschlüssel keinen Index zu haben.

Ansonsten: Scopes und Filter kann man nach Belieben kombinieren. Filter sind deutlich schneller, wenn die Datenbank bereits einen Scope besitzt. Aber die Indexe müssen natürlich geeignet sein.

[Manfred]

Nene,

ich versuche es nochmal richtig. Ich meinte oben mit Index + nummer -> Schlüssel plus Feld, das gefiltert werden soll. Es ist ein Browse, in dem die Möglichkeit besteht zu suchen über den Index. Leider kennt diese Such-Funktion aber nicht wirklich was da gefordert wird, sondern kann nur einfach pauschal im Index suchen. Der Index wird auch erst im Browser umgeschaltet. Auch da also keine großen Möglichkeiten noch etwas zu tun. Also wäre es sicherlich interessant, wenn man vorher schon den Scope auf die Nummer setzen kann.

[UliTs]

Hallo Manfred,

ich bin mir nicht ganz sicher, was Du meinst.
Geht es um folgendes?
Du hast beispielsweise folgenden kontrollierenden Index:

Code: Alles auswählen

str(Nummer,10)+Name

Du möchtest einen Scope auf einen Nummernbereich setzen, z.B. 1000<=Nummer<10000:

Code: Alles auswählen

DbSetScope( SCOPE_BOTTOM/*<nScope>*/,str( 1000   ,10 )         /*<xValue>*/ )
DbSetScope( SCOPE_TOP   /*<nScope>*/,str( 10000-1,10 )+chr(255)/*<xValue>*/ )

Ich meine, dies funktioniert auch, wenn der kontrollierende Index nach Setzen des Scope wechselt.

Uli

[Manfred]

Hm,

ich weiß jetzt nicht, ob ich euch verstehe, aber ich male es mal auf

Nummer1 beinhaltet einen Wert, auf dem gesucht werden soll. Nummer2 beinhaltet den Wert, der "gefiltert" werden soll.

Code: Alles auswählen

Wenn ich jetzt Str(nummer1,nLaenge,0) + Str(nummer2,nLaenge,0) als Schlüssel eingebe, oder:

Str(nummer2,nLaenge,0) + Str(nummer1,nLaenge,0) also Schlüssel eingebe, 

bin ich ganz ehrlich wüßte ich jetzt auf dem Papier nicht, was das richtige wäre.

[georg]

Hallo, Manfred -


in der Dokumentation zu SET SCOPE finde ich (ach ja, ich verwende die englische Dokumentation):

Scope: current work area, current order
...
A scope can be set for each order, be it a physical or logical order. A table may have its own scope using a record number as the scope value. The scope remains active until it is cleared using SET SCOPE TO (with no value) or the relating index or table is closed.

Wenn Du also INDEX ON Str(Feld1, 10) + Str(Feld2, 10) TO ... hast, und dieser Index aktiv ist, kannst Du den Scope nur auf Feld1 beziehen, Du willst aber auf Feld2 eingrenzen. Das geht nicht, da die Dokumentation besagt, dass der Scope auf die jeweils gesetzte ORDER bezogen ist, d.h. wenn Du zwei Index Tags verwendest, und bei der ersten einen SET SCOPE durchführst, greift dieser. Wechselst Du zum anderen Index Tag, kannst Du jetzt die Tabelle ohne Einschränkung lesen, da bei dieser ORDER kein Scope gesetzt ist.

Alternativ (wenn es nur um einen Wert von Feld2 geht) könntest Du einen zusätzlichen Index dieser Art verwenden:

INDEX ON Str(Feld2, 10) + Str(Feld1, 10) + Str(Feld2, 10)

Damit wäre die Bedingung erfüllt, dass der Scope-Wert "vorne" im Index-Begriff steht. Brauchst Du mehrere Werte von Feld2, geht das natürlich nicht.

Zweite Alternative: einen temporären Index mit einem WHERE Bedingung.

Oder SQL.


Gruss,

Georg

[Manfred]

Hi Georg,

das ist ja mein Problem. Deshalb hatte ich ja gefragt, ob es da evtl. eine andere Lösung gibt. Ich hatte auch schon mit Set Filter spekuliert, da bin ich aber noch nicht so weit, dass ich getestet habe, wie es dann mit dem Tempo aussehen wird. Nur bevor ich jetzt irgendeinen Weg einschlage wollte ich halt mal die Ideenküche vom Forum anzapfen. Es gibt ja immer wieder die tollsten Gedankengänge hier.

[UliTs]

Brauchst Du mehrere Werte von Feld2, geht das natürlich nicht.

Doch, man kann mit einem Bereich den Scope verwenden (s.o.) . Man muß nur darauf achten, dass alle benötigten Werte innerhalb des Scopes lieben.

Uli

[brandelh]

Dieser Thread ist das beste Beispiel, warum wir endlich von den NTX und CDX Beschränkungen weg und hin zur SQL Auswertung kommen müssen.

Arctica wir warten ...

Auf meinem Samsung Galaxy S plus habe ich eine SQLite Datenbank, egal ob dort 1000 oder 10000 Datensätze sind, bringt mir die Anfrage
"Select * where ... order by ..." ohne merkliche Laufzeit das Ergebnis, das du bräuchtest

ich denke bei den meinsten DBF Dateien kämen wir ohne Index aus ...

[UliTs]

Hi Georg,
das ist ja mein Problem

Ohne geeigneten Index kein Scope!
Ohne kontrollierenden Index funktioniert der Scope übrigens über die Record-Nummern.

----
Hubert: da brauchst Du aber nicht auf Arctica zu warten!
----
Uli

[Manfred]

Ah,

Moment..

Ich muß das Suchfeld (nummer1)am Anfang haben, damit ich drin suchen kann. Dann müßte also das "Filterfeld" (nummer2) dahinter kommen.

Also Index on Str(nummer1,5,0) + Str(nummer2,2,0) to index

Dann kann ich über nummer1 suchen. Kann man denn vorher über nummer2, was ja auch im Index ist einen Scope setzen?

[Tom]

Hallo, Manfred.

Ein konkatinierter (zusammengesetzter) Indexausdruck ist nichts weiter als eine Zeichenkette, die als Suchbegriff genutzt werden kann - beim Suchen ist dann unerheblich, wie sich der Index aufgebaut hat. Bei Scopes auf Zeichenketten mit einem Teilsuchbegriff werden alle Datensätze gefunden, die mit diesem beginnen. Wenn ich einen Index Str(kundennr,10,0)+Upper(name) habe, kann ich einen Scope "BOTH" nur auf die Kundennummer setzen und finde alle Einträge: DbSetScope(SCOPE_BOTH,Str(nSuchNummer,10,0)). Das gilt auch für die Ergänzung des Suchbegriffs: Index auf Str(kundennr,10,0)+Str(artikelnr,10,0) zum Beispiel in einer Datei mit Rechnungspositionen schränkt die Suchergebnisse immer weiter ein, je länger der Suchbegriff wird - Achtung übrigens bei umgewandelten numerischen Werten, bei denen es sich empfiehlt, mit Nullen zu füllen, auch im Suchbegriff! Scopes sind leichter zu verstehen, wenn man sie sich als DO-WHILES vorstellte: So lange der Indexausdruck (Länge entsprechend Suchbegriff) mit dem Suchbegriff übereinstimmt, gilt ein Datensatz als zugehörig (DO WHILE Left(IndexInhalt,Len(SuchBegriff)) == cSuchBegriff). Anders ist das bei Datumsausdrücken und bei numerischen Werten - die müssen exakt übereinstimmen, damit überhaupt etwas gefunden wird. Ein Scope auf "kundennr" (numerisch) findet mit der Suche nach "1" nichts, wenn es keinen Kunden mit genau der Nummer "1" gibt, sehr wohl aber welche, deren Nummern hiermit beginnen. Ein Scope auf Datumsfelder verhält sich entsprechend.
Schwierig bis unmöglich wird das verständlicherweise, wenn man von beiden Teilbegriffen immer nur einen Teil kennt. Will ich also alle Kunden scopen, deren Nummern mit "1" beginnen und zugleich auf die Artikel einschränken, für die das ebenfalls gilt, müsste ich im vorliegenden Beispiel auf "1" scopen und dann zusätzlich nach Artikelnummer filtern. Mir fehlten ja jetzt 9 Stellen der Kundennummer. Also DbSetScope(SCOPE_BOTH,"1") und ein anschließendes SET FILTER TO Left(artikelnr,1) = "1" (bzw. DbSetFilter).

[Tom]

ohne merkliche Laufzeit

Bei einer Tabelle, die sich auf einem Flashspeicher befindet oder/und sogar für die Suche komplett in den Hauptspeicher geladen wird. Und einem Betriebssystem, das Multitasking nur vortäuscht.

[UliTs]

Also Index on Str(nummer1,5,0) + Str(nummer2,2,0) to index
Dann kann ich über nummer1 suchen. Kann man denn vorher über nummer2, was ja auch im Index ist einen Scope setzen?

Manfred, Du kannst ja meines Erachtens mit 2 Indizes arbeiten: einen benutzt du für die schnelle Suche nach nummer1, den anderen für den Scope über nummer2.
Spricht etwas dagegen, einen 2. Index anzulegen?

Uli

Tom: Top-Antwort!

[brandelh]

Hubert: da brauchst Du aber nicht auf Arctica zu warten!

ich habe auch SQLExpress, aber über den ODBC Treiber möchte ich damit nicht in DBFs arbeiten
und richtige "SQL-Server" sind für meine Datenmengen nicht nötig.
Mit MySQL habe ich schon experimentiert, mehr nicht.

Arctica würde SQL Befehle direkt auf vorhandene DBFs ermöglichen, die bisher umständlich ausgewertet wurden.

[Manfred]

Hi Uli,

ich denke über den Index entscheide ich, da wäre sicherlich was zu machen.

Aber wie schon erwähnt, der browse und die Suchfunktion sind pauschal und schon vorhanden, da würde ich dann ungerne etwas ändern müssen. Wobei mir aber jetzt schon wieder eine Erweiterung dazu im Kopf herumschwirrt.

[georg]

Hallo, Manfred -


langsam verdiene ich mir einen Orden dafür, dass ich beim Thema bleibe ...

Versuche es doch testweise mal mit einem Filter und schau Dir die Performance an. Auf einem Atom-Dual-Core PC (2 * 1,6 GHz) mit 8 GB RAM, Windows 7, schneller WD-Festplatte greift ein SET FILTER auf eine DBF mit ca. 50.000 Sätzen rasant schnell (nicht von aussen messbar), selbst dann, wenn nur wenige (oder gar kein Satz, kommt in der Konstellation schon mal vor) Treffer anzuzeigen sind.

Versuch macht klug.


Gruss,

Georg

P.S.: SQL-Befehle auf eine DBF-Datei sind nicht schneller als ein SET FILTER, wenn die DBE nicht angepasst wird. Nur die Syntax alleine macht es nicht ... (Auweia, jetzt habe ich doch das Thema gewechselt)

[Tom]

Kann mich Georg nur anschließend. Viele von uns haben möglicherweise noch den "Filter im Kopf", aus Clipper-Zeiten, aber die Hardware hat sich verändert, und die verbliebenen Lücken schließen Techniken wie Caching. Filter werden bei jeder Datensatznavigation ausgewertet, was umgekehrt bedeutet, dass ihre Evaluierung vorläufig abgeschlossen ist, wenn der erste Datensatz gefunden wurde, und das kann sehr schnell gehen. Und übrigens gibt es da noch SET SMARTFILTER ON und SET RUSHMORE ON. Diese Techniken sollte man sich ruhig mal anschauen.

[Manfred]

Jaja,

ihr habt ja Recht. Set Filter benutze ich bisher nur im Zusammenhang mit Scope und da ist das echt toll. Ich hatte ja schon erwähnt, dass ich es probieren wollte. Vielleicht erledigt sich ja dann alles.

[Tom]

Eine Warnung vor allzu viel Euphorie ist allerdings angebracht. Etwa eine Volltext-Instring-Suche per Filter auf einer großen Tabelle, vielleicht sogar noch auf dem Inhalt eines Memofelds, kann durchaus recht langsam werden ("SET FILTER TO 'Manfred' $ memotext). Vor allem, wenn die Ergebnisse in einem Browser angezeigt werden, dessen Navi-Codeblöcke die anzuzeigenden Daten mindestens zweimal "durchwandern", wodurch der Filterausdruck recht häufig evaluiert wird.

[AUGE_OHR]

Ich muß das Suchfeld (nummer1)am Anfang haben, damit ich drin suchen kann. Dann müßte also das "Filterfeld" (nummer2) dahinter kommen.

Also Index on Str(nummer1,5,0) + Str(nummer2,2,0) to index

Dann kann ich über nummer1 suchen. Kann man denn vorher über nummer2, was ja auch im Index ist einen Scope setzen?

theoretisch ja

Code: Alles auswählen

      SET SCOPETOP    TO "0000000000"+Nummer2_Top
      SET SCOPEBOTTOM TO "9999999999"+Nummer2_Bottom

aber was würde dir das nützen wenn du von "allen" Kunden (->Nummer1) nun einen bestimmten Artikel ( ->Nummer2) angezeigt bekämst ?

ein "Filter" ist ja eine Art "Abfrage" und da würde ich immer erst mal alle Daten "sammeln" um sie dann in einem Array Browse ( oder ListView ) anzuzeigen.
hierfür eignet sich ausgezeichnet OrdWildSeek() zusammen mit Scope

Code: Alles auswählen

   Seek(cString)
   IF FOUND()
       SET SCOPE TO cString
       OrdWildSeek(*cString*cOther*) // mit 2nd. Bedingung
       DO WHILE FOUND()
         IF EVAL( bBlock)                   // hier evtl, 3th Bedingung
             AADD(aTreffer,DatenSatz)
         ENDIF
         OrdWildSeek()
      ENDDO
      SETSCOPE TO

      Do_Array_Browse(aTreffer)
   ENDDO

[Manfred]

Hi,

OrdWildSeek hat einen Nachteil: solange bis der erste Begriff gefunden wurde, geht gar nichts mehr. Man sieht nichts und man kann auch nicht abbrechen.

Es gibt auch nur 1 Artikel zu einem Kunden. Es gibt aber mehrere Kunden zu dem Artikel.

[AUGE_OHR]

OrdWildSeek hat einen Nachteil: solange bis der erste Begriff gefunden wurde, geht gar nichts mehr. Man sieht nichts und man kann auch nicht abbrechen.

kannst du das bei einem SEEK() ? die Geschwindigkeit ist die selbe !

Es gibt auch nur 1 Artikel zu einem Kunden. Es gibt aber mehrere Kunden zu dem Artikel.

dann muss du den Index "umstellen" mit den Artikel zuerst
Frage : wie viele Indexe hast du so im Schnitt ... man kann doch bis zu 255 TAG(s) haben