Jump to content
  • 0

Replace field contents traag


caroline

Question

Hallo,

 

Voor onze producten-database heb ik een layout gemaakt waar je het overzicht terug vindt van het aantal stuks er van een product gekocht werd het afgelopen jaar.

Het is simpelweg een portal dat wordt gefilterd door een dropdown waar je het jaar kan kiezen.

Om de pagina snel te laden heb ik de dataniet als calculation field opgeslaan, maar wordt die pas berekend als een trigger op 1 wordt gezet. Deze data verandert toch zelden eens die in de database zit.

 

Dit is de calculatie voor één veld op de layout:

 

Let (
trigger = _trigger
;

ExecuteSQL ( "
SELECT SUM(amount)
FROM volumes
WHERE member_id=11
AND product_id=" & product_id & "
" ; "" ; "" )
)

 

Ik heb een refresh knop (groene pijlen) die er voor zorgt dat de trigger op 1 wordt gezet bij alle records en de data opnieuw wordt geladen. MAAR (en nu komt het):

Dat werkt verschrikkelijk traag. Hoe kan ik er voor zorgen dat dit sneller gaat? Of is er een betere methode om een soortgelijke layout te verkrijgen?

 

Dit is de code die achter de refresh knop zit:

 

Freeze Window
Flush Cache to Disk
Set Error Capture [ On ]
If [ Get(WindowMode) ≠ 0 // Browse mode ]
Exit Script [ ]
End If
Go to Related Record [ From table: “volumes” ; Using layout: “volumes” (volumes) ]
[ Show only related records ]
If [ Get(LastError) ≠ 0 ]
Exit Script [ ]
End If
Replace Field Contents [ volumes::_trigger ; Replace with calculation: 1 ]
[ No dialog ]
Go to Layout [ original layout ]

 

Hopelijk is alles duidelijk...

Alvast bedankt voor de reacties!

screenshot_volumes.jpg.9dd0d9e4f1c4886002b967ce5385c25d.jpg

Link to comment

6 answers to this question

Recommended Posts

  • 0

Je schrijft dat je portaal wordt gefilterd op een opgegeven jaartal. Hoeveel jaar heb je in de database zitten? En om hoeveel record gaat deze telling? Want je telt hier aantallen en geen bedragen? Als je inderdaad portalfiltering hier toepast, zal naamate de tijd vordert, dit script steeds meer tijd gaan kosten.

 

Portalfiltering heeft alleen maar betrekking op de weergave, maar niet op de opgehaalde gegevens, dus als je naar de gerelateerde records gaat, dan ga je ook naar de weggefilterde record en je bewerking zal daar ook op plaatsvinden. Als je dat sneller wilt dan kan je beter je relatie aanpassen zodat daar het jaartal in wordt meegenomen.

Link to comment
  • 0

Hoewel de SQL engine van FIleMaker een uitkomst biedt voor bepaalde situaties, zou ik 'm in dit geval niet gebruiken. De FileMaker SQL engine maakt nog geen goed gebruik van de FileMaker indexen en het slimme caching mechanisme dat jarenlang aan maturiteit gewonnen heeft. De SQL engine cachet wel zaken, maar niet zo slim.

Het is daarom een goed idee om even te kijken of je hetzelfde niet kan doen door een aantal occurrences extra aan te maken en je sum over een relatie op te halen, via de native FileMaker methode.

Probeer het eens. Het is hoogstwaarschijnlijk een stuk sneller.

Link to comment
  • 0

Ik ben het helemaal met de voorgaande reacties eens: het probleem wordt vooral veroorzaakt doordat je executeSQL gebruikt in al die gerelateerde records: iedere record veroorzaakt een SQL op zich. En vele kleine vertragingen stapelen zich op tot één grote.

 

De oplossing met een paar TOC's en een 'native relatie' is dan veel sneller.

 

Maar wanneer je toch liever van executeSQL gebruik wilt maken, zou je ook het volgende kunnen overwegen: maak gebruik van 1 grote SQL die eerst alle resultaten berekent, ga dan met een GTRR naar de 'tabel in de portal' en vul dan de som-velden met behulp van een loop of een slimme Replace uit de SQL-results, die als één blok tekst terugkomen.

 

NB je moet wel zorgen dat je SQL nul teruglevert als er geen resultaten zijn, dus ik denk met een outer join.

 

Hans Erik

Link to comment
  • 0

Bedankt voor jullie reacties!

 

Execute SQL is inderdaad niet de beste oplossing zo blijkt nu. Ik zal het eens proberen met de tips die jullie meegeven.

Er zitten momenteel nog niet zo veel records in trouwens, maar in de toekomst komen er natuurlijk wel veel bij in de toekomst (+/- 5000 per jaar).

 

i'll check it out. bedankt!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...