Marsau

Dat gaat de registratie van de fout niet afvangen. Elke scriptfout wordt geregistreerd en dat is in principe een heel goed uitgangspunt.

Ik hanteer als ontwikkelprincipe dat fouten als 401 en 101 gewoon niet op de server gemaakt worden. Dus alleen de echte fouten in de logs. Als je weet waar ze kunnen ontstaan kan je ze gemakkelijk afvangen. Bij beperken van gevonden sets misschien iets dieper nadenken.

Dank Menno, ik heb dit helaas niet werkend gekregen. Voor nu in de betreffende omgeving teruggerold naar 19.4.2. Jammer!

Is er een workaround denkbaar? (en dan niet downgraden naar 19.4)

Interessant! Waarop gebruik je deze VM? Ik onderzoek nog steeds de mogelijkheid om een FMS op een NAS te draaien, als goedkoop alternatief van een gehuurde VPS-en.

Dank voor de tip! Deze bugs doen vermoeden dat de applicatie op een aantal punten grondig herschreven is...

Dank Menno. Denk je dat deze bug zich ook in de script engine onder FMS 19.5 voordoet? Jouw FMS-monitor gebruikt de Quote-functie ook rijkelijk. Het zou voor mij een reden zijn om die servers niet naar 19.5 te updaten.

Variabele body hoogte creëren is precies de oplossing die Banach aangeeft. Het is alleen zichtbaar in de afdrukmodus, of in print. Kan je wellicht je probleem opnieuw beschrijven?

Dank voor de samenvatting. Overigens PoS binnen PoS: wat is de use-case daarvoor? (Het lijkt een goede manier om je server plat te leggen)

Oeps, sorry!

Aanvullende opmerking wat betreft local sharing. Ik redeneer verder op mijn eigen uitspraak: Omdat de lokale FMPs een zelfstandige licentie zijn, à raison €576 excl btw, is dit by far de duurste manier van FileMaker te gebruiken in een groepssetting. tenzij je natuurlijk nog een paar separate, (al dan niet legale) licenties hebt liggen. 😬 Bij de ‘reguliere’ team licenties krijg je als het ware 5 FMP’s en drie FMS voor een bedrag dat nog niet eens het dubbele is van een individuele licentie.

Leuk! 19.5 bedoel je? 😇 of gaan we idd 19.3 evalueren? 😳

Ik vraag me af of dit zo is, Gerard. Mijn gedachte was dat je door NAT routering wel een verbinding met de lokale FileMaker zou moeten kunnen maken. Heb dat lang geleden wel eens gedaan. Maar misschien zijn de zaken veranderd en vergis ik me.

Zie mijn opm. dat is ook licentie-afhankelijk. Bij een user-based licentie is de veronderstelling dat een user met meerdere devices kan inloggen, hetgeen impliceert dat de limiet van 5 gelijktijdige connecties tijdelijk overschreden kan worden. Dat is dus niet het geval bij een concurrent connections license, die niet gebaseerd is op aanwijsbare users. Daar geldt een harde limiet. Dit alles betreft dus FileMaker server. Lokale FileMaker sharing valt buiten dit licentie regime. De veronderstelling is dat elke instantie van de applicatie correct gelicenseerd is. De technische limiet geldt voor 5 verbindingen en die is hard.

Inderdaad.

Het is erg leuk en leerzaam om de benaderingen te vergelijken. Wat betreft mijn benadering: ik heb één tabel met waarin alle taal-elementen worden opgenomen. Een record omvat alle vertalingen. je hebt daardoor ook het redactionele overzicht. dus niet alleen veldnamen: alles waar een stukje vertaald tekst moet worden getoond. voor toevoegen van nieuwe elementen hoef je geen velden aan te maken, maar een nieuw record! groot nadeel: er is geen betekenisvolle referentie als je taal-elelement gebruikt: alles hangt aan de nummers. ook is het mogelijk om [labels] in de taal-elementen mee te nemen, zodat je ook volzinnen met ingevulde data kunt presenteren (wat relevant kan zijn in bijv. dialogue boxes)

