Update unstored calculation

[andries]

Raar gedrag, 2e keer dat ik het tegenkom, dus ik zou graag nu mijn ervaring met een theorie staven. Ik heb alleen de theorie niet.

 

Ik heb het gevoel ( en ben er zeker van dat dit gevoel klopt ), dat telkens als ik in een hosted applicatie, een unstored calculation aan het aanpassen ben in de database definities, FileMaker het aanmaken van records in die tabel blokkeert voor andere gebruikers op het systeem.

 

Klopt dit? En zo ja waarom?

[JeanWM]

... telkens als ik in een hosted applicatie, een unstored calculation aan het aanpassen ben...

 

Dat klopt.

 

Daarom ook dat het af te raden is om aanpassingen te doen in/aan een hosted file.

 

In telegram stijl:

 

FileMaker heeft een vrij goede RLA. Een record kan maar aangesproken worden door 1 gebruiker.

Al de rest wordt afgesloten.

 

Als 'gebruiker' dien je te lezen; user, script, en alles wat een verandering aan data kan doen (Set, Insert, Paste, Replace, Cut, Copy, Clear, Import ( synch en update existing), Relookup, Select All ( in a field), Delete Record, Delete A ll Records and Delete Portal Row, etc.)

 

Zo ook de data management engine.

 

Vermits je aan een unstored calculatie werkt, kan de waarde van die calc beinvloed worden door een hele reeks andere zaken.

 

Om verkeerde return info te beletten na het terug vrij geven van het record, zal FM alle mogelijke pogingen tot verandering blokkeren.

Het gemakkelijkste op dat niveau is table lock.

 

Is de datamanagement engine niet actief, zal FM een bericht genereren.

Is de datamanagement engine wel atief, is er voor FM geen mogelijkheid te weten 'wie' bezig is veranderingen te doen.

Dus, het doet geen moeite een bericht te genereren.

 

Botton line: als je veranderingen wil doorvoeren doe je dat het best op een bestand dat off line is.

Tenzij je heel goed weet wat je doet en wat de gevolgen kunnen zijn/zullen zijn.

[andries]

He Jean

 

bedankt voor je antwoord, en ik vind ook dat FileMaker de RLA zeer goed doet (als je dit wil gaan doen in een andere soort database ben je een eind aan het programmeren).

 

Toch zijn er drie zaken die mij niet helemaal logisch lijken:

 

• Het aanpassen van een auto-enter calculatie, die naar mijn inziens wel rechtstreeks invloed heeft op de data die opgeslagen zal worden, vertoont dit gedrag niet. (heb het nog niet geprobeerd met een stored calculation)
   
  
• Een unstored calc heeft toch niets met dataopslag te maken. We passen enkel de calculatie aan... dus op zich zou FileMaker hier niet moeilijk over moeten doen. Bij het wijzigen van een unstored calc worden deze toch berekend op de server en dan worden de veranderingen naar elke client doorgestuurd (wat niet zo is bij auto-enters, dus mss ligt daar een verschil). Dus op zich zou tijdens het aanpassen elke gebruiker toch moeten verder kunnen werken (lijkt mij ).
   
  
• Ik heb het gevoel dat dit niet zo was bij FileMaker Server 10, en dat het zich pas nu manifesteert bij FileMaker Server 11. nu ja op zich verbiedt niets FileMaker om hun RLA logica aan te passen.

 

 

En verder over het niet live ontwikkelen, daar heb je me betrapt

 

Het is idd niet common om dit te gaan doen, maar ik probeer toch altijd af te wegen of een hele import/synchro tussen een development file <> productie file de moeite is. Om simpel weg een unstored calc aan te passen zodat hij nu toont "onbetaald" ipv "open factuur" lijkt mij een beetje overkill om dan een volledige versioning te gaan doen. Maar ik geef toe dat dit zoveel mogelijk moet vermeden worden.

[Peter Wagemans]

Het verschil tussen theorie en praktijk dus. In theorie doe je aan versioning en ontwikkel je offline.

In praktijk ontwikkel je online, omdat je dan het meeste "bang for the buck" produceert. Meestal gaat het goed, soms gaat het absoluut fout. Zoals gisteren bij een klant, waar FileMaker zich ophing omdat ik een global calculation toevoegde.

 

Stel je voor: een GLOBAL calculation. FileMaker blokkeert alles voor de gebruikers. Dit is niet correct. FileMaker hercaluleert alle records. Dit is eveneens niet correct.

