Gegevens overnemen uit een ander record met lookup

[rmw]

Al zolang als ik FM gebruik komt eens in de zoveel tijd het nut van een lookup met eerst lagere/hogere waarde weer eens boven drijven.

Zo ook nu, maar.....

 

Dat werkt niet in een portal

 

FM is zo slim tegenwoordig om pas bij het vastleggen van het hoofdrecord alle portal records vast te leggen (te comitten)

En tot die tijd is het laatste record bij het starten van muteren de eerst lagere waarde.

Als je dus een datum reeks wilt voortzetten op basis van startdatum en duur, worden alle nieuwe records berekend op basis van de laatst beschikbare bij aanvang van invullen.

Al vul je 100 regels in, ze bestaan niet voor je lookup.

 

En voor dat je daar dan weer achter bent....

 

Ook de scripttrigger OnRecordCommit doet in een portal lekker niks

 

Dat u het maar even weet.

 

rmw

[JeanWM]

FM is zo slim tegenwoordig om pas bij het vastleggen van het hoofdrecord alle portal records vast te leggen

 

Is toch altijd al zo geweest....¡¿

 

Een portal is niks anders dan een layout object dat gerelateerde records kan tonen.

 

FM doet een validatie:

1. Lookup triggered en data wordt gekopieerd

2. Validatie van alle velden in het record

3. Resolve relationships en data on screen krijgt een refresh.

 

Dus is het duidelijk dat de gerelateerde records eerst gecommit moeten worden voor de nieuwe data kan getoond worden.

[rmw]

Dus is het duidelijk dat de gerelateerde records eerst gecommit moeten worden voor de nieuwe data kan getoond worden.

 

Helemaal waar, maar mijn 'tegenwoordig' bestrijkt een redelijke periode

Ik moet toegeven dat ik terug moet naar FM6 om mijn punt te kunnen verduidelijken.

 

Vanaf FM7 is alle gerelateerde info inderdaad pas beschikbaar als het hoofdrecord wordt gecommit.

Daarvoor was een record in een portal gecommit zodra je aan een nieuwe regel begon. En dus kon je ook niet terug, zoals dat nu wel kan.

Maar in sommige gevallen blijkt er toch wel weer wat te zeggen voor die oude manier van werken....

 

rmw

[SuperWimmie]

Klopt helemaal wat je zegt, rmw.

 

Het heeft voordelen maar zeker ook nadelen.

 

Voordeel is het kunnen annuleren van een complete invoerslag, inclusief de portaalregels.

 

Nadeel is dat validatie pas bij opslag plaatsvindt, niet bij invoer van een portaalregel. Zit er een fout in, dan heb je 100 regels vastgelegd en zoek dan maar uit waar de invoervalidatie op vastloopt.

 

Geef mij de oude methode maar van versie 6. Veel stabieler en duidelijker.

De handleiding van Filemaker geeft al aan dat het niet zo consequent is wat er nu gebeurt. "Na het veranderen van record wordt het automatisch opgeslagen".

Portaalregels zijn ook records. De stelling wordt dus geweld aangedaan.

 

De portalen zijn zo onderhand wel een punt van aandacht voor Filemaker.

[rmw]

En om het geheel nog 'doorzichtiger' te maken:

 

Alleen het hoofdrecord activeert de trigger OnRecordCommit en dat slechts 1 keer. Geen enkele van de 100 portaal regels doet dat, ook al zijn het allemaal records en worden ze allemaal gecommit....

 

Ik sluit me geheel aan bij de vorige spreker:

De portalen zijn zo onderhand wel een punt van aandacht voor Filemaker.

 

rmw

[JeanWM]

Portaalregels zijn ook records.

 

Nope, portaalregels tonen data van gerelateerde records maar zijn layoutobjects.

Zoals het hele portaal trouwens.

[SuperWimmie]

Huh?

 

Portaalregels zijn records, maar het zijn geen records omdat het gerelateerde records zijn??

 

't Zal wel iets taalkundigs zijn, maar eenvoudigg gezien lijken het mij records

 

Presentatietechniek mag je in deze discussie ook weer niet helemaal los zien van de gegevens, naar mijn mening.

Zo kan je ook een muteerbaar veld maken die gebaseerd is op een gerelateerd veld. Zonder portaal. Evenzo slaat hij die ook niet op, omdat de gebruiker dan de belevenis heeft van 1 record...

En dat ervaren we wel als logisch...

[JeanWM]

 

Portaalregels zijn records, maar het zijn geen records omdat het gerelateerde records zijn??

 

 

Portalen zijn layoutobjecten.

 

Vermits portalen steunen op relaties, maakt niet uit welke vorm van relatie, tonen ze data van gerelateerde records.

 

Tonen. Meer niet.

 

Een portaalregel is een layoutobject dat data toont van een gerelateerd record.

[SuperWimmie]

Los van of de stelling juist is (elk veld is een layout object), feit is dat ik de huidige werking niet handig vind.

Sinds versie 7 knap lastiger zelfs. Ook in scripts.

 

Maar omdat ik IWP gebruik, merk ik dat voor deze doeleinden het ineens wel logischer werkt. Opslag achteraf, na verwerking van een compleet scherm... is toch iets anders dan interactieve invoer van gegevens. Filemaker is in de mix gegaan, helaas niet zonder gevolgen.