Vergis je niet. Je rekent af op jaarbasis voor minimaal 5 gebruikers, dus € 960 per jaar, exclusief BTW. Dat is exclusief hardware of VPS. Bij FileMaker Cloud zit je dan op € 1260 excl. , dan heb je geen verdere hosting kosten. Het kost wat, maar dan heb je ook wat. De FMP's zijn inbegrepen (en delen hetzelfde licentiecertificaat). De licentie is user-based, dus je kan in principe met meerdere apparaten inloggen. Als je tijdelijk overschrijdt, dan ga je niet opeens meer betalen, maar de server kan de verbinding weigeren. Bij een concurrent connections licentie is de limiet wel stringent. Het is mij nooit helemaal duidelijk geworden waar precies de grenzen liggen. Lokaal FileMaker delen zou ik afraden voor alle settings waar serieus gewerkt wordt. We verwachten bovendien al een tijdje dat deze functionaliteit zal worden verwijderd.

Dank Menno, als ik een beetje had opgelet had ik kunnen zien dat de UTC functie inderdaad niet een 'dagtijd' oplevert. Dus UTC levert dus toch echt een volwaardige datetimestamp. Vind het jammer dat Get ( CurrentTimeUTCMilliseconds ) geen variant heeft die op de host klok gebaseerd is, nu eigenlijk wel duidelijk is dat lokale timestamps uit den boze zijn als tijd-ertoe-doet in een multi-timezone systeem. Een calculatie/CF als hieronder zou de server UTC-timestamp kunnen leveren.. Let ( [ hostTS = Get (TijdstempelHuidigeHost) ; localUTC = Floor ( Get ( HuidigeTijdUTCMilliseconden ) / 1000 ) ; delta = GetAsNumber ( hostTS - localUTC ) ]; hostTS - delta ) Een tweede uitdaging is de uitbreiding van jouw CF: het converteren van een willekeurig UTC naar een lokale tijd, waarbij je uitgaat van tijdzone, wel/geen DST en zo ja, is deze actief op het moment van de gegeven UTC. Ik vraag me af wat de performance implicaties gaan zijn als je deze grappen echt implementeert.

In aanvulling hierop kan ik fmversion aanbevelen: https://fmversion.com/. Niet in de eerste plaats gericht op analyse, wel over de wijzigingen die in de bestanden worden aangebracht.

Ben zo vrij om even mijn oplossing te delen 😀 De truc zoals ik het toepaste is uit de tabel alle vertalingen van de gekozen taal bij aanvang in de sessie in een globaal veld te laden met x herhalingen. Je neemt dan overal ernaar verwijzen, waarbij je steeds het herhalingsnummertje gebruikt. Dit gaat razendsnel. Werkt ook in zoekmodus, dialogen, calculaties, etc. Omdat het een global is hoef je niet te malen om de relaties. Enkel en alleen om de herhalingnummers. In de vertaal tabel is elke record dus een taal-element, met een vertalingenveld met x-herhalingen, waarin de vertalingen zijn ondergebracht. Elke herhaling is een taal. De referentie heeft dus de vorm: <<lg::tr[3]>> (hou het zo kort mogelijk!) Een nieuwe taal laden is even de globaal vullen met één van de herhalingen van het vertalingenveld. Het indexnummer (herhalingsnummer) is hier natuurlijk erg belangrijk. Het verwijderen van een record uit de tabel is funest. Inderdaad beheer en redactie van de vertalingen heel goed afschermen.

Get(CurrentTimeUTCMilliseconds) is overigens geen timestamp, maar een tijd. Je moet dus ook een UTC datum vastleggen? Voor dit café begint dit best een zwaar onderwerp te worden.