FileMaker heeft hier nog werk te doen. Natuurlijk; het staat niet mooi op de doos van de volgende versie: "FileMaker Pro 12, nu met minder bugs".

 

Maar FileMaker mag eens goed nadenken over hun eigen "Snow Leopard" versie.

[JeanWM]

 

Toch zijn er drie zaken die mij niet helemaal logisch lijken:

 

FileMaker gebruikt een logica die soms wat eigenaardig overkomt, maar daarom niet minder juist is.

 

Niet al te technisch:

FileMaker werkt volgens een dependence graph, een DAG (Directed Acyclic Graph).

Als je een cyclic dependence berekening wilt maken (circular) in FM, zal dat niet lukken.

Het gebruik van directed cycles zal dus niet lukken. Dit wil zeggen dat FM enkel indirected cycles toelaat.

 

Als je dat toepast op unstored calculations, zie je dat links enkel kunnen komen van unstored calculations.

Waar stored calculations enkel naar andere stored calculations kunnen gaan.

 

FileMaker zal een update upwards propageren in de graph voor stored calculations.

Terwijl unstored calculations downwards worden gepropageerd. Zelfs indien gebruikte velden geen verandering ondergingen.

 

We onthouden dus dat de propagation van stored gaat toward referencing fields en unstored gaat toward referenced fields.

 

 

Bij het wijzigen van een unstored calc worden deze toch berekend op de server...

Het compute moment voor unstored calculations is wanneer FM de waarde nodig heeft, of voor displaying of in een ander calculation.

De memory usage zal dus temporarily in RAM zijn, waar het voor stored calculations in de file zelf zal zijn.

 

ik probeer toch altijd af te wegen of een hele import/synchro tussen een development file <> productie file de moeite is. Om simpel weg een unstored calc aan te passen zodat hij nu toont "onbetaald" ipv "open factuur" lijkt mij een beetje overkill om dan een volledige versioning te gaan doen.

 

In een "dood" moment kun je dit wel doen. Beter is de applicatie van de server halen, de aanpassingen te doen en daarna de applicatie terug plaatsen.

[JeanWM]

Stel je voor: een GLOBAL calculation.

 

Daar heb je het Peter.

De DAG kikt in omdat het een calculation is....

 

Dus is het wel correct om (tijdelijk) te blokkeren....

[Peter Wagemans]

Klinkt goed Jean,

 

Maar het is wel zinloos om 50.000 records te hercalculeren op een server, omdat je een global calculation bijmaakt.

De server doet het bijvoorbeeld niet als ik een unstored calculation bijmaak. En logischerwijze wél als ik een stored calculation bijmaak.

 

FileMaker heeft misschien een leuke DAG dan, maar ik niet.

FileMaker VOORZIET aanpassing van een database terwijl ze gehost is, het is zelfs als feature gepresenteerd van FileMaker Pro 7.

Als dat niet goed werkt, is dat een bug, en dat moet FileMaker die bug fixen.

 

FileMaker ondersteunt helemaal niet goed dat je offline development doet en dan online implementeert, doordat de data, de applicatie en de interfaces allemaal samen zitten.

De importeerfunctie ( script stap ) is archaisch en in dit geval onbruikbaar, en elke product developer zit hiermee zwaar in zijn of haar maag, en sommige zoeken hierdoor naar andere oplossingen zoals Servoy.

Ik beschouw hierdoor offline developen als een zwaar tijdverlies en alle systemen die een offline template met online data vullen zelfs gevaarlijker... dan online developen.

 

Ben ik een beetje boos aan het worden? Absoluut. FileMaker slaagt er niet in om te leveren wat ze beloven. Een FileMaker server kost geld. Véél geld. Dat dat ding overkop gaat omdat je een veldje bijmaakt, vind ik daarom onaanvaarbaar.

Terwijl ik het veld aanmaakte werd op dat ogenblik net de uurlijkse backup begonnen. Die kon niet verder omdat er een lock op de database zat. Rapporteerde een "unknown error". Geen backup dus. En FileMaker Server's rechterhand weet niet niet wat de linkerhand doet. Unknown error. Plezant hoor.

