Heropfrissen relatie & Date Last Modified

[Gido_]

Je ziet regelmatig bv set ID=ID om de relatie op te frissen.

 

Nu verlies je daardoor wel de functie van Date Last Modified...

 

Je kan misschien eerst dat veld even wegschrijven en dan terughalen[?]

 

Maar:

 

1) Het is wellicht eender aan welke kant v/d relatie je heropfrist? (zo kan je dan toch op één plaats je last modified functionaliteit behouden)

 

2) Het lijkt me ook dat dit soort set ID=ID vervangen kan worden door een Refresh Window of Commit Record?

 

Het zou sowieso mooi zijn als je in de velddefinitie kon bepalen of dat veld de Last Modified datum zou beïnvloeden of niet.

[Gido_]

Oeps, ik dacht dat ik hiermee volop problemen had, maar dat blijkt toch goed te gaan

 

Nochtans heb ik zo'n set ID=ID dingetjes, maar als er niks veranderd werd blijkt hij het (logischerwijze) niet te registreren als modified. Ik had eerst nochtans sterk wel die indruk, maar goed

 

Zo'n veldoptie zou nog altijd mooi zijn, want als je bv een checkmark even op (en af) zet heb je wel prijs, terwijl dat dikwijls van geen belang is.

[Rony Rabijns]

... want als je bv een checkmark even op (en af) zet heb je wel prijs, terwijl dat dikwijls van geen belang is.

Dat is jouw persoonlijke interpretatie dat het van geen belang is geweest om even te checken en unchecken.

Maar volgens de definitie van Modification Date is er wel een wijziging geweest en wordt dat veld dus getriggerd.

 

Om een aantal van deze "nul-operaties" kort te sluiten, kan je bijvoorbeeld een datumveld maken dat enkel getriggerd wordt indien veld x of veld y of veld z gewijzigd wordt. Dit alles in de veronderstelling dat die checkbox van hierboven niet toevallig één van die 3 velden is ...

[Gido_]

 

Er stond "dikwijls", dus daar kan ik alle kanten mee op En ja, mijn interpretatie is dat mensen graag op knopjes klikken en met aan/af switches spelen Indien dat er onbelangrijke zijn, dan is dat spijtig dat dat "gevolg heeft".

Zo kan je bv een aantal artikels markeren om achter mekaar in een mail te laten zetten voor iemand, maar als je niks aan de tekst hebt veranderd is het voor mij wat stom dat dit een modified tot gevolg heeft (enz, enz). De "professionele vbn" zijn natuurlijk veel indrukwekkender, dat begrijp ik

[Peter Wagemans]

De "Refresh Window" script stap heeft een (nieuw sinds 7) "Flush cached join results" aankruisvakje. Dat lost heel veel van dit soort problemen op.

[Gido_]

Om een aantal van deze "nul-operaties" kort te sluiten, kan je bijvoorbeeld een datumveld maken dat enkel getriggerd wordt indien veld x of veld y of veld z gewijzigd wordt. Dit alles in de veronderstelling dat die checkbox van hierboven niet toevallig één van die 3 velden is ...

Ik denk dat ik hem heb

Ik versta dat het zou moeten werken met een calculated auto-enterveld. Elk veld waarnaar je in je calculatie refereert zal dan een herberekening/Get(CurrentDate) kunnen doen triggeren (als het vinkje eronder afstaat).

Je kan er gelijk een anti-Big Brother pref inlassen voor gebruikers die niet van tracking houden

 

Maar... Wat zijn de meest onzinnige/snelste "veldreferenties" hiervoor?

[Gido_]

Case(AllowBigBrother=yes and not IsEmpty(veld1) or not IsEmpty(veld2); Get (CurrentTime); "")

 

Deze werkt mooi. Heb ik behoefte aan een snellere functie dan een aantal "or not IsEmpties" achter mekaar?

 

En was een Case ook weer sneller dan een If...?

[Rony Rabijns]

Ik zou gaan voor deze oplossing (zie bijlage).

 

Trigger (text, auto-enter calculatie)

Case(
Left(Veld_A & Veld_B;0) = "" ;
Timestamp ( Get(CurrentDate) ; Get(CurrentTime) );
Trigger
)

Triggering.fp7.zip

[Gido_]

Qua onzinnigheid kan hij inderdaad tellen "Ik ga ervoor"

 

Het is trouwens niet fijn om mijn vragen in je database "Onwaarschijnlijke Superbeginnelingen" opgenomen te zien worden

[Gido_]

Die is wel niet zo slim als FM om te merken dat je in een veld net hetzelfde hebt ingetikt en dus in wezen niets gemodified hebt.

Maar heel veel was ik dat toch niet van plan te doen

[rmw]

Dit is ook nog wel een leuke:

 

Evaluate heeft de mogelijkheid om aan te geven dat hij iets moet doen op basis van bepaalde velden.

 

Als je de code van het Trigger veld uit de oplossing van Rony vervangt door dit

Evaluate ( "get ( currenttimestamp )" ; [ Veld_A ; Veld_B ] )

dan doet ie hetzelfde.

 

Voor mij heeft dit als voordeel dat er niets wordt ingevuld als er gewijzigd wordt in velden die niet gecontroleerd worden (in plaats van zichzelf uit de Case van hierboven).

 

rmw

[Rony Rabijns]

Voor mij heeft dit als voordeel dat er niets wordt ingevuld als er gewijzigd wordt in velden die niet gecontroleerd worden (in plaats van zichzelf uit de Case van hierboven).

Het veld Trigger zet ik in de Case() om te vermijden dat wat er ingevuld is in het veld zou verdwijnen wanneer de Case()-voorwaarde niet voldaan wordt.

 

Het is één van de zandzakjes die ik hier en daar neerleg