Ok, dat is een hele terechte opmerking! Als je alles baseert op het tijdsverschil van een bepaald moment, krijg je fouten met DST op de betreffende datum/tijdstip. Dan kom ik tot de volgende inrichting': enkel en alleen hosttime-stamps vastleggen: Get(CurrentHostTimestamp) in een UTC formaat. Let op. Get(CurrentTimeUTCMilliseconds) is hiervoor niet bruikbaar! voor datum/tijd weergave aparte unstored calculatievelden waarin de UTC tijd wordt geconverteerd op basis van de tijdszone en DST van de lokatie van de gebruiker. Tijdszone en DST (wel/niet) moeten dan sessie-parameters worden. Wellicht kan je dan on-the-fly bepalen, maar voor makkelijker lijkt het om gebruikersrecords te gebruiken waarin het gegeven wordt opgeslagen. M.i. is er een CF nodig dat Get(CurrentHostTimestamp) omzet in een UTC, aangezien Get(CurrentTimeUTCMilliseconds) de client klok gebruikt. Vervolgens kan de CF als die van Menno worden gebruikt om de UTC om te zetten naar lokale datum/tijd op de layouts: uitgebreid met het DST stuk. Ik vroeg me af of het gebruik van UTC een noodzaak is, of je m.a.w. niet ook gewoon de lokale servertijd tot norm kan verheffen, en mutatis mutandis elke timestamp kan converteren naar de lokale timezone van de gebruiker. Ik denk echter dat je dan ook hetzelfde vraagstuk krijgt met DST.

FBA is de vroegere benaming van Claris Partners. De benaming als zodanig wordt niet meer gebruikt.

Dank jullie wel! Dit is waardevolle input. Ik verkeerde in de onterechte veronderstelling dat Get(CurrentTimeUTCMilliseconds) een host-gebaseerde timestamp oplevert! Dat is dus niet zo en dat maakt het m.i. direct onbruikbaar voor absolute tijdsregistratie, tenzij je de functie op de FMS laat evalueren, wat mij enorm ingewikkelde rompslomp lijkt. Ik volg Banach met zijn stelling: consequent gebruik van de host-timestamp en dus nooit meer de auto-entry tijdstempel aanvinken als je een multi-tijdzone systeem bouwt waarin tijd ertoe doet. Vervolgens moet er dus voor alle gegevens waarvoor een datum/tijd wordt weergegeven een (unstored) calculatieveld worden gebruikt waarin de tijd wordt gecorrigeerd naar de lokale datum/tijd. Althans - als men de tijdstippen in lokale tijd moet kunnen duiden. Kan me voorstellen dat je per sessie een tijdsverschil vastlegt ten opzichte van de hosttijd, om deze correctie mogelijk te maken. Je hoeft dan eigenlijk niet eens de tijdzone op zichzelf vast te leggen. Elk tijdsverschil is goed. Binnen het gesloten systeem van één server heb je daarmee het probleem waarschijnlijk opgelost. Bij niet gesloten systemen en data-sync op basis van timestamps heb je inderdaad het probleem van de tijdverschillen (al dan niet in verschillende tijdszones en DST). Zou me kunnen voorstellen dat je hier een zelfde soort benadering toepast als hierboven: per sessie eerst het tijdsverschil bepalen, en vervolgens bij elke vergelijking op recordsniveau de tijdsverschilfactor meenemen, in de vorm van een soort globale variabele, ook bij het overzetten van de data. Heb een dergelijke benadering nog niet eerder hoeven toe te passen. Wel gebruikte ik een minimale margetijd om niet op elke gedetecteerd tijdsverschil een record te laten syncen, juist omdat de klokken niet 100% gelijk lopen. Overigens vaak in combinatie met een hashcode om werkelijke wijzigingen te kunnen detecteren.

Even peilen: Wat is de beste benadering voor een applicatie dat in meerdere tijdszones wordt gebruikt? We hebben natuurlijk Get(CurrentTimeUTCMilliseconds) om een universele tijd vast te leggen, maar dat leidt wel tot een conversievraagstuk om leesbare tijden in het systeem weer te geven (waarvoor Menno overigens een mooie CF heeft gemaakt). De standaard entry-optie voor tijdstempels uitschakelen en calculatie instellen op Get(CurrentHostTimestamp) is ook een optie, maar leidt ook tot een display probleem als de eindgebruiker in een andere tijdzone zit. Benieuwd naar jullie inzichten!