Jump to content
  • 0

Gegevens overnemen uit een ander record met lookup


rmw

Question

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 :twisted:

 

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.... :evil:

 

Ook de scripttrigger OnRecordCommit doet in een portal lekker niks :cry:

 

Dat u het maar even weet.

 

rmw

Link to comment

8 answers to this question

Recommended Posts

  • 0

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.

Link to comment
  • 0
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 :wink:

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

Link to comment
  • 0

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.

Link to comment
  • 0

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

Link to comment
  • 0

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 :D

 

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...

Link to comment
  • 0

 

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.

Link to comment
  • 0

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.

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...