AvD Posted May 1, 2004 Posted May 1, 2004 Hieronder samenvatting van thread http://www.clarify.net/viewtopic.php?p=9781#9781 waarin Rony Rabijns en Jean uitleggen wat te doen wanneer er te kiezen valt tussen stored en unstored. Integrale lectuur van deze thread is zeker aan te bevelen. Vermits de meeste ‘Status’ functies in een berekening kunnen gebruikt worden indien ze ‘unstored’ staan,, moet je eerst wat meer weten over de ‘index-werkwijze’ van FM..., omdat er veel situaties zijn waar het resultaat van een berekening afhangt of het veld al of niet ‘ge-indexed’ is... De index wordt gecontroleerd/gestuurd door door de ‘storage instelling’ (stored versus unstored). Wanneer de index ‘aan’ staat, wordt ieder unieke waarde in het veld opgeslagen. De index voor dat veld bewaart iedere afzonderlijke waarde voor dat veld doorheen het bestand. Zo verlopen oa zoekopdrachten sneller vanuit een indexlijst.... ‘Dubbele’ waarden worden maar 1 keer opgeslagen en enkel de eerst 20 karakters worden geindexeerd. Dit is meer gedaan om de ‘grootte’ van het bestand te beperken. Dus dien je nooit een veld te indexeren waarop nooit zal gezocht worden....of dat ‘nergens’ op een layout staat.... Natuurlijk voorziet de index meer dan ‘sneller opzoeken’. De index bewaart de resultaten van een berekening. Zonder index zouden berekeningsvelden enkel de ingave weergeven en niet het resultaat...Unstored berekeningen worden niet ge-indexeerd, ze worden herberekend bij iedere ‘screen refreshment’. En verder nog: Berekeningen die naar globalen refereren worden automatisch op unstored gezet omdat een globaal niet kan geindexeerd worden. is dat eigenlijk niet omdat er geen reden is om globalen te indexeren ¿? Dat kan wel voor problemen zorgen indien je globalen gebruikt in een berekening. Indien je een globaal wilt tonen in een list-view layout zal de schermopbouw vrij traag verlopen omdat ieder record herberekend wordt... Scrollen door een lijst wordt daardoor dan ook eerder een nachtmerrie... Te vermijden dus... Berekeningen die verwijzen naar een gerelateerd veld zijn ook unstored omdat het eigenlijke bestand geen toegang heeft tot de index van dat gerelateerd veld. De enige oplossing zou zijn alle indexen van alle bestanden in ieder bestand te bewaren.... Een mogelijkheid om dat te omzeilen is gebruik maken van een look-up ipv een relatie, maar die worden dan weer niet automatisch geupdate.... Een veel voorkomende fout (als je van fout kunt spreken...) waar 'beginners' in trappen is bij het gebruik van de Status Current Found Count in een berekening (afgaande op postings....) waarbij het resultaat altijd hetzelfde aantal records geeft... We kunnen samenvatten dat indexering in een bestand invloed heeft op : Globalen, niet indexeerbaar Berekeningen kunnen unstored gezet worden en daardoor niet indexeerbaar Relaties hebben een geindexeerd veld nodig, uitgezonderd globalen... List view gaat langzamer bij gebruik van niet geindexeerde velden Indexering versnelt het vinden/zoeken Indexering vergroot de omvang van een bestand Indexering wordt automatisch 'aan' gezet wanneer gezocht wordt, behalve wanneer geen gebruik gemaakt wordt van de optie auto turn on... Niet geindexeerde velden worden tijdelijk geindexeerd bij een zoekopdracht... Met dank aan Jean en aan Rony.
Recommended Posts