menno

Ja FMS heeft hetzelfde probleem. Mijn FMS-monitor gebruikt Quote() inderdaad nogal kwistig, maar voor zover ik heb kunnen zien doet alles het gewoon. Het grootste probleem treedt op wanneer de combi Char(10) & Char(13), wordt gebruikt/gmaakt zoals bij base64encode() Ik zou echter toch wachten op 19.5.2, want er staan nog een paar andere fixes op de rol die daarmee óók worden opgelost. Bijvoorbeeld: importeer maar eens een custom-function met 19.5.1, ik hoop dat die met 19.5.2 wordt opgelost. Dus dat is al 3 major bugs

Er is nog een ernstiger bugje: de Quote-functie is gewijzigd. Nou denk je misschien, dat die functie niet belangrijk is of nooit wordt gebruikt, maar dat klopt helaas niet. Ik gebruik deze functie heel vaak (middels een CF, dus indirect) om gegevens in variabelen te stoppen. Eerst even de bug: De Quote-functie zet tekst in dubbele aanhalingtekens en "escaped" tekens die daarbij voor problemen zorgen, zoals bijvoorbeeld aanhalingekens door daar een backslash ( \ ) voor te zetten. Op een later moment pak je die waarden weer op door de te evalueren met Evaluate() of door de gecreëerde variabele uit te lezen. Je verwacht dan dat de tekstwaarde exact overeenkomt met datgene dat je er in hebt gestopt. Lijkt logish toch? Helaas geldt dat niet voor CRLF (ook wel Char(10) & Char(13)), want daar wordt na omzetten met Quote() en weer terug met Evaluate() LFLF van gemaakt. Als je bijvoorbeeld met documenten en base64 encoderen bezig bent, zoals bij het maken van een mime-file om e-mail met html-encodering te versturen, dan wordt met "Base64Encode ( Container )" de binairy omgezet naar de RFC5322 conforme waarde van een base64-string met elk maximaal 80 characters, waarvan de laatste 2 CR en LF zijn. Stop je die nu in een script-result die je vervolgens in een ander script uitleest, dan klopt de inhoud van je bericht niet meer en bij versturen mislukt het plaatsen van de inhoud. Ter illustratie kan je de volgende formule even proberen: Let ( [ base64data = Base64Encode ( Container ) ] ; base64data = Evaluate ( Quote ( base64data ) ) ) Alle versies t/m 19.4.1 geven als resultaat een 1 ...... 19.5.1 geeft een 0 In de Claris Community zijn er diverse topics aan de gewijzigde Quote-functie gewijd. E.e.a. heeft ertoe geleid dat Claris nu versie 19.5.2 snel wil uitrollen. Zij hebben iets anders willen fixen met deze aanpassing (gaat over het opslaan van een veld met tekst voor een add-on. Dit staat in de ETS lijst, dus ik kan daar helaas geen link naartoe maken), maar hebben daar nogal wat toepassingen mee gecompromiteerd. Hoe dan ook: mocht je dezelfde soort technieken gebruiken als ik, dus gebruikmaken van Quote(), voor het maken/rondsturen/uitlezen van variabelen met tekst, waar ¶, base64 etc in voorkomt, dan zou ik 19.5.1 even voorbij laten gaan.

Als je bijvoorbeeld dynamische datasources gebruikt, dan kan je daar in een lus gebruik van maken ipv voor iedere datasource een apart script te maken of te starten.