40 gebruikers spelen dus een uur data kwijt, en velen kunnen dat niet recuperen ( nota's bij telefoongesprekken en zo ).

ONAANVAARBAAR, FileMaker!!!!

[Peter Wagemans]

Hier is een goeie:

 

Maak een unstored calculation bij. Doen dan "OK" ( commit de veranderingen ). Je ziet de server NIET alle records hercalculeren.

 

Maak nu een een stored calculation bij. Doen dan OK. Je ziet de server WEL alle records hercalculeren.

 

Maak nu een stored calculation bij. Als ze gemaakt is, verander ze dan naar unstored. Raad eens wat er gebeurd als je OK klikt....

 

 

Hier een andere goeie:

 

FileMaker Server lockt de database zodra je gegevens BEGINT te veranderen. En niet op het ogenblik dat je deze gegevens ook daadwerkelijk doorgeeft met de OK knop.

Als je dus een occurrence van plaat verzet, wordt het hele systeem vergrendeld, het wordt pas ontgrendeld als je annuleert.

Logisch?

[Peter Wagemans]

Ik heb files waarbij de tabellen primary keys hebben die niet leeg mogen blijven, en dat is strict gedefinieerd.

Nochthans gebeurd het regelmatig dat er records ontstaan ZONDER primary key. Gewoon leeg. Net op het ogenblik als er aan de velddefinities gewerkt is.

 

Nee, ik ben helemaal niet blij met de manier dat FileMaker toelaat dat je velden aanpast op een gehoste database, en dat dan niet bullet proof kan krijgen.

Ik blijf echter bij mijn standpunt. Online developen gaat 2 keer zo snel dan offline developen. Offline developen geeft update problemen en introduceert nog een aantal andere bugs die veel erger zijn.

 

In een ideale situatie heb je een klant die zegt: mag het 2 keer langer duren? Geen probleem. O ja, gebruikersdocumentatie? 3 keer langer, ook geen probleem. En ook nog technische documentatie, 4 keer langer. Doe maar hoor. En opleiding van de gebruikers... ga zo maar door. De realiteit is dat de typische FileMaker klant niet met een mega budget zit.

[JeanWM]

Je hebt gelijk Peter.

 

En in meer en meer gevallen begin ik mij ook te ergeren aan het feit dat de FileMaker logica niet "mijn" logica volgt.

 

FileMaker Inc. wil van twee walletjes tegelijk eten.

 

Het blijft trouw aan de initiele opzet van het programma: end user.

 

Het wil tegemoet komen aan de meer professionele eisen: developers.

 

Ik zit zelf een beetje veilig omdat ik enkel database (geen brand) technieken moet uitleggen.

Als FileMaker het niet kan, of tegenspartelt, gebruik ik Sentences.

 

Hoe dan ook, mijn boekje is gevuld.

Als developer, gebruik makend van FileMaker, kan ik de frustratie begrijpen. Aanvaarden: niet altijd.

 

Er is wel een technische uitleg (excuse) te vinden binnen FileMaker inc. voor een bepaald. volgens ons niet logisch gedrag, of dat nu als bug kan beschouwd worden of niet.

 

FileMaker dient inderdaad de online development sluitend te krijgen. Maar dan moeten we waarschijnlijk 3 jaar wachten naar een nieuwe versie.

En dan komt het financiele de kop opsteken.

 

Het is dus gemakkelijker te zeggen: je kunt dit doen, maar we raden het eigenlijk niet aan....

En dat laatste dekt alle mogelijk ramp scenarios.

 

Maar ondertussen zitten we met veel minder haar, met beschadigingen aan muren en hechtingen in ons hoofd....

[JeanWM]

Hier is een goeie:

 

Maak een unstored calculation bij. Doen dan "OK" ( commit de veranderingen ). Je ziet de server NIET alle records hercalculeren.

 

Neen, dat gebeurt op RAM niveau.

 

Maak nu een een stored calculation bij. Doen dan OK. Je ziet de server WEL alle records hercalculeren.

 

Yep, dat gebeurt op file niveau.

 

 

Hier een andere goeie:

 

FileMaker Server lockt de database zodra je gegevens BEGINT te veranderen. En niet op het ogenblik dat je deze gegevens ook daadwerkelijk doorgeeft met de OK knop.

Als je dus een occurrence van plaat verzet, wordt het hele systeem vergrendeld, het wordt pas ontgrendeld als je annuleert.

Logisch?

Ja, omdat het compute moment begint op het moment dat de "define" begint, en dat ageert op alle records, dus complete record lock voor alles.

 

Met die manier van werken zitten we inderdaad met een hele boel wasted computation.

[andries]

Hier is een goeie:

 

Maak een unstored calculation bij. Doen dan "OK" ( commit de veranderingen ). Je ziet de server NIET alle records hercalculeren.

 

Neen, dat gebeurt op RAM niveau.

 

Dat is waar, maar dit verklaart voor mij niet waarom FileMaker de aanmaak van nieuwe records gaat blokkeren, als ik enkel de intentie heb om een calculatie aan te passen die verder geen effect heeft op de file. Zoals je zelf zegt wordt er "downward" geëvalueerd. Wat wil zeggen dat unstored calculations hun data gaan berekenen als ze gevraagd worden (en dan de data van de gerefereerde velden gaan opvragen) en dat zij verder geen invloed hebben op andere velden die hun zouden refereren. Of zelfs straffer, dat zij niet rechtstreeks kunnen beïnvloed worden door andere velden. Er kunnen namelijk enkel links komen (en dus vertrekken) van een unstored field. Waarom mogen gebruikers op dat moment dan niet vrolijk records aanmaken? Ik pas toch enkel een calculatie aan die in het RAM wordt uitgerekend. En die trouwens pas zal worden geëvalueerd bij het bevestigen van de veranderingen van de database definities. Al die tijd daarvoor doe ik toch niets fundamenteels aan de file of zijn data.

 

Verder heb ik nu ontdekt dat het inderdaad bij elke verandering in de veld definities het lock mechanisme aanspringt, stored of unstored. Maar ik kon wel de ERD aanpassen en relaties aanpassen etc.

 

mmmhh interessant:

 

 

 

Is de datamanagement engine niet actief, zal FM een bericht genereren.

Is de datamanagement engine wel atief, is er voor FM geen mogelijkheid te weten 'wie' bezig is veranderingen te doen.

Dus, het doet geen moeite een bericht te genereren.

Je krijgt een bericht terug dat de Admin aan het werken is aan het database definities. Tenzij je dus de foutopvanging aanzet...

 

 

Wat ik ook nog wel raar vind is dat je dan wel nog de records die bestaan kan aanpassen (alle... ook gelukkig maar ). Dus enkel aanmaak wordt geblokkeerd... Voor aanpassingen in bestaande records gelden de oude auto-enter voorwaardes nog. Waarom kunnen die dan ook niet gelden voor de nieuwe records die worden aangemaakt totdat de veranderingen worden doorgegeven?

[JeanWM]

... als ik enkel de intentie heb om een calculatie aan te passen die verder geen effect heeft op de file.

Het zit 'em in de "intentie".

Ja, jij weet dat, maar FileMaker, die iets moet gaan doen, weet dat niet. En er is geen manier om het te "zeggen".

Dus speelt FM op veilig, en hop, alles en iedereen buiten.

 

 

Zoals je zelf zegt wordt er "downward" geëvalueerd. Wat wil zeggen dat unstored calculations hun data gaan berekenen als ze gevraagd worden (en dan de data van de gerefereerde velden gaan opvragen) en dat zij verder geen invloed hebben op andere velden die hun zouden refereren. Of zelfs straffer, dat zij niet rechtstreeks kunnen beïnvloed worden door andere velden. Er kunnen namelijk enkel links komen (en dus vertrekken) van een unstored field. Waarom mogen gebruikers op dat moment dan niet vrolijk records aanmaken? Ik pas toch enkel een calculatie aan die in het RAM wordt uitgerekend. En die trouwens pas zal worden geëvalueerd bij het bevestigen van de veranderingen van de database definities. Al die tijd daarvoor doe ik toch niets fundamenteels aan de file of zijn data.

 

Hetzelfde hier. Jij weet het, weet wat je "gaat" doen, FM weet het niet. En als er geen details beschikbaar zijn, gelden algemene regels. General lock.

 

Waarom kunnen die dan ook niet gelden voor de nieuwe records die worden aangemaakt totdat de veranderingen worden doorgegeven?

Hetzelfde, jij weet dat allemaal, FM heeft enkel het raden. Het kan zijn dat je van een stored een unstored calc wil maken, of omgekeerd.

Al die tijd moet FM de hele applicatie veilig houden. Dus geen aanmaak van records mogelijk omdat het niet weet in welke richting de veranderingen zullen gaan in de dependence graph.

 

Maar het ligt een beetje complexer.

De dependence graph werkt in clusters.

Van een standard field naar stored calculations naar unstored calculations over global, summary, related.

 

Het geheel is te ingewikkeld voor een forum post. Ik ga hier dus niet dieper op in. Het is ten andere vrij droge, maar wel boeiende cursus stof.

[trikke]

Ga vooral door, hier leren we nog eens wat...

[WJ]

Wij maken toch bijna altijd een updater. Een bestand dat de data overhevelt. En ja het kost meer tijd. Maar eenmaal gemaakt is het bijwerken niet heel veel werk. En je kan de klant het werk laten testen ! Ook erg fijn, het wordt wat minder adhoc. Maar het blijft verleidelijk om live wat aan te passen.

De import mogelijkheden zijn inderdaad belabberd. Een import optie matching op FieldID zou al een heleboel schelen. Het blijft tricky omdat je niet wilt dat er iets mis gaat in dat process. Maar ja live werken is niet fijn.... geeft teveel stress mijn inziens, zeker bij grote klanten. FileMaker zou het updaten van Files moeten ondersteunen via de DDR. Dus een ddr toepassen op een file.

Maar of dat er ooit komt ?

 

Groet WJ

[JeanWM]

Ga vooral door, hier leren we nog eens wat...

 

We wijken dan meer en meer af van FileMaker in de richting van DB technisch....

[andries]

mag van mij hoor, een beetje afwijken

 

nuja, toch ben ik niet helemaal tevreden met het antwoord. Wat ik tot nu toe onthoud: als we in de velddefinities iets aanpassen zet FileMaker een tablelock. Lijkt me logisch ook.

 

Wat me niet logisch lijkt is de manier waarop die tablelock wordt gezet. De tablelock heeft enkel invloed op het aanmaken en verwijderen (waarom?) van records.

Ik blijf erbij: voor bestaande records kan FileMaker de oude velddefinities gebruiken (dus oude auto-enters, calculaties, summaries, etc). Voor deze records geldt toch ook dat wat ik aan het veranderen ben invloed op hun zal hebben, en niet alleen op nieuwe records die ik ga aanmaken. Maar blijkbaar is het voor die bestaande records wel mogelijk om ergens nog de "oude" velddefinities op te vragen, maar kan hij voor het aanmaken van nieuwe records hier geen gebruik van maken.

 

Dus lijkt mij een aanbeveling voor FileMaker: gebruik dezelfde "oude" velddefinities die je nu nog gebruikt om bestaande records te laten werken ook voor het aanmaken van nieuwe records. Pas bij het bevestigen van de database definities worden de regels effectief aangepast. Volgens mij moet dit kunnen, tenzij ik iets over het hoofd zie.

[JeanWM]

Wat me niet logisch lijkt is de manier waarop die tablelock wordt gezet. De tablelock heeft enkel invloed op het aanmaken en verwijderen (waarom?) van records.

Omdat FileMaker geen rekening houdt met de veldwaardes, iets wat jij wel doet.

 

FM rekent met o.a. veldIDs. Voor FileMaker is A + A niet gelijk aan 2*A. Het veld A kan een type text, nummer, datum etc zijn.

Wij "zien" de veldwaarde en rekenen dan ook met die waardes. FileMaker rekent met ID en de attribute gegeven aan de ID.

 

Ik blijf erbij: voor bestaande records kan FileMaker de oude velddefinities gebruiken (dus oude auto-enters, calculaties, summaries, etc). Voor deze records geldt toch ook dat wat ik aan het veranderen ben invloed op hun zal hebben, en niet alleen op nieuwe records die ik ga aanmaken. Maar blijkbaar is het voor die bestaande records wel mogelijk om ergens nog de "oude" velddefinities op te vragen, maar kan hij voor het aanmaken van nieuwe records hier geen gebruik van maken.

Veronderstel

Z, Number 
Y, Number 
X, Calculation, =Status(CurrentUserCount) 
W, Calculation, =Z+Y 
V, Calculation, =Y+X 
U, Calculation, =Max(W,V) 
T, Calculation, =U*(U+1) 
Alle velden zijn stored.

 

Veronderstel verder dat

 

Z=Y=X=2 ( dus , W=V=4, U=4, T=20)

 

Als we Z veranderen in 0, zal dat een update triggeren in W (dat wordt 2).

Dat zal een update triggeren in U, ondanks het feit dat de return waarde dezelfde blijft.

Ondanks het feit dat U in waarde hetzelfde blijft, zal FM toch een update van T doen, terwijl er geen update van X en V is.

 

Veranderen we nu Y ipv Z, zal FM een update doen van W, V, U en T en zal X gerust laten.

Hier heeft FM wel een soort van efficient update order.

Y zal een update triggeren voor U en T, maar enkel 1 keer, geen twee keer zoals zou verwacht worden.

1 keer via V en 1 keer via W.

 

Er is al heel wat verbetering gekomen met de invoering van de Let() functie, warbij double (of meer) computation niet meer nodig is.

We bepalen een waarde in een variable en die wordt verder gbruikt.

 

Dus lijkt mij een aanbeveling voor FileMaker: gebruik dezelfde "oude" velddefinities die je nu nog gebruikt om bestaande records te laten werken ook voor het aanmaken van nieuwe records. Pas bij het bevestigen van de database definities worden de regels effectief aangepast. Volgens mij moet dit kunnen, tenzij ik iets over het hoofd zie.

 

Volledig akkoord dat het moet kunnen, en het zal allemaal waarschijnlijk wel komen.

 

Maar je ziet dat een eenvoudige verandering, die vrij logisch lijkt en blijkbaar gemakkelijk te doen is, achter de schermen een vrij gecompliceerd iets kan zijn.

 

Gewoon 1 volgorde in de dependence graph aanpassen kost al meer dan 500 code regels achter de schermen.

 

Iedere regel dient getoetst te worden aan de Field Dependency Table. Om nu constant hercomputation tegen te gaan en de Field Dependency Table te beschermen, zal FM een lock zetten op alles wat die table in gevaar kan brengen.

 

Mettertijd zullen er meer mogelijkheden komen om de lock wat soepeler te maken (zie de Let() functie en de introductie van variables), maar dat kost niet alleen tijd, ook geld.

[JeanWM]

Om nu terug te gaan naar je initiele vraag bij gebruik van een unstored calculation.

 

Bij het gebruik van een unstored calculation heeft FM write access nodig, bv als de functie Get ( FoundCount ) in unstored vorm gebruikt werd.

 

Bij het actief aanpassen van een unstored calculation in de Manage Database engine zal FM een tijdelijke lock zetten op alle records met een unstored calc en write access afzetten. Dus is er geen record aanmaak mogelijk.

 

Pas bij het verlaten van de calc window zal FM aan de update van records beginnen.

Dat zie je o.a. als je een massa records hebt in je toepassing. Je moet even wachten omdat FM de dependencies aanpast.

[andries]

ok nailed it to the bottom... ( I guess )...

 

met dank aan bcooney: http://fmforums.com/forum/topic/78884-adapting-an-unstored-calc-on-a-hosted-application/page__gopid__368587#entry368587

 

 

het is de volgende definitie die dus een Table Lock veroorzaakt, en niets, maar dan ook niets anders (tenzij ik iets over het hoofd heb gezien): auto enter Serial Number!

 

En dat is ook logisch. FileMaker heeft die waarde nodig om een nieuwe record aan te maken.

 

Heb een hele testfile aangemaakt met stored and unstored calculaties: ik kon records blijven aanmaken. Pas als ik een veld introduceer met een auto enter serial number kwam de table lock in het spel. Nu is dat een veelgebruikte techniek om de primary key aan te maken. Misschien toch geen slecht idee om over te gaan naar UUID.

 

Verder was alles wat JeanWM hier heeft uitgelegd een hele eye-opener voor mij, waarvoor dank!

[andries]

Dat zie je o.a. als je een massa records hebt in je toepassing. Je moet even wachten omdat FM de dependencies aanpast.

 

niet helemaal. FileMaker slaat in een aparte tabel de dependencies op (dus welk veld naar welk veld verwijst). Als FileMaker toont: "rebuilding dependencies" is hij bezig met die tabel up te daten. En als je dus veel berekeningen hebt met met vele verwijzingen, kan dit even duren. Heeft eigenlijk niets met het aantal records te maken.

 

Tenzij je natuurlijk een stored calc hebt aangepast die FileMaker opnieuw moet evalueren voor al die records.

[JeanWM]

 

Tenzij je natuurlijk een stored calc hebt aangepast die FileMaker opnieuw moet evalueren voor al die records.

 

Dus is het ook records afhankelijk.

 

Wat ook een rol speelt, en daar hebben we het (nog) niet over gehad, is de field validation en de record validation.

 

Nu dat we de Let() functie hebben, maken we meer en meer gebruik van die techniek om de oude werkwijze van lookups te vervangen.

We werken dus meer en meer op het niveau van field validation/auto-enter.

 

Field validation en record validation zijn twee verschillende beestjes om te behandelen.