Global field in gehoste database

[Mike]

In een netwerkomgeving gebruik ik FM server en FM pro voor het hosten van wat bestanden. Mij viel op dat als er een waarde wordt opgeslagen in een globaal veld deze waarde niet wordt opgeslagen in de originele gehoste database (m.a.w. client A ziet de waarde in GlobalA niet die door client B daar wordt ingevuld). Meestal is dat natuurlijk ook de bedoeling. Maar hoe kan ik er voor zorgen dat in bepaalde gevallen via een client wel een nieuwe globale waarde kan worden ingesteld die voor alle clients geldt? Bedoeling is om op deze wijze settings te kunnen instellen zonder separaat settingsbestand.

[Rony Rabijns]

die waarde wordt wel degelijk opgeslagen in de database, maar globals zijn eigen aan de gebruiker. Ttz, de host kan globals definitief wijzigen, gebruikers hebben de "macht" over de globals zolang ze de bestanden geopend hebben. Eigenlijk wil dit dus zeggen dat een global op hetzelfde ogenblik verschillende waardes kan hebben, namelijk zoveel als er gebruikers ingelogd zijn op de database.

 

De volgende keer dat een gebruiker inlogt krijgen de globals terug de waardes zoals ze ingesteld werden door de host.

In het geval van FM SERVER is dat de host. Wil je dan de globals wijzigen, moet je de server quitten, bestanden openen met een client-versie van FM, globals instellen, bestanden sluiten, server terug opstarten.

[Sanne]

Wil je dan de globals wijzigen, moet je de server quitten, bestanden openen met een client-versie van FM, globals instellen, bestanden sluiten, server terug opstarten.

 

Er is ook een andere methode: als je een gehoste database opent (dus de database die onder de server geopend is), naar definieer velden gaat (je moet dan de enige gebruiker zijn en met versie 5 of hoger werken) en aldaar een wijziging aanbrengt zodanig dat de velden opnieuw gedefinieerd worden, dan wijzigen de globals PERMANENT en voor IEDEREEN vanaf dat moment.

Aldus is - meen ik - zeer helder gedemonstreerd op de 2e Clarify Confrituursessie ...

 

Ik weet niet of het een bug of undocumented feature is, maar het is bepaald iets om rekening mee te houden als je als ontwikkelaar op die manier bezig bent.

 

Voor Mike: je zult het met een settingbestand moeten oplossen (en dat weet je vast wel: 1-1-permanente-relatie en 1 record). Wat is je bezwaar daartegen?

[Rony Rabijns]

Wil je dan de globals wijzigen, moet je de server quitten, bestanden openen met een client-versie van FM, globals instellen, bestanden sluiten, server terug opstarten.

 

Er is ook een andere methode: als je een gehoste database opent (dus de database die onder de server geopend is), naar definieer velden gaat (je moet dan de enige gebruiker zijn en met versie 5 of hoger werken) en aldaar een wijziging aanbrengt zodanig dat de velden opnieuw gedefinieerd worden, dan wijzigen de globals PERMANENT en voor IEDEREEN vanaf dat moment.

Aldus is - meen ik - zeer helder gedemonstreerd op de 2e Clarify Confrituursessie ...

 

Ik weet niet of het een bug of undocumented feature is, maar het is bepaald iets om rekening mee te houden als je als ontwikkelaar op die manier bezig bent.

 

ik doe het zelf ook soms op die manier, omdat ik weet wat ik aan het doen ben. maar ik wil mijn eindgebruikers weghouden uit definieer-velden! daar kan teveel verkeerd gaan. vandaar de recht-toe-recht-aan-oplossing die ik Mike (er stond Wief, mea culpa) voorstelde. met die methode kan relatief weinig fout gaan.

Edited February 20, 2004 by Guest

[Sanne]

Het duizelt je een beetje, Rony? Dit is de vraag van Mike, die van Wief gaat over wielrennen, wat je weer niet moet verwarren met de fietsen van Frank ...

[Rony Rabijns]

