Nogmaals globalen

[Stardust]

Met het gevaar hier voor eeuwig verbannen te worden, wil ik het nogmaals over globalen hebben.

 

Ik heb een bestand waarvan ca dagelijks (slechts één maal per dag) ca 15000 records dienen geëxpoteerd te worden naar excel formaat.

 

Op zich geen probleem, script maken en dit werkt probleemloos, behalve ...

 

Om te vermijden dat men vlug het script zou afbreken, wordt dit toegepast bij het einde van de dag, bij het afsluiten van de database dan wel bij het begin van de dag bij het openen van de database. Alles is geautomatiseerd via het script en bij het opstarten van de desbetreffende database wordt alles netjes doorgezonden per e-mail. Echter de volgende client die de database opent activeert nogmaals dit script en de volgende client verzendt nogmaals de gegevens door.

 

Hiervoor heb ik vroeger een globaal datumveld ingesteld en werd het script pas geactiveerd wanneer de huidige datum (Get(CurrentDate) ) niet in overeenstemming was met dit globale datumveld, bij het einde van het script werd het globale datumveld gewijzigd (SetField) naar de actuele datum en werd dit script dus niet meer geactiveerd bij de volgende client die de database opstart.

 

Jullie raden het al, wanneer dit bestand zich op de server bevindt, werkt de SetField niet meer voor het globale datumveld. Zou misschien een variabel hier van nut kunnen zijn en hoe zit dat met variabelen, vertonen die ook een afwijkend gedrag onder Filemaker Server?

 

Hoe kan ik dit aanpassen, want ik zie dit niet zo zitten d.m.v. een relatie zoals reeds voorgesteld en (met succes) toegepast in een ander globaal draadje van me waarbij grafische containervelden gebruikt werden.

 

Ik wacht zoals steeds met spanning op jullie talrijke adviezen

 

Met vriendelijke groet vanuit een winters Brussel,

 

Danny

[AvD]

Kijk hier eens. Er staat in die tip 156 ook een verwijzing naar twee recentere (238 en 239) die de vergelijking maakt tussen globalen en variabelen. Als je daarna nog uitleg nodig hebt, vraag dan maar.

Bedenk ook nog: een global is er voor de gebruiker, een variabele voor de hele solution.

Wat je nodig hebt is een soort griffier die alle waarden bijhoudt voor iedereen. Dat kan een tabel zijn met één record en met gewone velden (dus niet globally stored) die relationeel zo gelinkt is dat iedereen erbij kan.

Succes!

[Koen Van Hulle]

Eén ding moet je toch een beetje nuanceren.

 

De volgende stelling is totaal fout:

 

Nog een verschilpunt tussen de variabelen en de globals: globals zijn locally stored, dus ze kunnen verschillende waarden bevatten per gebruiker. Variabelen daarentegen behouden hun waarde zoals ze in bijvoorbeeld een script gedefinieerd zijn: die is voor iedereen dezelfde!.

 

Variabelen zijn, zoals globals, ook locally stored en kunnen verschillende waarden bevatten per gebruiker. Als gebruiker A het script nog niet heeft uitgevoerd, dan zal de waarde van de locale variabele leeg zijn, meer zelf de variabele bestaat voor deze gebruiker nog niet. Gebruiker B, die het script wel al heeft uitgevoerd, heeft wel al een waarde.

 

Als een gebruiker de inhoud van een variabele aanpast gedurende zijn sessie, dan zal deze enkel voor deze gebruiker gelden.

 

 

De grote verschillen tussen een global en variabele zijn de volgende:

 

- Je kan geen relaties baseren op variabelen

- Je kan variabelen niet gebruiken als merge field

- Je kan variabelen niet beveiligen.

 

 

 

Koen

[Stardust]

Ondertussen heb ik deze avond verder geknutseld en ja, het werkt. Niet met globals en evenmin met variabelen, maar gewoonweg met Set field (met dank aan Peter in mijn vorige topic over globale problemen icm FM Server).

 

