Commit Record vs. Go to field

[Roger]

Als ik naar mijn oude werk kijk kom ik vaak de scriptstap Go to field tegen waar ik daar tegenwoordig Commit record voor gebruik. Ik vraag me af, zit daar qua wat het doet eigenlijk veel verschil in? Ik weet, bij Commit heb je de mogelijkheid Dialog On/Off en opties als Skip data entry validation en Override ESS locking conflicts. Maar deze opties gebruik ik nooit en ik weet ook niet wanneer ik die zou moeten gebruiken. Ik ben eens benieuwd, wie kan hier iets interessants over vertellen?

[menno]

Go to field werkte in FM6 nog goed, omdat iedere wijziging werd vastgelegd zodra je een veld verliet en niks anders selecteerde .... vanaf FM7 moet je expliciet record/verzoek vastleggen gebruiken om een record op te slaan.

[hans erik]

Go to field heeft nog wel een functie: je heft de recordlock op. Als de data nog niet gecommit zijn moet je daar natuurlijk apart voor zorgen.

[menno]

"go to field" zonder veld, heft een recordlock (vanaf fp7 bestandsformaat) niet meer op. Je moet echt een commit uitvoeren.

[hans erik]

Klopt.

[peterS]

als je het laat volgen door een stap naar een volgend veld (SetField[VolgendVeld]) of een volgend record, dan is de commit wel direct, toch?

[menno]

"Ga naar volgend veld/Go to next field" slaat de gegevens niet op, je moet dan nog steeds een "commit" uitvoeren.

"Go to next record" slaat de gegevens wél op, mits je "save record changes automatically" in de lay-outinstellingen hebt opgegeven (dat is overigens standaard ingesteld bij het aanmaken van een nieuwe lay-out).

Als je gegevens in een portaal in meerdere portaalrecords wijzigt, worden alle gewijzigde records pas vastgelegd na een commit. Als je gegevens in meerdere portalen in dezelfde lay-out wijzigt, zonder tussendoor te "committen", geldt hetzelfde.

[hans erik]

Een commit is wel automatisch als je een layout sluit.

dus je doet bijv een GTRR in een new window dan een new record, dan Sluit je het window en je record is gecommit.

[Roger]

Dank voor ieders bijdrage. Op zich verhelderend maar het roept nog wel de vraag op, wanneer moét je nu echt een commit doen? Je kunt natuurlijk redeneren dat bij iedere recordwijziging een vastlegging kan plaatsvinden onder het mom van, baat het niet dan schaadt het niet. Maar je wilt je scripts ook niet onnodig lang maken. Een GTRR via een interface-layout o.b.v. globals, al dan niet in een new window, vereist bijvoorbeeld geen commit om het juiste record te tonen. Dus even om het goed te begrijpen, met dit script:

Set (global) field [ INTERFACE::factuur_nr ; FACTUUR::klant_nr ]
Go to Layout [ "Interface" ]
Go to Related Record [ interface_KLANT__klant_nr ; Using layout: "klant" ]

is een commit na de 1e scriptstap niet nodig voor de goede werking. (Ben je het daarmee eens Menno?) Maar is het dan zo dat het INTERFACE record gelockt is en blijft, zodat een andere gebruiker niet ook dit script kan uitvoeren? Volgens mijn test die ik gedaan heb niet. Komt dat door het feit dat het veld in INTERFACE een global is? In mijn test maakt het namelijk zelfs niet uit wanneer je op de ene client actief je cursor in dat veld hebt staan, op de andere client kun je ook dan dit script gewoon draaien.

Om dit helder te krijgen heb ik ter test van INTERFACE::factuur_nr even een non-global veld gemaakt. Werkt het dan nog? Gedeeltelijk, namelijk: zonder actieve commit in het script wordt nog steeds het juiste record getoond. De commit heeft echter op de achtergrond wel plaatsgevonden getuige de andere client waarop te zien is dat INTERFACE::factuur_nr gewijzigd is. Ook op de andere client kan het script probleemloos worden uitgevoerd, behalve als op de eerste client men actief in het veld staat. Want dan krijg je de bekende foutmelding dat dit record gewijzigd wordt door een andere gebruiker.