Het duizelt je een beetje, Rony? Dit is de vraag van Mike, die van Wief gaat over wielrennen, wat je weer niet moet verwarren met de fietsen van Frank ...

Ik heb een paar erg vermoeiende weken achter de rug en dan krijg je van die dingen natuurlijk. Ik kan misschien beter op de bank gaan zitten bij vrouwlief ... voor er straks verkeerde antwoorden bij verkeerde vragen staan, of erger nog, verkeerde antwoorden bij juiste vragen.

[Sanne]

ik doe het zelf ook soms op die manier, omdat ik weet wat ik aan het doen ben.

 

Ja, dat denk ik ook altijd

 

Maar dan hebben we weer een mooi een-tweetje gemaakt, Rony.

[Frank ter Braak]

Ik heb de indruk dat de methode van Sanne niet altijd goed werkt.

Nu is die ervaring o.a. gebaseerd op een "HerhalendGlobalContainer" veld en die verloor telkens op bv positie 5, 6, 8, 13, 14, 17 enz zijn waarde ook als ik tussendoor "Define Fields" opende -even iets deed of een definietsie opende- en weer sloot.

Ik heb de indruk dat een "HerhalendGlobalContainer" veld zowiezo onbetrouwbaar is en ik gebruik nu een "GlobalContaner" die zijn waarde haalt uit een "HerhalendeContainer" en dan gaat het wel goed.

 

Ook heb ik een "OneRecordFile" waar ik een "soort global" velden heb die juist waarden moeten opslaan die voor iedereen gelijk moeten zijn.

 

Eigenlijk zou je bij een Global veld moeten kunnen aanvinken of de waarde:

O per gebruiker eigen

of

O voor alle gebruiker gelijk

zou moeten zijn. Of maak ik een denkfout? Het is toch idioot dat ik een apart bestand moet maken voor een functie die gewoon in het veld zelf zou kunnen zitten.

[AvD]

De Tip over de globals was gepland voor volgende maand, maar hij stond al klaar:

http://www.avd-ci.be/tip156.htm. Ik denk niet dat er iets in staat wat hierboven nog niet is gezegd. Maar ja, dit is Clarify natuurlijk, hier weten ze alles!

[Sanne]

Ik heb de indruk dat de methode van Sanne niet altijd goed werkt.

 

Laat ik even duidelijk zijn met mijn mening over "mijn methode": ik denk dat het een slechte manier is om globalen in een multi-user omgeving via de definieer-velden-"bug" in te stellen!

 

Het is ongedocumenteerd gedrag en het lijkt daarom meer op een bug dan op een feature. Ik vind het ook ongepast gedrag: globalen in FileMaker zijn lokale variabelen, en horen helemaal niet te wijzigen als ik Definieer Velden heb gebruikt!

 

Het is ook niet dat ik deze methode propagandeer: ik denk dat hij zeer onbetrouwbaar is.

 

Maar ik denk wel dat programmeurs op de hoogte moeten zijn van dit gedrag, dat is de reden waarom ik de methode noem als een manier waarop globalen in een gehoste database permanent en voor alle gebruikers van waarde kan veranderen.

 

Het volstaat de enige gebruiker van het bestand te zijn en dan de waarde te wijzigen. De beste methode om dat te bereiken is het openen van Define Fields: dat kan enkel als er niemand anders ingelogd is op het systeem.

 

AvD: Het is niet waar dat wanneer je een gehoste global wijzigt als enige gebruiker, dat de waarde dan voor iedereen gewijzigd is. Dat is alleen wanneer die enige gebruiker *daarna* Definieer Velden heeft geopend *EN* daar een verandering heeft aangebracht waardoor het definieren getriggerd wordt. Je ziet, het zijn nogal duistere omstandigheden.

 

Ik denk niet dat je in je tip de manier moet noemen als "de beste methode". De beste methode om een gehoste global te veranderen is de methode zoals beschreven: sluiten-wijzigen-openen. Als je al iets wilt doen in je tip, dan is het mensen waarschuwen voor dit gedrag!

[Theo2]

