Set Global: cache flush

[andries]

Ik heb iets raars voor.

 

De volgende relatie bestaat:

 

vdos__VDOS__ - dos__DOS__ - dos_DEC__Selected

 

Als ik vanuit VDOS een sortering uitvoer op een veld in DOS dan gaat het de eerste keer wat langzamer en dat is logisch omdat FileMaker dan de cache opbouwt. De volgende sorteringen gaan snel.

 

Als ik nadien dan echter een globaal instel in DOS om een bepaalde DEC record te selecteren en weer sorteer vanuit VDOS op een veld in DOS dan gaat het weer traag, alsof FileMaker de cache verloren is door het zetten van die globaal.

 

Iemand hier ervaring mee? Of enig idee wat hier kan spelen waarom dit verloren gaat in de cache?

[Felix]

.

Edited October 6, 2015 by Guest

[andries]

nee nee, gewoon het veld aanpassen en teruggaan naar de lijst en sorteren... (manuele acties, geen scripting)

 

en ik denk niet dat er een commit met flush caches bestaat als optie

[Felix]

.

Edited October 6, 2015 by Guest

[andries]

tussen VDOS en DOS is er een 1 op 1 relatie, geindexeerd

tussen DOS en DEC wordt inderdaad de globaal gebruikt.

 

wat ik denk dat er gebeurt is dat als je een waarde aanpast in je TOG die invloed heeft op een niet geindexeerde relatie, FileMaker de cache voor gerelateerde records flusht. Want als je sorteert op een veld in VDOS blijft het snel gaan.

[andries]

ok gevonden!

 

het feit dat je dus een globaal aanpast in de gerelateerde tabel (DOS) zorgt er voor dat FileMaker de cache voor die tabel verliest.

 

Oplossing:

 

VDOS - DOS x VARIABLES - DEC

 

Waarbij dus nu de globaal in VARIABLES zit en een carthesian tussen DOS en VARIABLES. Cache van DOS blijft nu behouden.