Stored of unstored ? Wat te doen?

[AvD]

Deze thread volgt op een vraag i.v.m. containers (http://www.clarify.net/viewtopic.php?t=1525).

 

Goh Rony, waarom zou je de berekening unstored willen houden? Deze calculatie kan toch gewoon gestoord worden?

Ik denk dat dit voor menig gebruiker een pertinente vraag kan zijn en dat het nuttig zou zijn dit even toe te lichten: wat is het verschil tussen stored en unstored, en welke zijn de criteria die aan de basis liggen van de beslissing?

Niet vergeten dat deze optie iets of wat verborgen ligt, en dat heel veel gebruikers met de default settings werken zonder het te weten.

Edited May 2, 2004 by Guest

[JeanWM]

Hmm, interessante vraag André.

Dat is ook hoe ik mijn ‘conversaties’ over een item begin.....

(voor de duidelijkheid....ik ga hier tot versie 5v3 van FM....meer dan waarschijnlijk dat anderen de verschillen kunnen aangeven in hogere versies...).

 

Heel snel en zeker niet volledig....enkel om deze draad te starten....

 

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’.

[Rony Rabijns]

Calculatieveld maken (unstored, number)

 

Goh Rony, waarom zou je de berekening unstored willen houden? Deze calculatie kan toch gewoon gestoord worden?

 

Het is dag van de arbeid vandaag ...

 

@ Sanne :

klopt, de berekening mag stored zijn. in dit geval is er geen verschil tussen stored en unstored, behalve dat het zoeken langer (zou kunnen duren) duurt in geval van een "unstored" berekening.

 

Goh Rony, waarom zou je de berekening unstored willen houden? Deze calculatie kan toch gewoon gestoord worden?

Ik denk dat dit voor menig gebruiker een pertinente vraag kan zijn en dat het nuttig zou zijn dit even toe te lichten: wat is het verschil tussen stored en unstored, en welke zijn de criteria die aan de basis liggen van de beslissing?

 

Aan het verhelderende verhaal van Jean heb ik niets meer toe te voegen.

Behalve misschien dit : als er globalen of gerelateerde gegevens in je berekening zitten, kan je niet "storen".

[Sanne]

Het is dag van de arbeid vandaag ...

 

Als loonslaaf heb ik elke werkdag dag van de arbeid

[Rony Rabijns]

als "toevoeging" aan Jean's verhaal :

 

(ref. FM 7 Help)

 

Defining field indexing options

 

In FileMaker Pro, you can create indexes, which are lists of the words or values in a field. FileMaker Pro uses indexes for searching and for joining related tables. Indexes increase the speed of searches but also increase file size.

 

FileMaker Pro uses different indexes for different tasks:

 

Value indexes can be created for text, number, date, time, and timestamp fields, as well as calculation fields that return results of these same types. Value indexes are used for joining related records and for searches in number, date, time, and timestamp fields, and calculation fields that return results of these same types. A value index is created by taking each line of text (delimited by the carriage return character) and taking up to the first 100 primary character weights that all the characters in that line generate, according to the Unicode Collation Algorithm. For more information, see Choosing a language for indexing or sorting.

 

Word indexes can only be created for text fields, where they are used for searches. A word index is created by storing each unique word in a field. Fields containing large amounts of text can generate large indexes, as each unique word in the text field appears in the word index. This can significantly increase file size.

 

Notes

 

You can define storage and indexing options for text, number, date, time, and timestamp fields. You can also index calculation fields if the results are text, number, date, time, or timestamp.

 

FileMaker Pro stores most calculation field values immediately after the field is defined, when the Define Database dialog box is closed. By default, calculations that include a related field, summary field, global field, or a reference to another unstored calculation are unstored; all other calculations are stored.

 

Stored results require more disk space. Unstored results require more time to calculate.

 

For normal use, use None or Minimal and enable the option to Automatically create indexes as needed.

 

Selecting All for text fields can significantly increase file size, as every word in the text field will be indexed. Certain operations, such as importing records, may also take more time, as each word in the field will be added to the field's index as the import occurs.

 

The Automatically create indexes as needed option indexes the field the first time a user performs a find request (searches) on the field. The first search is slow because the index is being created. However, subsequent searches on that field are faster because they use the index. (This option also creates an index when the field is used in a relationship.)

 

To create relationships using text fields as match fields without creating word indexes for these fields, use Minimal and disable the option to Automatically create indexes as needed.

 

To reduce file size and prevent users from creating indexes, use None (or Minimal) and disable the option to Automatically create indexes as needed.

 

The combination of selecting None and disabling the option to Automatically create indexes as needed will also prevent the field from being used to create relationships.

 

For databases that will be placed on CD-ROM or other read-only media, any field that could be used in a Find should be set to Indexing All (if disk space on the CD-ROM allows).

[Gill]

Hartelijk dank Rony.

De formule werkt als een speer.

Dit scheelt me heel wat geblader en gezoek.

En ook weer wat geleerd.

Ook de anderen bedankt.

[JeanWM]

als er globalen of gerelateerde gegevens in je berekening zitten, kan je niet "storen"

 

Klopt helemaal :

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...

[AvD]

Dank aan Rony en aan Jean voor deze kostbare informatie. Ze is nu veilig en voor eeuwig bewaard in de rubriek Documentatie:

http://www.clarify.net/viewtopic.php?t=1527

[Sanne]

Relaties hebben een geindexeerd veld nodig, uitgezonderd globalen

 

Mag ik nog een puntje op de i zetten?

 

Relaties hebben - aan de rechterkant - een geindexeerd veld nodig: aan de linkerkant kan een ongeïndexeerd veld (global) staan.

[Rony Rabijns]

In de marge van dit verhaal, kreeg ik gisteren volgend probleem off-line doorgespeeld van een fervente Clarify-ster (met de nadruk op stér )

 

Zij deelde me mee dat je een veld met een unstored auto-enter calculation niet kan indexeren.

 

we hebben toen volgende testopstelling geboetseerd :

cVeldA = 10 ("forced" unstored calculation)

nVeldB met autoenter calculation = Status(CurrentRecordID) * cVeldA

 

deze autoenter is dus unstored, maar het veld nVeldB kan wel degelijk geindexeerd worden.

 

tot hier kon ik haar verhaal dus weerleggen.

 

maar nu ....

 

als je ook een veld cVeldC maakt = nVeldB * nVeldB zou je verwachten dat cVeldC geindexeerd kan worden ...

En dat is dus niet !

Waarom niet eigenlijk ? De gebruikte velden in de berekening zijn toch geindexeerd ?

[Sanne]

Ik heb er vandaag ook nog even mee zitten stoeien.

 

Het zijn bizarre omstandigheden waarin het zich voordoet: kern is dat wanneer je aan een veld een unstored calculatie als auto-enter geeft, en dat veld gebruik je dan weer "ergens" in een calculatie (vaak dan weer in een gerelateerd bestand), en DIE calculatie gebruik je dan weer opnieuw ergens anders.

 

Dan kan je krijgen dat je de calculatie wel handmatig kan storen (je ziet in velddefs dan ook "stored" staan!), maar open je de velddefs later opnieuw, dan blijkt de calculatie weer op unstored te zijn gesprongen.

 

Het lukt je ook niet om op de 2e calculatie een relatie te leggen: want die blijkt weer unstored te zijn geworden.

 

Ik kom het - gelukkig - zelden in het wild tegen: en al helemaal niet in mijn eigen code. Maar ik werk veel met code die door andere programmeurs is geschreven: en daar vind ik dit soort staaltjes wel eens.

[JeanWM]

Je maakt een data channel door links en rechts in de relatie een ‘match’ te maken...

Met een ‘constant field’ in beide bestanden is dat gemakkelijk....

Met dit constant kun je, samen met Set field de data in elke global manipuleren, zo kun je copy/paste vermijden, niks nieuws...en de constant zijn stored...

 

Dat een match field in een gerelateerd bestand geindexeerd is, is niet altijd nodig.

Als je de setting van een constant calculatie op unstore zet, of zelfs een relatie tussen twee globalen op unstore, dan kun je nog altijd data uitwisselen tussen die globalen in de bestanden...

 

Als je twee unstored constanten gebruikt voor een relatie, zal FM zeggen ‘This relationship will not work etc...’. Je mag hier gerust op OK drukken, de relatie zal wel werken...

Global data zal altijd uitgewisseld worden tussen globalen....

[Sanne]

Ah Jean, nu snap ik je. Je wilt algemene data tussen 2 databases uitwisselen en je gebruikt daarvoor een "unstored relatie" (ja, ik bedenk hem net zelf) tussen 2 globalen.

 

Ikzelf gebruik deze ietwat kromme toepassing niet. Wat ik wel vaak heb liggen tussen 2 bestanden waar ik tussen wil uitwisselen, is de "1-link": in beide bestanden een calculatie met als inhoud het getal "1". En op die twee velden een relatie.

 

Dan heb je ook een relatie tussen alle velden in het ene bestand en alle velden in het andere bestand: op die manier gooi ik de algemene gegevens vaak over.

 

Het 1-veld is ook vaak aanwezig in mijn database omdat je zo lekker het aantal records kunt tellen (hoewel je daar ook de count-functie voor heb, ik weet het).

 

Maar, beste mensen, ik zeg nog maar 1 woordje: FileMakerProZeven!

 

Het lijkt alsof we het daar allemaal anders in kunnen gaan (hoewel ik liever eerst nog even een technische workshop volg voor ik wat zeg, want foei: die relaties in 7 )

 

-------

 

< >>

Edited May 2, 2004 by Guest

[Rony Rabijns]

Als je twee unstored constanten gebruikt voor een relatie, zal FM zeggen ‘This relationship will not work etc...’. Je mag hier gerust op OK drukken, de relatie zal wel werken...

Global data zal altijd uitgewisseld worden tussen globalen....

 

de zogenaamde "pipeline"-methode, een open kanaal waardoor je data "pompt".

[Bonte]

In de 7 zijn er nu ook 2 sterktes om te 'indexeren', heeft het nut om bij korte ID velden de zwaarste index te gebruiken?

[Sanne]

Ik heb eens naar 7 gekeken, en daar kun je van een veld qua index zeggen:

 

none - minimal - all

 

In de help-tekst wordt het verschil tussen minimal en all alsvolgt gegeven:

 

Minimal : Create a value index of a text field's contents or a calculation field returning text results.

 

All: Create both word and value indexes for text fields or calculation fields returning text results. For number, date, time, and timestamp fields, as well as calculation fields returning results of these types, All creates an index of a field's values.

 

Maar eigenlijk snap ik nog steeds - voor een tekstveld - het verschil tussen minimal en all niet.

 

"Create both word and value indexes for text fields": wat is voor een tekst-veld nu het verschil tussen een "word-index" en een "value-index"?

[JeanWM]

Dat heeft te maken met de 'Unicode Collation Algorithm', waar onderscheid gemaakt wordt via collatie.

 

Vandaar de verschillen in 'tekst', 'cijfer', datum enz.

 

Zelfs woorden met accenten worden op een andere manier gesorteerd als 'vroeger'...

Nu wordt een controle van 'links' naar 'rechts' gedaan, in tegenstelling tot vroeger...

 

Is allemaal misschien vrij technisch, maar het is degelijk 'database stuff'....

[Sanne]

Dat heeft te maken met de 'Unicode Collation Algorithm', waar onderscheid gemaakt wordt via collatie.

 

Oh wijze doch verre Jean: zoud u hier over kunnen uitwijden?

[JeanWM]

Als 'lid' van het Unicode Consortium...uuuuuuuren....

 

...en in de klas ook, met krijt en bordveger...en studenten die niet akkoord zijn...

 

Maar het is gemakkelijker dat je effe kijkt op :

http://www.unicode.org/

 

Daar is alle info te vinden....

 

Happy reading....