Voor Mike: je zult het met een settingbestand moeten oplossen (en dat weet je vast wel: 1-1-permanente-relatie en 1 record). Wat is je bezwaar daartegen?

 

In mijn applicaties neem ik altijd het bestand Settings.fp5 op. Hierin staan alle "constanten" van de applicatie zoals bv bedrijfsnaam en adres en ALLE globale velden van de gehele applicatie. Daarnaast neem ik er "Globale" scripts - scripts die universeel werken - in op. Voordelen: 1) je zult sneller een zogenaamde constante opnemen in een veld in Settings. Immers de ervaring leert dat je vaste teksten en getallen niet velddefinities, scripts, layouts etc. moet opnemen vanwege de problemen meyt onderhoud. 2) Je hoeft niet na te denken waar je een globaal veld moet laten of terugvinden. 3) Als je de applicatie bij meerdere afnemers distribueert kan je Settings.fp5 gebruiken om de applicatie te lokaliseren dwz geschikt te maken voor een specifieke gebruiker.

[Rony Rabijns]

Voor Mike: je zult het met een settingbestand moeten oplossen (en dat weet je vast wel: 1-1-permanente-relatie en 1 record). Wat is je bezwaar daartegen?

 

In mijn applicaties neem ik altijd het bestand Settings.fp5 op. Hierin staan alle "constanten" van de applicatie zoals bv bedrijfsnaam en adres en ALLE globale velden van de gehele applicatie.

Theo, ik doe juist hetzelfde, maar soms geraak je er dan nog niet.

 

Even terzijde om dit te illustreren :

Ik heb bvb een tweetalige applikatie draaien waarbij alle vertalingen van de buttons in globalen steken. Soms moet daar eens een vertaling gewijzigd worden, en dan zou ik met een settings-bestandje vastlopen. Want in mijn settingsbestandje staat dan wel de juiste vertaling, maar bij de andere gebruikers niet meer ...

[AvD]

Sanne is misschien wat te snel wanneer ze zegt dat iets niet waar is, dat het ongedocumenteerd is, en dus meer weg heeft van een bug. We kunnen inzake de globals zoveel gissen en vermoeden als we willen, zelfs tot welles - nietes overgaan. De AVD-Tip waarover Sanne het heeft hierboven is gebaseerd op een schriftelijk advies van Marcel de Maria van FileMaker Inc. zelf. Het is dus niet ongedocumenteerd, evenmin unexpected behaviour, en evenmin onbetrouwbaar:

In FileMaker Pro 5.0v3 only and FileMaker Pro 5.5 if you have full access privileges and are the sole guest of a database hosted from FileMaker Server, you can make changes to the value in a global field and then save the changes by immediately accessing the Define Fields dialog box directly from the guest machine. The new value in the global field along with any text formatting will be saved in the hosted file.

 

Note: This will not work with a global field of type container.

 

You don't have to close the database in FileMaker Server and reopen it locally in FileMaker Pro to make the changes.

 

Sanne heeft wel gelijk als ze tot voorzichtigheid aanmaant, maar dat is dan enkel voor degenen die vandaag nog met een versie werken lager dan 5.0 v3.

 

In verband met de globals is er echter een andere vraag: "Kan je een record lock veroorzaken als je met twee users tegelijk een SetField uitvoert op één en dezelfde global in een single record file?".

Edited February 22, 2004 by Guest

[Theo2]

In verband met de globals is er echter een andere vraag: "Kan je een record lock veroorzaken als je met twee users tegelijk een SetField uitvoert op één en dezelfde global in een single record file?".

 

Nee.

 

Dit omdat een Global alleen kan worden gewijzigd als je Single User werkt, zoals hiervoor al is uitgelegd. Een global wordt alleen gelezen uit het bestand en de eventuele wijziging wordt bewaard op de computer van de gebruiker. Je kunt met Define Fields ook nooit in een record lock geraken!

[AvD]