Afgelopen Donderdag (16 juni 2022) heeft Claris versie 19.5 officieel uitgebracht. Zie de releasenotes voor Pro: https://support.claris.com/s/answerview?anum=000035899&language=en_US en voor Server: https://support.claris.com/s/answerview?anum=000035900&language=en_US Is dit een belangrijke versie? Ik denk het wél, want er zijn flink wat wijzigingen en verbeteringen aangebracht. Sommige vernieuwingen zullen je niet aanspreken, sommige anderen wél en sommige zullen je mogelijk minder bevallen. Op het blog van Soliant kan je een uitgebreidere beschrijving vinden van alle nieuwigheden, met nog enkele "under the hood" aanpassingen die je misschien niet meteen opvallen in de releasenotes van Claris. Enkele verbeteringen die mij persoonlijk opvielen: oData is nu óók op Windows- en MacOS-servers beschikbaar. Zie: https://help.claris.com/en/odata-guide/content/index.html . Met oData kan je bijvoorbeeld direct op een fmserver webhooks gaan aanbieden, zonder dat je nog tussenserver met Node-RED oid nodig hebt. De bug van de wegvallende lijnnummers in de script-editor én in de script-debugger is opgelost De FMServer-script-engine heeft een 4x zo grote cache, waardoor script-schedules (soms) soepeler gaan verlopen De backups kunnen nu parallel worden gemaakt, dat laat het backup-proces op servers met SSD's aanzienlijk sneller verlopen De aantallen in de recordslider heeft nu scheidingstekens in de duizendtallen, daardoor is het een stuk beter leesbaar Een bug in de Get(UUIDnumber) functie is opgelost, waardoor er geen duplicaten meer kunnen onstaan Resumé's worden nu op de server berekend (maar dat kan je uitschakelen, zie de blog van Soliant) Een feature die door veel mensen is gevraagd, maar in de ETS-fase is teruggetrokken is PSoS form server. In een notedop: je kan vanuit een script dat op server draait een nieuwe thread starten, m.a.w. script-on-server is als een aparte client en een nieuwe thread is dan nog eens een nieuwe client en dus is het aan apart proces. Onderhuids is de feature nog wél aanwezig en via de link hiervoor kan je zien hoe je dat kunt activeren.

Maar een nieuwe Meetup organiseren is wél een goed idee! De dotfmp is net geweest en die was heel leuk, daar kunnen we het over hebben en vandaag is 19.5.1 officiëel uitgebracht en daar kunnen we natuurlijk ook uitgereid bij stilstaan @hans erik / @Peter Kr hebben jullie zicht op een datum?

Het bericht van Peter is over 12 dagen 1 jaar oud .... 🤪

@Leen Bijgevoegd bestandje bevat één script en je kan het in jouw "menu-bestand" plaatsen. Het enige wat je dan nog moet doen is username, password en filename vullen (filename moet de volledige bestandsnaam, dus mét extensie) Script is een gestripte versie van mijn voorbeeld waar @Marsau het in zijn reactie over heeft. CountUsers.fmp12

De labels staan in een aparte tabel met global-fields, voor elk label is er een apart veld met de naam van het label. De tabel heet bij mij simpelweg "Labels", maar in de relatie-grafiek noem ik deze "L" omdat die naam lekker kort is . Bij het opstarten vul ik met een scriptje en de ingesteld taal alle global-fields met de vertaling van het label. Omdat deze velden globaal zijn blijven ze hun waarde tonen in elke modus van het bestand. Een relatie naar de table-occurrence "L" is hier nooit nodig, omdat alle velden globals zijn. Je kan de table-occurrece "L" dus in ieder bestand van het database-systeem opnemen en de (vertaalde) labels zo overal gebruiken. Op mijn site https://www.filemakertips.nl het ik in 2015 een artikel geplaatst over dit onderwerp: https://www.filemakertips.nl/meertalig-systeem/ met een voorbeeldbestand om te downloaden

Dat ligt aan de definitie die je hanteert, Get ( CurrentTimeUTCMilliseconds ) is het aantal verstreken milliseconden (getal) sinds "01-01-0001 0:00:00,0", dus als zodanig is het inderdaad een (verstreken) tijd. FileMaker slaat tijdstempels, data (datums in Nieuwspraak) en tijden intern op als getallen en daarom kan je de UTC gemakkelijk als tijdstempel, datum of tijd noteren: Let ( [ UTC = get ( CurrentTimeUTCMilliseconds ) ] ; List ( GetAsTimestamp ( UTC / 1000 ) ; GetAsDate ( Floor ( UTC / 86400000 ) ) ; GetAsTime ( UTC / 1000 ) ) )

