Marsau

Is een goeie, Menno. Zie hier weer eens het belang van een goede probleemdefinitie. Al die tijd was de server gewoon bereikbaar. Dacht overigens dat die filter functie standaard 'uit' staat.

Het is doorgaans een no-brainer. Ik zou de setup eens uittesten met een andere router. Nog niet duidelijk: komt er überhaupt iets van buiten binnen (of werkt je domotica wel van buitenaf?)

Zie https://support.filemaker.com/s/article/Ports-used-by-FileMaker-Server-14-and-15-1503693096896?language=en_US

@Banach, bij FMS15 heeft poort 443 dus een extra belang, los van container streaming e.d.. @se7en kan je het externe adres überhaupt bereiken (just checking!)? Werkt je domotica wel? En als die 443 gebruikt, moet je die misschien even uitschakelen. Bij hogere FMS versies schijnt het weer anders te zijn.

Ik begrijp dat er helemaal niets gebeurt... Check of de port forwarding ook intern de juiste poort aanspreekt. Ik geloof dat 80 en 443 ook open moeten. Bij FileMaker 15 m.n. de laatste: FileMaker Connection License Client authentication

Vermenigvuldigen van tekst kan je met een recursieve custom functie doen. Bijvoorbeeld MultiplyText ( text; factor) Met als calculatie: If ( factor > 0 ; text & MultiplyText ( text; factor - 1) ; "" )

Drie opmerkingen: Het kan functioneel wenselijk zijn om na betaling vast te houden hoeveel dagen een factuur heeft opengestaan. Dan zou je deze calculatie uit moeten breiden met een veld betaaldatum. Er valt wat te zeggen voor apart Calc.veld vervaldatum, afhankelijk van de betaaltermijn. Onopgeslagen calculaties zou je wellicht moeten mijden, omdat die performance zouden kunnen drukken bij grotere aantallen facturen in lijsten. Ik gebruik soms een veld ‘checkdatum’ waarin op dagelijkse basis de actuele datum wordt vastgelegd.

Maak er eens een lijst van. Koppelteken eruit, vervangen door ¶. Of gebruik de List-functie om de parameter te genereren.

Denk wel dat het een logische ontwikkeling is dat de interface minimalistischer en eenvoudiger wordt. En dat gaat inderdaad ten koste van bepaalde zaken. Het lijkt een ander type gebruiker die nu in de eerste plaats bediend wordt.

Ja, sorry. Ik bedoel containers met externe opslag.

Onderhoudsmatige, kleine ingrepen met kleine foutkans of waarbij een eventuele fout weinig consequenties heeft, doe ik veelal gewoon live. Meer substantiële ingrepen, nieuwe functionaliteit werk ik uit in een development omgeving. Soms ook wel eens geheel offline omwille van snelheid en performance, maar vind het prettig om bij langduriger development werk ook over robuuste backups te kunnen beschikken. Als de operatie het kan hebben, kan je overwegen om bepaalde, meer complexe ontwikkelwerkstukjes ook direct live uit te voeren. De ontwikkelsnelheid is dan ongeëvenaard. Door directe terugkoppeling van gebruikers kan je heel snel fouten repareren of het ontwerp bijsturen, zonder dat je een aparte testfase nodig hebt. Vroeger gebruikte ik scripts om een systeem te legen en opnieuw vanuit een live-systeem te vullen. Dat is nooit een vlekkeloos beheersbaar proces gebleken. Het koste ook erg veel tijd. Migratie is redelijk pijnloos geworden met de migratie-tool, al blijft het gehannes met externe containers.

Heb dat wel eens in elkaar moeten zetten. Denk dat je voor het paginanummering van elk vervolgbestand een gecalculeerd veld (unstored) moet maken op basis van get (paginanummer) + $$aantal voorafgaande pagina’s. Van elke pdf bepaal je in het script het aantal pagina’s; leg dat vast in die $$. Een andere optie is dat je de start paginanummering invult bij het genereren van de pdf. Die kan je dan op dezelfde wijze calculeren.