Hier thuis werkt het maar nu nog morgenochtend echt uittesten op de werkvloer.

 

Variabelen zijn, zoals globals, ook locally stored en kunnen verschillende waarden bevatten per gebruiker.

 

Alleszins was ik het veel te ver gaan zoeken, ik kwam er maar niet uit, globaal veld kon niet en m.i. wat nu ook door Koen bevestigd is, zag ik niet in hoe ik een variabele kon gebruiken. Uiteindelijk toen ik op de trein zat zag ik het licht en dankzij de tips van André, Peter en de anderen een tabelletje bijgemaakt in het menu databasebestandje met een veld Today (ik heb gewoon het veld zo genoemd, kwestie van nog wat reacties uit te kunnen lokken). Een relatie gelegd tussen dit tabelletje en de tabel waar het script wordt uitgevoerd.

 

Bij het opstarten van deze laatste tabel gaat het script na of de inhoud van dat veldje Today overeenkomt met de huidige datum, indien neen wordt het script verder afgewerkt met als laatste opdracht via Set Field het veldje Today voorzien van de huidige datum, indien ja, wordt het script gestopt.

 

Het was zo eenvoudig en te bedenken dat ik het altijd veel verder ging zoeken. Globalen en variabelen, niet voor deze oplossing dus

 

Met dank voor de raad en de tips, ik hoop dat ik dit topic als afgesloten kan beschouwen

 

Danny

[AvD]

Eén ding moet je toch een beetje nuanceren.

 

De volgende stelling is totaal fout:

 

Nog een verschilpunt tussen de variabelen en de globals: globals zijn locally stored, dus ze kunnen verschillende waarden bevatten per gebruiker. Variabelen daarentegen behouden hun waarde zoals ze in bijvoorbeeld een script gedefinieerd zijn: die is voor iedereen dezelfde!.

 

Variabelen zijn, zoals globals, ook locally stored en kunnen verschillende waarden bevatten per gebruiker. Als gebruiker A het script nog niet heeft uitgevoerd, dan zal de waarde van de locale variabele leeg zijn, meer zelf de variabele bestaat voor deze gebruiker nog niet. Gebruiker B, die het script wel al heeft uitgevoerd, heeft wel al een waarde.

 

Als een gebruiker de inhoud van een variabele aanpast gedurende zijn sessie, dan zal deze enkel voor deze gebruiker gelden.

 

 

De grote verschillen tussen een global en variabele zijn de volgende:

 

- Je kan geen relaties baseren op variabelen

- Je kan variabelen niet gebruiken als merge field

- Je kan variabelen niet beveiligen.

 

Koen

Dat de stelling "totaal" fout zou zijn, is al in tegenspraak met de aanbeveling om "een beetje" te nuanceren. Toch wil ik die aanbeveling volgen, maar kan ik - hoe graag ook - niet onderschrijven wat je argumenteert. Waarschijnlijk heb ik me wat onduidelijk uitgedrukt. Wat ik bedoelde met "behouden hun waarde" is "behouden hun relatieve waarde", dit wil zeggen, de manier waarop ze gedefinieerd zijn.

Een variabele wordt immers "gedeclareerd", aangemeld aan het systeem. In die declaratie alleen al zit een relatieve definiëring. Relatief omdat de werkelijke waarde van andere factoren kan afhangen. De manier waarop de variabele gedeclareerd is, ligt wel voor iedereen vast, ook al heeft iemand dat script bijvoorbeeld niet gerund. Toch zit die variabele ingebouwd in het systeem. Zeggen dat ze voor die persoon dan niet bestaat, komt er op neer dat je een inrijverbod als niet bestaande beschouwt, omdat je toch nooit in die straat komt.

Ik geef wel graag toe dat de hele discussie puur theoretisch is en van weinig of geen nut "te velde".

[Stardust]

Hier op het 'veld' schijnt het alleszins te werken en dit zonder ook maar enige variabele in zijn globaliteit te gebruiken ... nu nog een oplossing voor het print probleem vinden

 