Ik weet, dit is hele basale materie maar wel belangrijke, in mijn optiek. Nuttige aanvullingen hierop zijn dan ook welkom!

 

 

 

 

 

 

 

 

[menno]

Er vanuit gaand dat

1. de eerste handeling het instellen van een global-field is
2. er verder nog geen niet opgeslagen wijzigingen zijn gedaan

Is er niets gelocked.

1. ga naar layout
2. ga naar gerelateerd record

Er is nog steeds niets gelocked. De volgende handelingen zetten records "op slot": Scriptstap "open record" of "Veld instellen (tenzij het een glogal-field is)" en alles wat daar op lijkt (alles wat gegevens wijzigt)

Je moet de gegevens vastleggen zodra je dat zelf nodig vind of wanneer je klaar bent met bewerken.

Iets dat bijvoorbeeld vaak gebeurt is dat mensen een record in bijvoorbeeld een portaal bewerken en dan in een ander venster iets anders gaan doen. Het openstaande record wordt dan pas opgelagen als ze het betreffende venster sluiten of er naartoe terug gaan en op de een of andere manier het record vastleggen.

Best lastig om hier een goede middenweg te vinden. Sommige gebruikers maken altijd hun werk aan een record af en gaan pas dán iets anders doen. Andere gebruikers zijn zo rommelig, dat ze te allen tijde meerdere records in meerdere vensters open hebben staan en op enig moment lopen zij dan vast.

Zodra je gegevens moet opvragen in een script of een berekening, dan moet het zijn vastgelegd en alleen globals zijn daarvan uitgezonderd. Soms werkt het niet opgeslagen gegeven prima, maar omdat iets lukt of kan, wil nog niet zeggen dat je dan de juiste werkwijze gebruikt. Bij twijfel dus gewoon even opslaan (committen)

Wijzig je gegevens in een portaal en je moet na het opslaan nog iets met zo'n gegeven doen, dan zal je goed op moeten letten. Op de een of andere manier moet je gaan naar de juiste portaalrij of de juiste gegevens al in een variabele hebben gezet om te gebruiken (legio oplossingsmethoden zijn hier mogelijk).

Hoe, wanneer en waarom je een wijziging opslaat is denk ik helemaal afhankelijk van jouw eigen behoefte, maar het opslaan overlaten aan het toeval, lijkt me in elk geval een slecht idee  

[hans erik]

On 4/8/2021 at 11:05 PM, menno said:

"go to field" zonder veld, heft een recordlock (vanaf fp7 bestandsformaat) niet meer op. Je moet echt een commit uitvoeren.

Ehm, ik heb nog even wat gechecked. Ik heb een layout A met een gerelateerd record  (niet in een Portal) en de cursor staat in een veld X, heb net wat tekst ingetypt. Het veld is dus nog geselecteerd, het record dus gelocked en de tekst nog niet gecommit.

In een ander venster run ik een script (in een andere tabel) dat mbv een executeSQL de inhoud van veld X selecteert en displayt. De oude, opgeslagen versie verschijnt. Logisch.

Als ik in layout A buiten het veld klik (wat 'go to field()' ook doet) en ik run in het andere venster de SQL, krijg ik de nieuwe versie. M.a.w. Filemaker voert wel degelijk een commit uit, anders kan ik nooit de nieuwe versie krijgen.

[menno]

8 minutes ago, hans erik said:

Als ik in layout A buiten het veld klik (wat 'go to field()' ook doet) en ik run in het andere venster de SQL, krijg ik de nieuwe versie. M.a.w. Filemaker voert wel degelijk een commit uit, anders kan ik nooit de nieuwe versie krijgen.

Nee buiten een veld klikken is een commit, gebruik nou toch gewoon commit en niet "go to field", dat is niet betrouwbaar (en "old school")