Mijn CF berekent de DST zoals deze nu in het grootste deel van de EU wordt gebruikt. Je zou mijn CF dus eigenlijk moeten uitbreiden met een stukje waarmee je DST uitschakelt. Verder is de opmerking van Banach óók zeer terecht. Wanneer je slechts één FMServer gebruikt is dat de meest eenvoudige manier om allemaal van dezelfde absolute tijd gebruik te maken Dat verandert helaas als je meerdere servers gebruikt en ze met alkaar gaat laten 'praten'. UTC vanuit FM(server) is dan ook niet betrouwbaar, omdat het voor veel systeembeheerders erg moeilijk is om de juiste tijd en tijdzone op een server in te stellen. Ze synchroniseren dan wel via NTP, maar als de basisinstellingen niet kloppen, krijg je toch een heel riedeltje problemen. Voorbeeld: je hebt een host voor je virtuele machines, die heeft ook een tijdzone. De VM's zijn verschillende smaken Windows en Linux én ook nog eens op verschillende locaties en door verschilende personen op verschilllende werkstations aangemaakt en geconfigureerd. Het is een extreem voorbeeld, maar ik heb het aan de hand gehad en de tijdsverschillen zijn erg niet van de lucht en erg lastig op te lossen. Je moet echt alles doorlopen om de zaak synchroon te krijgen

Ja, dit was een zeer leuke dotfmp! De sessies waren natuurlijk hartstikke interessant, maar vooral het ontmoeten van zoveel verschillende ontwikkelaars uit zoveel verschillende landen is mij de beste ervaring geweest. Mensen zoals Claus, Fabrice, Jijzelf, Christian, Russel, Otmar, Egbert etc. die allemaal flink actief zijn op diverse websites wereldwijd, allemaal tegelijk op één bijeenkomst en waarmee je kan overleggen en/of een Pint drinken is mij erg goed bevallen! Volgend jaar wil ik er wéér bij zijn!

Als je de "advanced tools" hebt aangevinkt, dan kan je ook de DataBase Design Report laten maken: https://help.claris.com/nl/pro-help/content/documenting-schemas.html Daarin kan je precies nagaan waar alle scripts, layouts, table-occurrences en velden worden gebruikt.

Gefeliciteerd! En nog steeds is deze website een vraagbaak voor heel veel ontwikkelaars en aficionados! Erg leuk!

Nou ja uh, dat zou dan alleen nodig zijn voor het aanmaken van een totaal nieuw bestand en dat doe ik eigenlijk niet dagelijks, zelfs niet wekelijks. Er zijn m.i. wel zaken die belangrijker zijn, zoals de scriptregelnummer die iedere keer wegvalt het écht kunnen afbreken van een zoekopdracht een betere interface voor de security extern geauthenticeerde accounts per script kunnen toevoegen de schedules in fmserver kunnen sorteren etc. etc. Allemaal zaken die ook half af zijn en waar je wél dagelijks tegenaan loopt

"Het" standaard thema van FileMaker kan je niet wijzigen, maar wél je eigen werkwijze. Zodra je een bestand aanmaakt kan je voor de allereerste lay-out een thema kiezen (of importeren). Daarna wordt bij de aanmaak van iedere nieuwe lay-out het thema van de lay-out die op dat moment actief is gebruikt. M.a.w. na aanmaak van een bestand is de eerste stap die je moet uitvoeren: het thema wijzigen ..... Het zou wel ideaal zijn als je net als met de DefaultFields.xml een DefaultThemes.xml zou kunnen maken, met daarin alleen de Themes die je wilt gebruiken én met je standaard-theme ingesteld