cache <> goed rekenen?

[SuperWimmie]

FM8 Windows.

 

Ik gebruik zware rekenkundige acties in een grote applicatie.

 

Nu bezit ik een bestand met offerteregels en opdrachtregels (in dezelfde tabel), door middel van een (lege) opdrachtdatum wordt dit onderscheiden van elkaar.

 

Ik heb in versie 6 diverse rapporten gemaakt, waarbij ik een globale variabele gebruik om alle totaaltellingen

a. met alleen offerteregels

b. met alleen opdrachtregels

c. met beide regels

tot de juiste uitkomst te laten leiden.

 

In versie 6 werkte dit perfect. In de afdrukscript kreeg de gebruiker de keuze, de globale variabele werd ingesteld, het schermvoorbeeld rekende alles netjes opnieuw uit en voila: de juiste uitkomsten werden gepresenteerd.

 

Maar in FM8 doet hij dat niet meer.....

 

Het eerste rapport gaat goed, hij berekent alles zoals dat via de dan geldende parameter moet zijn.

Maar zodra ik direct erachteraan een nieuw rapport op vraag, en de parameter verander, rekent hij helemaal NIETS opnieuw uit.

De oude waarden komen weer netjes in beeld.....

 

Oeps, is dit de prijs voor een hogere performance?

 

Heeft iemand een tip dat ik FM8 weer opnieuw kan laten rekenen?

(commit record heb ik al ingesteld staan voor alle mogelijke wijzigingen)

[rmw]

Een snelle gok: Refresh Window[Flush Cache Results] ?

 

rmw

[SuperWimmie]

Natuurlijk even uitgeprobeert (mijn dank voor de tip):

 

Gedeeltelijk werkt dit.

 

Wel met betrekking tot de gegenereerde gegevens van de actieve tabel, helaas niet voor de berekening die uit gerelateerde tabellen er onder uit moeten komen...

 

Ik krijg nu zelfs dat de TOTAL velden niet meer overeenstemmen met de in de Calculated Fields gegenereerde totalen...

 

Dieper liggende Child-tabellen worden NIET opnieuw berekend en laten in het scherm nog steeds verkeerde uitkomsten zien!

[SuperWimmie]

Yep, ik ben er uit....

 

 

Wat Filemaker doet, is controleren of één van de records binnen de gevonden set is gewijzigd. Indien dat niet zo is, gaat hij uit van de cachewaarde.

 

De berekening is bij mij zo opgezet, dat de berekeningsparameter in een gebruikersinstellingen record zit.

De records waarin de uiteindelijke berekening zit, worden gewoonlijk dus NIET gewijzigd.

 

Oplossing: door het eerste record waarin berekeningen zitten eventjes aan te passen, signaleert FM een verschilletje en rekent opnieuw de calculated fields uit van de betreffende tabel.

 

 

Je moet het maar net even weten.....

 

(pffft, allemaal nieuwe "workarounds", een functie Recalculate zou hier op zijn plaats zijn.)

 

 

Toch wel belangrijk: stel dat je de BTW percentage van een factuur aanpast, het is dan maar de vraag of hij bij de eerste de beste afdruk het juiste percentage opnieuw heeft doorberekend over de factuurregels heen (indien de BTW per regel wordt berekend)....

[SuperWimmie]

Nou, ben ik weer.....

 

Het gaat gewoon hardstikke fout!

 

Indien de records BINNEN 1 SUBTOTAAL niet gewijzigd zijn, berekend hij het niet opnieuw....

 

Dus ik dacht het op te lossen met de wijziging van het eerste gevonden recordje in elk onderliggende Child bestand, maar dat volstaat niet voor het volledige rapport....

 

De Summary velden voor het totaal-generaal van het rapport worden in zijn geheel niet herberekend....

 

Pfoe, wat hiervan te denken...

[hbrendel]

Staat de calcalutie op 'unstored'?

[SuperWimmie]

Ja.

[hbrendel]

En wat gebeurt er als je dit doet:

 

Freeze Window

Enter Preview mode []

Enter Browse mode []

 

(dit gebruik ik altijd als 'refresh')

[SuperWimmie]

Ik laat sommige uitkomsten ook in de invoerschermen terug komen, daar gaat het net zo goed fout.

 

Ik probeer een testopzetje te maken in de hoop dat ik daarin het probleem kan laten zien.

TestDatabase.zip

[SuperWimmie]

Yes en nu ben ik er toch wel uit!!

 

Wat een gedoe, maar het gaat toch maar weer lukken.

Gelukkig schijnt de zon er ook nog door vandaag, dus de dag kan niet meer stuk....

 

Het probleem:

FM8 zou met een Refresh Window (Flush cached joint results) alle opgeslagen resultaten die al eerder zijn gegenereerd moeten weggooien en nieuwe resultaten opnieuw moeten opbouwen.

 

a. Helaas doet hij dat alleen op het betreffende tabel waarop de opdracht wordt uitgevoerd en relaties van slechts 1 nivo diep (voor zover getest maakt het niet uit of het in één bestand zit, of in aparte bestanden)

 

b. Helaas worden Summary velden die gepresenteerd worden in de Trailing Grand Summary ook niet opnieuw berekend.

 

Voor probleem A laat ik op alle tabellen het commando Refresh Window (Flush cached joint results) uitvoeren

 

Voor probleem B laat ik twee keer achter elkaar Show Omitted Only uitvoeren, zodat de gevonden set voor FM wel gewijzigd is, maar voor de gebruiker hetzelfde resultaat geeft.

 

 

Eindelijk....... *zucht van verlichting*

 

(Superwimmie gaat weer vrolijk verder met zijn mooiste pakket ooit )

[rmw]

Dank voor je doorzettingsvermogen en het presenteren van deze workaround!

 

Dit alleen al maakt het forum uiterst waardevol.

 

rmw