Dank, Theo. Over Define Fields was in mijn vraag evenwel geen sprake. Ik probeer een trouble shooting te doen op een urenregistratiesysteem met vijftien gebruikers waar af en toe de melding "User X is modifying this record" opduikt, terwijl elke user zijn eigen records heeft, en het dus enkel kan liggen aan het wijzigen van een global. Ik probeer het straks zelf nog eens uit en houd jullie op de hoogte.

Maar misschien zie ik iets over het hoofd en heeft er iemand een andere verklaring voor die record lock?

[Sanne]

Sanne is misschien wat te snel wanneer ze zegt dat iets niet waar is, dat het ongedocumenteerd is, en dus meer weg heeft van een bug ... schriftelijk advies van Marcel de Maria van FileMaker Inc.

 

I stand corrected en ga maar weer mijn stille hoekje in. Maar blijf bij mijn meninkje dat ik het onterecht gedrag vind. Snik.

 

Dankjewel AvD!

[AvD]

Nee, Sanne, niet in het hoekje. We hebben je teveel nodig. Dat bleek trouwens ook op vorige confituursessie. En ik geef toe dat ik misschien ook te snel ben geweest met te zeggen dat het wél documented was. Ik heb geen tijd om het overal na te trekken, maar ik geloof NIET dat het in de handleiding of de online help staat. Waarschijnlijk wel in de TechInfo Database en die is toch vri j toegankelijk, of vergis ik me?

Maar blijf bij mijn meninkje dat ik het onterecht gedrag vind.

Ik probeer het uit te leggen. De engine die zorgt voor de global fields is om allerlei redenen mee ingebouwd in de algemene field engine. Die is voor ons als gebruikers enkel toegankelijk via de optie Define Fields. Het vastleggen van globals moet dus langs daar gebeuren. Dat kan niet anders. Op het ogenblik dat je als developer een global creëert, heeft dat veld uiteraard géén inhoud, geen value. Je kan het zo laten. Wanneer je dan je werk - dit wil zeggen: "Define Fields" - afsluit, dan gaat die global leeg de gebruikerswereld in. Een user kan dan via Browse naar dat veld gaan (of eventueel via SetField of Paste en dergelijke vanuit een script) om een waarde toe te kennen aan die global. Die waarde is dan locally stored. Als je FileMaker desinstalleert van zo'n computer, dan is die waarde definitief weg, ook als je daarna FileMaker terug installeert. De FileMaker developers (dus niet wij, maar zij) hebben het ook nuttig geacht de mogelijkheid te voorzien om aan zo'n global een waarde toe te kennen die default beschikbaar is voor alle users, met dien verstande dat ze die waarde daarna zelf kunnen wijzigen, maar dat ze bij elke nieuwe FileMaker sessie terug de default-waarde krijgen. Daarvoor was een optie nodig om aan die global een value toe te kennen. Dat kan natuurlijk enkel in Browse. Om die waarde definitief te saven IN DE HOST-versie - zou dan een speciale button of optie nodig geweest zijn. Dat was te gek, natuurlijk. Die save-optie zat immers al ingebouwd in de Done-button waarmee je Define Fields afsluit. Daarom dat je dus even via Define Fields moet om die waarde te saven. Dat is dus geen bug of unexpected behaviour, maar de meest elegante oplossing voor het probleem. Als zo'n bespreking afgesloten wordt met "OK jongens, zo doen we het dus. Jullie zorgen ervoor, en zet het ook in de online help, OK?", dan kunnen we alleen maar hopen dat die kerel dat meteen opschrijft en dat hij er enkele dagen later nog aan denkt ook. Doet hij dat niet, dan staan wij een jaar later voor een "undocumented feature". Het ergste is dat ze het soms zelf niet meer weten en dan een bug enquiry opstarten voor iets dat ze zelf zo gemaakt hebben. En wij maar klagen dat we na enkele maanden niet meer weten waarom we in een script iets zus of zo gedaan hebben...

 

PS Sanne, ik ga de tip wel aanpassen, want de optie waar we het nu de hele tijd over hebben, is pas ingevoerd in versie 3 van 5.0.

[Mike]

Bedankt voor de reacties. Heb nu zekerheid over de werking van globals en zie eens te meer het nut in van een settingsbestand.