Vertraging in verwerking gegevens

[Joser8]

Heb de laatste tijd wat problemen met Filemaker,

met name dat k de indruk heb dat de verwerking van gegevens vertraging oploopt.

 

Als k 2 scripts na elkaar laat lopen, dan ‘ziet’ Filemaker in het 2de script de gegevens niet die het eerste script heeft verwerkt.

Als k 1 sec na het eerste script het 2de script nogmaals laat lopen werkt dit wel.

 

Iemand een idee? Computerprobleem, filemaker server probleem, ...

 

Met vriendelijke groet

Jo

[Felix]

.

Edited October 6, 2015 by Guest

[SuperWimmie]

Ik heb onderlaatst de Server sided scripting hier en daar toegepast en ben volop tegen dit onderwerp aangelopen.

 

Je ontdekt dan hoe belangrijk Commit Records is.

In vroegere versies van Filemaker bestond dit nog niet en sloeg FM altijd alles direct op, inclusief de verwerking op server en overige werkstations.

Maar dat belastte het systeem te veel en het had ook zo zijn beperkingen, reden om dit nu aan de ontwikkelaar over te laten.

 

Nu met Server sided scripting, gebruik ik stuurvariabelen die ik aan de client kant instel, die vervolgens door het server script moeten worden opgepakt.

Ik kreeg de gekste resultaten, terwijl ik dacht dat het wel in orde was.

Maar zonder Commit Records is de informatie op de server nog niet aanwezig. Vervolgens wordt het server script verwerkt met de foutieve gegevens en komt het script weer terug op het werkstation.

Door b.v. een verandering van layout wordt automatisch een Commit Records uitgevoerd en zat ik verwondert te kijken waarom of mijn server script niet goed werkte...

 

En jawel, de eerste keer ging het fout, de tweede keer ging het ineens wel goed.

[menno]

jaha, de "commit-record", "the infamous script-step", na de conversie van .fp5 naar .fp7 wat een ellende was dat zeg, ben blij dat ik dat al heel lang niet meer heb hoeven doen.

 

Weten jullie het nog? Die melding: "dit record wordt momenteel gewijzigd in een ander venster" terwijl je geen ander venster (meer) open had. Bleek iedere keer weer te zijn veroorzaakt doordat je dan ergens in de tientallen/honderttallen scripts (in systemen van 70-80 bestanden) een commit-record stap nodig had.

 

Bij de conversie iedere set-field laten volgen met een commit-record kon ook niet, want veel scripts gingen er nog van uit dat je een bewerking in een portaal deed .... erg veel werk dus. Moet er bij zeggen dat veel programmeurs ipv "exit-record" de stap "GoTo-Field[]" (zonder een veld aan te geven) misbruikten als "exit-record", met alle gevolgen vandien bij de conversie naar fp7.

[Felix]

.