Inoffizielles deutsches Xbase-Forum

Hi,

dieses Thema wurde zwar immer wieder angesprochen, ich möchte das aber jetzt mal konzentriert auf einen Punkt bringen.

Was bringt/nutzt oder nicht mir diese Einstellung. Einzeln, oder in Kombination zueinander? Das habe ich immer noch nicht ganz verinnerlicht. Kann mir dazu jemand etwas sagen?

Hallo, Manfred.

Bei allen drei Technologien geht es um die Optimierung bei der Suche ohne Index(such)e, vor allem um Abfragen mit Filtern, LOCATE und ähnlichem. Rushmore soll z.B. Filter so optimieren, dass dennoch Indexausdrücke verwendet werden, "Optimize" holt irgendwie Indexe in den Arbeitsspeicher und sucht dort. Zu diesen beiden Kandidaten kenne ich nur die (offenbar immer noch gültige) Mitteilung "Bitte ausschalten, da problematisch". Es gibt sogar ältere PDRs (2002 u.ä.) in der Alaska-Knowledgebase, die nach wie vor offen sind und diese Hinweise enthalten.

Was tatsächlich und auch gut funktioniert, das ist "SET SMARTFILTER". Dabei merkt sich die DBE je Workarea, in der ein Filter aktiv ist, ob ein Datensatz bereits für die Filterbedingung evaluiert wurde. Wenn das der Fall ist, muss die Filterbedingung nicht mehr geprüft werden. Das verwende ich auch an den wenigen Stellen, an denen ich noch Filter auf größeren (!) Tabellen einsetze, und es funktioniert richtig gut - ein Browse, das eine solche Tabelle anzeigt, wird deutlich schneller, wenn einmal alle Datensätze "durchgelaufen" sind. Problematisch ist das, wenn die Tabelle von woanders aus so geändert wurde, dass Datensätze, die vorher in den Filter fielen, das jetzt plötzlich nicht mehr tun - und umgekehrt. Da nur noch geprüft wird, ob die Datensatznummer bereits in der Liste steht, blieben solche Datensätze im alten Status, bis man DbRefresh() auslöst, was diese Liste zurücksetzt, dann aber auch einmalig den Filter wieder auf seine Ursprungslangsamkeit zurückwirft.

Ich setze das allerdings, wie gesagt, sehr gezielt ein - und schalte es auch gleich wieder aus. Im Prinzip kann man das mit Bordmitteln auch selbst relativ leicht nachahmen, indem man einfach in einem Array die Datensätze speichert, die schon angefasst wurden, und dort auch die Information vorhält, ob sie dem Filter entsprechen oder nicht. Ich vermute, dass SMARTFILTER exakt so arbeitet.

Hi Tom,

Danke für die Erklärung. Das war es was ich wissen wollte. Also ist es besser es nicht zu nutzen. Ich frage deshalb, weil in meinem übernommenen Projekt möglich ist dies zu (de) aktivieren und ich habe keine Ahnung wozu das mein Vorgänger brauchte. Ist sowieso standardmäßig ausgeschaltet. Also klemme ich die Möglichkeit besser ab.

zu SMARTFILTER finde ich (nur) 3 Einträge als PDR mit Workaround

PDR 4575 :
Workaround : SET SMARTFILTER OFF

PDR 4644 :
Workaround : Either set SET SMARTFILTER OFF or re-set the FILTER by setting
SET FILTER TO again after having changed one of the embedded LOCALs

PDR 5115 :
Workaround : SET SMARTFILTER OFF, does resolve the problem as described above.
For more details check the Xbase++ documentation about SMARTFILTERung which
should explain why this is so

Jimmy, die sind alle drei geschlossen - seit mehr als 10 Jahren.

Tom hat geschrieben:Jimmy, die sind alle drei geschlossen - seit mehr als 10 Jahren.

hm ... auch wenn Alaska die auf "grün" gesetzt hat heisst es ja nicht das es behoben wurde weil es keinen Hotfix gibt.

vielmehr macht Alaska das immer dann wenn sie meinen das ein Workaround reichen würde : "abschalten"
da es sich aber "nur" um die 3 Fälle handelt kann man sich die ja merken und zusehen das man nicht so was programmiert.