Ahh. Je wilt dus ritten uniek kunnen identificeren. De auto-enter bij de velddefinities werkt ook gewoon binnen portals (zijnde niets anders dan een wijze van weergave van records binnen records...) Uitgaande van een aparte nummering bij één order kan je auto-enter doen gebaseerd op een telling van aantal ritten + 1.

Om een duit in het zakje te doen: Productontwikkeling in Filemaker. D.w.z. alle aandachtspunten bij technische inrichting, distributie, licensing en het business model.

Een dwarsdoorsnede tussen 'wat je wil leren' en 'origineel' kan ook problematisch zijn.

Het is wel beetje raar om een zo dynamisch gegeven met ordernummer te combineren. Als het alleen om een dynamisch nummer gaat volstaat "{{RecordNummer}}" op de layout of portaalrij.

Het fenomeen dat je meervoudige sleutels kunt gebruiken was mij al bekend, en Menno ongetwijfeld ook. Dat is het punt dus niet. Dat ik dan toch een samengestelde sleutel adviseerde heeft te maken met het veronderstelde gemak ervan. Geen onnodige complicatie, maar een tip om sneller systemen te maken waarin clustering op weeknummers vereist is, waarbij je direct ook een weekcodering hebt die in het natuurlijke gebruik direct herkenbaar is. Een weeknummer moet namelijk altijd in samenhang met jaar worden gezien. Dat was het eigenlijke punt.

Denk dat je wat scherper moet nadenken over wat je neer wilt zetten en wat je precies nodig hebt. Je opzet lijkt meerdere bedoelingen te hebben, en bij elkaar klopt het niet. Heb je een geldig aantal uren als je de tijden invult? Zo ja, dan klopt de formule voor omzet niet: dat is alleen uren x uurloon. Bijkomend bedrag (wat is dat dan?) tel je dan daarbij op. Veld totaalbedrag zou ik hanteren voor het totaal van alle omzetbedragen, bijvoorbeeld als resume-veld.

Weekcodering vind ik altijd handig. Ik doe dit eigenlijk in alle systemen waar iets van weekrapportage aan de orde is. misschien iets teveel als beginnerstip. Maar ik anticipeer op het beoogde gebruik.

Leuk dat je FileMaker gebruikt. Je kan het op verschillenden manieren benaderen, afhankelijk ook van hoe je je werk doet. denk dat je minimaal een tabel van ritten aanmaken. Per rit een aantal calculatievelden met - rijtijd (feitelijk rijtijd totaal per rit minus totaal pauzes, indien deze wel/niet betaald worden) - tarief gehanteerd - omzet/loon: tijd * tarief daarna kan je groeperen op datum of week om declaraties of facturen aan te maken.

Ik bedoel: een calculatieveld met tekstresultaat. Bijv. Year ( datum ) & “-“ & Right ( 100 + WeekOfYearFiscal ( datum ; 2) ; 2) voordeel: - goede sorteringen, ook over jaren heen. - een bruikbare key voor de aanmaak van aanvullende table occurences.

Mogelijk moet je deze combineren met een jaartal, aangezien (de meeste) weeknummers jaarlijks terugkomen.

check de context en de beschikbaarheid van de uitgangsdata. Het is handig om even goed de fouten te loggen in het script. Je zou wonderbaarlijke zaken kunnen ontdekken.

Fout 1506 is een bruikbaar handvat. Niet bij opstart, maar bij verzending. Je zou dan ergens een tabel met SMTP-servers kunnen opnemen. Bij mailverzending ga je de lijst af net zo lang tot je een fout 0 hebt, anders rapporteer/log je de fout. Maar waarom zou je niet gewoon een eenduidige en betrouwbare SMTP-server regelen? Desnoods lokaal, zoals Peter zegt, maar lijkt mij ook weer ingewikkeld, ivm blacklisting, antispam-zaken, domein en DNS gedoe - maar misschien weet ik er te weinig van.

Kleine correctie: strikt genomen is voor portal-filtering zelfs dat calculatie-veld niet nodig. Je kan binnen de filterdefinitie verwijzen naar het veld 'werf-id' van de bestelbon.