Ik had gehoopt dat dit in FileMaker 12 beter zou werken maar helaas: FileMaker rekent velden op basis van complexe relaties niet altijd door.
Voorbeeld.
Ik heb een tabel met bankrekeningen en een tabel met saldi.
In de saldo-tabel wordt per rekening een saldo met bijbehorende datum opgeslagen.
Dus op een gegeven moment heb je de volgende saldi, uitgewerkt voor 1 rekening:
02-10-2012 €300,-
05-12-2012 €145,-
17-12-2012 €160,-
04-01-2013 €88,-
Merk op, dat de saldi niet altijd op dezelfde dag vd maand worden geregistreerd en dat in 1 maand best meerdere saldi kunnen voorkomen, of helemaal niks.
In de rekeningtabel wil ik op een peildatum het laatst bekende saldo weten en de datum van dat saldo.
Dus als ik invoer: 06-12-2012 moet ie 05-12-2012 geven en € 145,-
En als ik invoer: 02-01-2013 moet ie 17-12-2012 geven en € 160,-
In rekning heb ik een global field 'peildatum' (type date), dat een complexe relatie heeft met saldi:
TOC heet saldi_peildatum en de relatie is op rekening::peildatum >= saldi_peildatum::datum_saldo
Op basis van die relatie bereken ik in de tabel 'rekening' eerst de laatst bekende datum met een saldo:
b_laatste_datum = max ( saldi_peildatum::datum_saldo )
De max-functie zorgt ervoor dat je altijd de laatste datum krijgt die op of voor de peildatum valt.
Dat gaat prima: ik vul een andere datum in, het systeem berekent meteen de juiste datum uit de saldo-tabel.
Maar nu wil ik die 'b_laatste_datum' gebruiken om uit diezelfde saldo-tabel ook het bijbehorende saldo op te halen en dat doet ie niet! FMP heeft kennelijk niet door dat de b_laatste_datum veranderd is en voert de vervolgberekening niet uit, evalueert de relatie zelfs niet.
NB De saldo-tabel is hiervoor dus gekoppeld op rekening::b_laatste_datum = saldi::datum_saldo, maar die wordt niet getriggered terwijl b_laatste_datum WEL verandert.
Is dit een feature of een bug? Ik houd het op het laatste.
Vraag
hans erik
Ik had gehoopt dat dit in FileMaker 12 beter zou werken maar helaas: FileMaker rekent velden op basis van complexe relaties niet altijd door.
Voorbeeld.
Ik heb een tabel met bankrekeningen en een tabel met saldi.
In de saldo-tabel wordt per rekening een saldo met bijbehorende datum opgeslagen.
Dus op een gegeven moment heb je de volgende saldi, uitgewerkt voor 1 rekening:
02-10-2012 €300,-
05-12-2012 €145,-
17-12-2012 €160,-
04-01-2013 €88,-
Merk op, dat de saldi niet altijd op dezelfde dag vd maand worden geregistreerd en dat in 1 maand best meerdere saldi kunnen voorkomen, of helemaal niks.
In de rekeningtabel wil ik op een peildatum het laatst bekende saldo weten en de datum van dat saldo.
Dus als ik invoer: 06-12-2012 moet ie 05-12-2012 geven en € 145,-
En als ik invoer: 02-01-2013 moet ie 17-12-2012 geven en € 160,-
In rekning heb ik een global field 'peildatum' (type date), dat een complexe relatie heeft met saldi:
TOC heet saldi_peildatum en de relatie is op rekening::peildatum >= saldi_peildatum::datum_saldo
Op basis van die relatie bereken ik in de tabel 'rekening' eerst de laatst bekende datum met een saldo:
b_laatste_datum = max ( saldi_peildatum::datum_saldo )
De max-functie zorgt ervoor dat je altijd de laatste datum krijgt die op of voor de peildatum valt.
Dat gaat prima: ik vul een andere datum in, het systeem berekent meteen de juiste datum uit de saldo-tabel.
Maar nu wil ik die 'b_laatste_datum' gebruiken om uit diezelfde saldo-tabel ook het bijbehorende saldo op te halen en dat doet ie niet! FMP heeft kennelijk niet door dat de b_laatste_datum veranderd is en voert de vervolgberekening niet uit, evalueert de relatie zelfs niet.
NB De saldo-tabel is hiervoor dus gekoppeld op rekening::b_laatste_datum = saldi::datum_saldo, maar die wordt niet getriggered terwijl b_laatste_datum WEL verandert.
Is dit een feature of een bug? Ik houd het op het laatste.
Heeft iemand hier ervaring mee?
Link naar reactie
6 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.