Met dank, en prettig weekend voor al de Clarify lezers en voor al de Schrijvers!

 

Danny

[Koen Van Hulle]

Helemaal niet met je eens, André. Variabelenamen op zich kunnen zelf variabel en dynamisch zijn en per gebruiker anders zijn.

De manier waarop ze gecreeerd zitten hoeven niet per definitie fixed ingebakken te zitten in een script.

 

Lokale variabelen zijn, zelfs vluchtig en hebben maar even een bestaan, tijdens het uitvoeren van een script en dan zijn ze weer weg.

 

Bewijze is de nieuwe data viewer, die je alle variabelen toont die op dit moment bestaan. Je zal zien dat die lijst per gebruiker grondig kan wijzigen al naar gelang de gebruiker.

 

Er is ook geen routine in FileMaker die bij het opstarten kijkt, welke variabelen je alle wil gaan gebruiken en deze gaat declareren. Een variabele wordt pas gedeclareerd op het moment een "Set Variable" script stap wordt uitgevoerd, of de variabele voor het eerst een waarde krijgt binnen een "Let" functie. Ervoor is ze voor die sessie onbestaande.

 

Ook wordt een waarde van een variabele nooit weggeschreven naar het FileMaker bestand. Ze zal zich enkel in het geheugen van de gebruiker bevinden.

 

 

 

Koen

[Stardust]

Hier op het 'veld' schijnt het alleszins te werken en dit zonder ook maar enige variabele in zijn globaliteit te gebruiken ...

 

Helaas,

 

te vroeg victorie gekraaid ...

 

Nu blijkt het niet te werken, leuk wanneer je medewerkers je op de hoogte houden

 

Dus beginnen we opnieuw ... alleen ik weet het niet zo goed meer ... ik kan geen variabelen noch globalen gebruiken en nochtans is dit het enige dat ik me kan bedenken om mijn probleem op te lossen.

 

Ik vermoed dat ik dit moet laten gebeuren vanuit een lokkal opstartbestand per client maar dan vraag ik me af of de data in het bestand op de server effectief gewijzigd wordt?

 

Concreet, Wanneer de actuele datum niet overeenstemt met het veld 'Activeringsdatum' dient het script Activatie gestart worden.

Dit script doet een export naar een DIF-formaat en verzendt dit bestand naar collega's elders die niet over FM beschikken. Dit script Activatie werkt zoals het hoort! Wat niet werkt is de invulling van het veld 'Activeringsdatum', deze moet bij het beëindigen van het script gewijzigd worden naar de huidige datum [Get(CurrentDate)] zodat de volgende die inlogt in het bestand niet weerom de export en verzending van dit (7 MB grote) dif-bestand doet.

 

Gezien dit automatisch, lees met zo weinig en liefst geen tussenkomst van de gebruikers, dient te gebeuren dacht ik het aan een openingscript te hangen. Bij het openen van het bestand wordt nagegaan of de datum overeenkomt met de huidige datum en zo niet wordt het Activatiescript geactiveerd, indien wel, gebeurt er niets (ExitScript). Zodra we met globale velden kunnen werken, is dit geen enkel probleem maar vanop een FM Server instelling is dit een hemeltergend probleem waar ik maar niet uit raak

 

Danny

[Jeroen Aarts]

Danny, is je enige probleem nu niet dat je de laatste script stap (Set Field waarin je huidige datum wegschrijft) buiten de context van je nieuwe tabel uitvoert.

 

Dat is nog een verschil tussen globale velden en niet-globale velden: globale velden kan je lezen en schrijven out of context, dat lukt niet voor gewone velden. Zie het voorbeeld in bijlage met 2 niet-gerelateerde Tabellen!

 

Indien dit werkelijk het probleem is, los je dit gemakkelijk op door een "Go to layout[...]" script stap in te voeren voor de Set Field script stap

 

gr Jeroen

TestGlobalen.fp7