Filtern von rel. grossen Datenmengen [erledigt]

[Tom]

Möglich, dass die DBU da noch etwas zusätzliche Logik enthält. Rogers XDot macht das auch so. Aber im Code ist es, wie ich's erklärt habe. SET FILTER hat vorerst keine Auswirkung auf die Position des Datensatzzeigers.

[AUGE_OHR]

hi,

ich sagte in DBU und da gibt es einen DBSKIPPER.

wie schon gesagt prüfe ich per SEEK() vorher "ob" überhaupt ein Treffer für die Bedingung existiert.
nach dem setzten eines FILTER oder SCOPE "bewege" ich den Record Pointer.

es würde im Prinzip auch ein SKIP(0) reichen aber wenn ich per SEEK() was gefunden habe mache ich lieber ein GOTO.

p.s. SET OPTIMIZE OFF

[Tom]

Wie meinst Du das, dass Du mit DbSeek prüfst, ob es einen Treffer für die Bedingung gibt? Wozu brauchst Du einen Filter, wenn die Bedingung über einen Indexausdruck geprüft werden kann? Filter braucht man nur für unscharfe Anfragen (Instring-Suche, komplexe Abfragen o.ä.) und bei der Suche nach Ausdrücken, für die es keine Indexe gibt.

[Wolfgang_B]

Übrigens ...
habe jetzt das Ganze auf Index umgestellt ... ---> 10.000 Datensätze 3 Sek.

[AUGE_OHR]

hi,

Wie meinst Du das, dass Du mit DbSeek prüfst, ob es einen Treffer für die Bedingung gibt? Wozu brauchst Du einen Filter, wenn die Bedingung über einen Indexausdruck geprüft werden kann? Filter braucht man nur für unscharfe Anfragen (Instring-Suche, komplexe Abfragen o.ä.) und bei der Suche nach Ausdrücken, für die es keine Indexe gibt.

ich kann dir nicht folgen wieso SEEK() mit FILTER / SCOPE nicht passen sollten

Code: Alles auswählen

   cSeek := "B"
   SEEK(cSeek)
   IF FOUND()
      nRec := RECNO()
      SET SCOPE (cSeek) 
      GOTO(nRec)
   ELSE
      Msgbox("kein Artikel mit "+cSeek+ "gefunden !")
      RETURN .F.
   ENDIF

wenn ein SEEK nicht erfolgreich war wird ein FILTER / SCOPE auch keinen Erfolg bringen.

wenn aber Found() schadet es nicht sich die RECNO() zu merken denn, da sind wir uns ja einige, man muss den Record Pointer danach noch "bewegen".

---

bei einem FILTER prüft er IMHO jeden Datensatz auf die Bedingung das wie auch viele DELETE() alles langsam macht.
wenn ich mit einem GOTO() nicht am Anfang starten muss kann ich viel Zeit sparen.

bei einem SCOPE, über den Index, sind es nur die Datensätzen die durch den Index eingegrenzt werden.
deshalb ist ein GOTOP bei einem SCOPE schnell auch wenn man viele DELETE() hat.
ein GOTO() wäre in diesem Fall nicht schneller

---

wenn man die "Bedingung" in der "Mitte" hat mache ich das selbe mit OrdWildSeek(cSeek)

Code: Alles auswählen

      OrdWildSeek( cSeek )
      DO WHILE FOUND()
         IF EVAL( bBlock )
            IF "CLOSE" $ PDRS->CLOSESTATE
               AADD( aPDR, { PDRS->PDRNR, "C", PDRS->SYMPTOM, PDRS->( RECNO() ) } )
            ELSE
               AADD( aPDR, { PDRS->PDRNR, "O", PDRS->SYMPTOM, PDRS->( RECNO() ) } )
            ENDIF
         ENDIF
         OrdWildSeek()
      ENDDO

auch dort "lohnt" sich ein FILTER / SCOPE nur dann wenn man zumindest 1 Treffer hat.

sicherlich hab ihr bBlock gesehen.
wenn man "komplizierte" Sachen hat ist das die Stelle wo dann ein Codeblock reinkommt der nicht nur .T. zurück liefert