Marsau

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.

Ja, dat kan, maar niet als je werfid als Foreign key wilt gebruiken, dan heb je een geïndexeerd veld nodig. Als toegevoegd berekend (niet opgeslagen) veld kan je wel je portal filteren met bijvoorbeeld een global field met werf-id. Dat is wat je wil, geloof ik.

Voeg WerfID aan je bestelregels toe.:-)

Volgens mij wordt de externe verbinding doorgelust. Dus de poorten moeten open. Het verbaast mij dat het op het LAN wel zou werken. Waarom deze ingewikkelde setup?

Wellicht raar, maar... als je gewoon een leeg wachtwoord invoert? Je hebt waarschijnlijk de auto-login uitgeschakeld.

Uit de losse pols; je kan het op meerdere manieren aanvliegen: - als afhandelen van expiratie-data echt een bedrijfsactiviteit is, valt er wat voor te zeggen om alle expireerbare items in een aparte tabel onder te brengen; - Anders moet je met calculatie velden binnen het medewerker-record gaan werken; krijg je wat minder mooie overzichten van. - Zorg voor een portaal met de expirerende items volgens het gewenste criterium (kan mij voorstellen dat er meerdere criteria nodig zijn: bij 7 dagen ben je altijd te laat) - Plaats deze in een card window layout. Maak een knopje ‘expiratie-overzicht’ o.i.d. dat deze opent. - Vervolgens in het openingscript maak je subscript dat dit expiratie-overzicht opent als er items zijn. - Daarnaast een install timer script installeert met de duur uitgerekend tot morgen 0.00 uur, of een andere popup-tijd, dat hetzelfde script uitvoert. -Nb timer scripts zijn venster gebonden. Als je veel vensters sluit en opent, moet je je timers steeds opnieuw installeren. Ergo, snoozen is verder niet nodig, maar je kan altijd kiezen een kortere tijd in te stellen als je je gebruikers tot waanzin wilt drijven. Of als er een andere, serieuze functionele noodzaak is. Logt de gebruiker gewoon weer de volgende dag in, dan krijgt weer het overzicht - als er op dat moment items zijn. ‘Opvolgen’ houdt in dat de datum wordt opgehoogd en beter nog, dat het geëxpireerde item vervalt en wordt vervangen. Kan je op verschillende manieren doen. Ik neem aan dat je de opvolging in deze data moet aanpakken, en niet op het niveau van dit script, dat niets anders doet dan notificeren Succes!

Beste mensen, Graag nog dit probleem nog even onder jullie aandacht. Full access toegang op Windows clients, maar opmaak van layout-objecten laat zich niet wijzigen. Vanaf mijn Mac(s) geen enkel probleem. Op zich is dit wel grappig natuurlijk, maar... Klant is unhappy. Herinstallatie op één van de clients hielp niets. Probleem doet zich voor op alle clients op deze ene lokatie. Heb ik hier weer een zeer uniek en lokaal probleem, of zie ik iets essentieels over het hoofd? En zo nee, welke oplossingsstrategie zou ik kunnen hanteren?

Ik zou de eerste ontwikkelingsschreden even scheiden van het hostingsvraagstuk. Vraag je eerst eens af welke oplossing je wilt ontwikkelen. De eerlijkheid gebiedt te zeggen dat een beginnende ontwikkelaar niet zomaar een functionele bedrijfsapplicatie zal realiseren, maar met de templates kan je zeker een heel eind komen. Hosting kost wat, kan ook intern, als je Filemaker Server gebruikt. Prijzen op de website en afhankelijk van aantal users. Kosten moet je uiteraard in verband brengen met je business case als ondernemer; afgemeten aan een goede businesscase zijn ze helemaal niet 'hoog' en doorgaans voor bedrijven een reden om op de lange termijn voor Filemaker te kiezen. Interne hosting vanaf een Mac mini kan ook prima, maar vereist wat meer expertise / zorg. Persoonlijk zou ik zeggen: schaf het aan, en volg een cursus. Het gaat zich dubbel en dwars terug betalen. Voor ontwikkeling van ideeën / concepten kan je ook een beroep doen op de vele professionele ontwikkelaars op dit forum.

Helaas. Vandaag iemand laten herinstalleren met volledige rechten. Probleem persisteert. Raar issue hier: meerdere clients hebben er last van. Via rechter muisknop is opmaak van layout-objecten wel mogelijk. Windows only!