bigbadwolf

Ik mag hopen dat je je databases alleen intern hebt… dit zou je toch niet moeten willen op het open net.

Die gebruik ik al zolang niet meer dat ik ’m vergeten was…

Ik gebruik het voor vrijwel elke database die ik maak. Met name omdat er tabellen zijn waarin gebruikers records niet mogen maken/weggooien, en dit is de beste manier om dat te voorkomen.

De werkwijze voor de container kun je niet wijzigen. Zo werkt het nu eenmaal in FileMaker. De database is een soort ‘doorgeefluik’. Waarom lees je niet gewoon de paden naar de foto’s uit? Dan heb je ze ook in de database, maar hoef je ze niet allemaal te importeren. Als je van alle foto’s een thumbnail wilt hebben kun je daarvoor ook een routine maken die een thumbnail inlees en vervolgens het origineel weer weggooit.

WD werkt prima, maar je moet heel erg oppassen met wat je op de pagina zet. Less = more… De performance mag dan niet optimaal zijn, dat is het bij veel ‘echte’ websites tegenwoordig ook niet meer door alle fratsen die ontwikkelaars uithalen. Daarnaast is het wel zo dat ‘wij’ met FileMaker wel heel snel een aanpassing kunnen doen die in veel gevallen voor webontwikkelaars meer tijd vergen. Sommige nadelen hebben dus ook voordelen. En je hoeft er ook geen aparte website voor in te richten. Groot nadeel is de licentiestructuur van FileMaker. Als je een beperkte gebruikersgroep hebt

Onder Windows gaat het altijd goed. macOS is veel kritischer, dan moet ik ze echt goedzetten anders staan ze op slot.

Dat banken voorzichtig zijn met koppelingen lijkt met vanzelfsprekend. Je wilt niet dat iedereen zomaar bij bankgegevens kan komen. Het minste waarvoor je wel zouden kunnen zorgen is echte standardisatie…

In mijn geval is het een vaste verbinding… heb het dus niet over een MacBook, maar over een iMac die 24/7 aan staat en verbonden is over een vaste internetverbinding.

Ken het fenomeen ook. Soms wordt de verbinding wel hersteld, soms niet. Maar waarom is mijn ook nog steeds een raadsel. Wat dat betreft volg ik Marsau… vroeger was het slechter… ;o)

Mijn ervaringen met banken (ClieOp, SEPA) is dat ze afspraken maken over standaards, maar er vervolgens alles aan doen om zich er vooral niet aan te houden.

Dat gaat niet werken als hij onderweg is…

Meest logische keuze is een FileMaker Server. In alle andere gevallen kun je een database wel lokaal delen, maar niet buiten het eigen netwerk. Je hebt dan nog wel een ander probleem… je zult moeten upgraden naar FileMaker 19, want een server voor FileMaker 15 kun je niet meer aanschaffen. Of je moet gebruik gaan maken van één van de weinige shared hosters die er nog zijn.

Bestandjes van 1 pixel die 67K zijn is fors… ik heb zelf wel eens met png’s gewerkt, maar die waren nog niet eens 1K… 48 * 67K is toch nog wel een aardige hoeveelheid data. En als je dat dan ook nog eens in portalen laat zien… tel uit de hoeveelheid dat die steeds opgebouwd moet worden. In de unicode lettertypen zitten ook vaak blokjes. Die kun je misschien ook wel gebruiken i.p.v. containers met afbeeldingen.

Nope. Enige alternatief is gewoon FileMaker Pro aanschaffen en dat is voor veel ‘enkele’ gebruikers een (te) dure oplossing. Het stond overigens al heel lang (volgens mij bij versie 16) op de nominatie om te verdwijnen. Daardoor werkte een aantal vernieuwingen ook al niet meer in de runtime.

Met ingang van FileMaker 19 kun je geen runtime meer maken.

Even zonder het voorbeeld van Menno te openen… als je een optelling maakt van alle 1-en in het portaalveld weet je ook hoeveel records er met 1 zjin. Daarvoor hoef je geen FileMaker expert te zijn, dat is gewoon rekenen.

Het zou nog mooier zijn als je op basis van gebruiksfrequentie de lijst zou kunnen samenstellen. Dus veelgebruikte keuzes bovenaan (bijv. met een maximum van 5) en dan de rest alfabetisch eronder.

Kan het zijn dat je ‘forward typing’ hebt aangezet voor het veld? Als dat zo is kan het afhankelijk van de index van het veld inderdaad wel vertragen…

Ik heb nu (nog) een vergelijkbare iMac uit 2012, maar de problemen die je beschrijft komen me niet bekend voor. FileMaker is niet altijd even stabiel, maar het komt maar zelden voor dat hij mij niet bij kan houden. Weet niet wat je allemaal op de machine in de achtergrond hebt draaien? Maar dat kan er natuurlijk wel voor zorgen dat de processor (ook) druk is met andere processen.

En eerlijk gezegd… met FileMaker Go onder iOS zou het erop neerkomen dat het voornamelijk interessant is om in te zetten voor Android gebruikers. En dan is de keuze voor WebDirect ook helemaal niet zo verkeerd. Zeker niet als je er vanuit gaat dat de gebruikers toch altijd online zijn.

Kan op verschilleden manieren. Eenvoudigste is waarschijnlijk door een relatie te leggen tussen de afdelingsnummers (en eventueel een relatienummer zodat je niet in de knoop komt met bedrijven die dezelfde afdelingsnummers gebruiken). Met een simpele berekening kun je dan een lijstje maken. Substitute ( list ( RELATIE::email ) ; ¶ ; "; " ) Een script kan ook, maar dat moet je dan laten lopen om het veld weer te vullen.

En je krijgt waarschijnlijk geen geld terug als je minder gekocht hebt… ;o) Is inderdaad schreeuwend duur. Voor dat geld kun je bijna een App laten ontwikkelen.

Omdat je niet specifiek een substitute doet voor bepaalde teken (behalve dan de Char-codes), kun je die eenvoudig om de hele code heen zetten: Upper ( TrimAll( Substitute ( TextFormatRemove ( If ( IsEmpty ( self ) ; ArtikelRelatie::Omschrijving ; Self ) ) ; [ Char ( 10 ) ; " " ] ; [ Char ( 13 ) ; " " ] ; [ Char ( 160 ) ; " " ] ) ; 1 ; 1 ) )

Downloaden/uploaden via de Admin Console ben ik al een poosje op afgebrand. Ik schuif ze altijd over via de FTP. Sneller en praktischer.

Misschien kunnen we beter helpen als we een duidelijk(er) beeld hebben wat je voor ogen hebt. Je hebt het nu ineens over zoeken, terwijl je het eerst hebt over de weergave van de tekst. Dit zijn twee totaal verschillende zaken. Zoeken heeft niets te maken met de grootte van de letters. Als je niet kunt zoeken ligt dat eerder aan de wijze waarop je zoeken en of het veld wel geindexeerd is.