WJ

Account corrupt denk ik. Gewoon account vervangen voor nieuwe. Groet WJ

Thanks werkt erg leuk en is robuust.

We hebben een server ingericht met Tika (https://tika.apache.org/) via een insert from url kun je daar een document naar toesturen en krijg je die in tekst terug. Dit kan je ook doen met https://github.com/tesseract-ocr/tesseract Deze zou ik aanvullen met https://www.imagemagick.org/script/index.php Groet, Willem-Jan

Er is maar 1 admin console en dat is die op de master....

Hoi Superwimmie, Ken het fenomeen niet. Ik weet wel dat windows 2012 sterk wordt aangeraden vanwege IIS8. Betere prestaties. Groet WJ

Hoi Superwimmie, We hebben het hier ook al uitgeprobeerd en werkt prima. Ben benieuwd naar de acceptatie procedure van apple. Welke cursus doel je op ? Groet, Willem-Jan

Felix ik heb altijd je bijdrage gewaardeerd. Snap er niks van als de moderator niet voor jouw zijde kiest. Jammer dat het zover moet komen dat er een zijde gekozen moet worden. Moderator ik denk dat hier wat recht gezet moet worden. Groeten Willem-Jan Kempen

Tja volgens mij hadden we deze discussie niet gehad als FileMaker gewoon een goede versie en update management tool had. Andere omgevingen hebben bijvoorbeeld github. Dit hebben we echt nodig als je het mij vraagt. Tot die tijd is het behelpen. Of vaak data updates of vaak interface files verwisselen beide niet heel erg prettig. We ontwikkelen niet tegelijk in 1 bestand(meestal moet ik zeggen.) Wat we doen is de aanpassingen in een aparte versie maken vervolgens ter controle aanbieden aan een andere ontwikkelaar na goed keuring code overzetten in 'echte versie' Groet, WJ

Nee gewoon in het ancher buoy model rood voor delete en groen voor aanmaken etc... We ervaren geen probleem met onze software oplossing (azorsoftware.nl) in 1 file die de volgende modules bevat. (bedrijven,relaties,facturen,inkoopfacturen,urenregistratie,todo's,planning,kosten,documenten,agenda,offertes, management, meertalig en multicurrency. 115 tabellen). Het is voor ons een genot om 1 file te hebben. Denk aan updates, demos, customfuncties, variable, rechten backups etc. Filemanagement is gewoon een stuk makkelijker. Wij werken het liefst zo min mogelijk met ExecuteSQL en als we het gebruiken dan vaak op de manier zodat je nog de veldnaam kan wijzigen. Denk ook aan het probleem dat je met baseelements niet meer kunt checken of iets unreferenced is. Denk aan het probleem dat ExecuteSQL een andere engine is die de resultaten in een ander formaat teruggeeft etc... Nou ja om het verhaal maar af te sluiten denk dat je niet kan zeggen welk model beter is. Er zijn argumenten voor alle 2 de kanten te bedenken. En een specifieke situatie kan ook bepalen welk model beter past. Ik denk dat het ook verschilt of je met meerdere mensen aan 1 oplossing werkt of alleen. Dus met andere worden tal van redenen om voor iets te kiezen.

Ben nog steeds van mening dat FileMaker zelf ook geen voorstander is van deze manier van werken en dat het onverstandig is. Het kunnen leggen van koppelingen met andere bestanden is vanuit backwards comptabiliteit ontstaan. Volgens mij zijn er geen voorbeelden in de FileMaker training series te vinden van data en interface file. Er zijn ook geen voorbeelden van FileMaker starter themas of wat dan ook waarbij deze methode wordt toegepast. De verschillende interfaces zitten in 1 bestand. Het zijn voornamelijk de ontwikkelaars die dit pad zijn gaan bewandelen omdat ze dan makkelijker updates kunnen uitvoeren. De klanten wil snel aanpassingen dan is het wel lekker als je geen data hoeft over te zetten. Je kan ook makkelijk een bug snel oplossen. En omdat alle andere omgevingen mysql php of wat dan ook de data en logica gescheiden zit. FileMaker onderscheidt zich door dit niet te doen. Je bouwt als het ware op een bruggetje wat filemaker heeft gemaakt voor compatibiliteit. Een voordeel is dat het tegenwoordig door zoveel ontwikkelaars wordt gedaan dat FileMaker wel betere ondersteuning hiervoor moet gaan aanbieden. Onze favoriete werkwijze - 1 bestand met alles erin. (ancher en buoy methode, eventueel bij een zeer grote hoeveelheid in 1 tabel deze splitsen.) - Extra bestanden voor 'bijzondere koppelingen' (customphp/output die de gebruiker zelf moet kunnen aanpassen) - Extra bestand voor iPad wat op de ipad lokaal draait zodat de snelheid optimaal is. (merk wel dat 4g en nieuwe ipads dit eigenlijk overbodig maken - 1 update bestand wat data van de oude versie in de nieuwe live inlaad. Trouwens wat ook een argument is is dat alles steeds meer naar de cloud gaat en de server maar 125 files aankan. Doordat wij Azor op 1 file hebben gebouwd kunnen we heel wat klanten kwijt op 1 server. Groet WJ

Caching probleem: Komt erop neer dat de data file niet goed doorheeft wanneer de cache joins moeten worden geleegd. Je hebt 2 files met 2 file caches. Gewoon gezegd je zult meer refresh flush moeten gebruiken en portalen zullen moeilijker updaten. Complexiteit: Heel simpel 1 file is een stuk eenvoudiger hoe je het ook went of keert. En dit zeg ik niet omdat we nooit met meerder files werken. Niet dynamisch kunnen instellen van external resources: Deze heb je niet nodig als je met 1 file werkt..... Wil niet zeggen dat de voordelen van interface en data gescheiden toch kiest en blij mee bent natuurlijk. Iedereen zijn manier van werken. En het makkelijker kunnen updaten vind ik echt een groot voordeel. Helemaal voor !!! Groet, WJ

Ik vind FileMaker een prachtig pakket maar version management is een groot gemis in het platform. Je kunt dit proberen op te lossen met data interface te scheiden maar daar kleven veel nadelen aan. Enkele problemen die je nog bij scheiden van data en interface ondergaat: - Caching! (Je krijgt 2 caches de data file heeft niet altijd door dat de cache moet worden vernieuwd dit heb je al bij een singel file maar wordt nog erger met 2 files ) - Alle zaken die per file zijn (variable/taal settings etc) - Continue moeten schakelen tussen de files - Complexiteit (zaken doorgeven met scriptparameters en dergelijke) - Niet dynamisch kunnen instellen van external resources geeft veel problemen - Perform on server - Wij gebruiken het wel bijvoorbeeld voor iPad module die dan makkelijk is te vervangen. Maar eigenlijk moet FileMaker eens een fatsoenlijke version management mogelijkheid bieden. Bijvoorbeeld update file met DDR XML. Groet WJ.

Conclusie: Geen verschil in laadtijd tussen een database met veel lay-outs en scripts en een database zonder lay-outs en scripts. Hoi Rene, De laatste conclusie klopt volgens mij niet. De relatie grafiek heeft de meeste impact op de performance. Ik hou niet van database en interface scheiden in FileMaker. Maar bij grootte oplossingen (grootte grafiek, veel joint caches) scheelt het nogal om met een extern interface bestand te werken voor iPad / iPhone, tenminste dat is mijn ervaring. Groet, WJ

Het is inderdaad erg jammer dat de PDF functionaliteit er niet inzit. De MBS plugin kan het volgens mij wel. Ik zou willen vragen of iedereen een feature request wil indienen om dit in webdirect te krijgen. http://www.filemaker.com/company/contact/feature_request.html Groet, WJ

Hoi Andries, Dit wordt een beetje gokken en begeef me dus op glad ijs. Maar de volgende punten: Een bestand met veel occurences opent een stuk langzamer. Zeker als ze allemaal verbonden zijn en dus niet in met het ancher en buoy. FileMaker heeft dan veel werk met het aanmaken van de cache data. Als FileMaker alleen de joins zou cachen die hij tegenkomt met opstarten door de 'layouts' dan zou er niet zo'n groot verschil mogen zitten tussen bestanden met een grote grafiek en een kleine. Walking the graph heb ik andere ontwikkelaars dit fenomeen ook wel horen noemen. Voorbeelden van bestanden die 5 minuten duur voordat ze openen omdat de grafiek zo groot is zijn bekend. Caching verandert zo'n beetje in iedere versie van FileMaker en wordt steeds verder geoptimaliseerd. We hebben het hier over de joint cache. Die je kunt legen met flush cache join results(refresh window). Dit zijn de joins van de relaties. Andere informatie zoals layout info wordt ook gecached. Hoe het precies werkt met meerdere bestanden weet ik niet precies.Dat het refresh problemen oplevert dat weet ik wel. FileMaker probeert automatisch de cache bij te werken als data verandert dit lukt niet altijd even goed. Zeker niet met meerdere bestanden. Dit kan je eenvoudig uittesten. Er zit dus verband tussen meerdere bestanden en caching. FileMaker heeft minder goed door wanneer hij de join cache van de interface file moet bijwerken. Ik denk dat FIleMaker de externe koppeling met bestanden meer erin heeft gezet om toen der tijd backwards compatible te zijn (Conversie van fp5->fp7). Maar ja het lonkt wel om te gebruiken voor allerlei doeleinde. Maar het heeft een hoge prijs als je het mij vraagt. Groet, WJ

Hoi, Ik denk dat het van belang is te beseffen dat filemaker een cache per bestand bijhoudt. Als je een factuurmodule maakt met een factuur tabel en factuurregels tabel. Je maakt deze structuur in een single file en in een interface/data file dan zul je verschil zien in caching. In een single file kan je een factuurregel toevoegen en op het moment dat je het bedrag invult zie je meteen het totaal bedrag updaten (sum van de regels). Doe je datzelfde in een multifile dan heb je refresh problemen. Bij het openen van een bestand loopt filemaker de grafiek af en maakt een cache per join aan. Dat doet hij voor alle relaties. Je zult zien dat als je een grote graph (1000+) hebt dit een behoorlijke performance druk legt op de applicatie, tot zelf niet meer functioneren. Het scheiden van de graph in verschillende bestanden levert dan ineens een veel snellere applicatie op. Maar levert dan weer refresh problemen op. Dus ja het is kiezen. Maar een kleine graph zorgt voor meer snelheid in je app. Over het wan is de hoeveelheid data erg belangrijk voor de snelheid. Daarom zie je soms dat men aan table narrowing doet. Groet, WJ

Gatverdamme, misschien kan iemand dit verwijderen ?

- Laatste versie van FileMaker Pro 12 gebruiken scheelt veel - Freeze sriptstap werkt nu echt. Groet, WJ

Ik bedoelde ook alle records uit de relatie waarop de portal is gebaseerd, die je eigenlijk namaakt via de het SQL commando. Als de relatie verandert moet je niet vergeten het SQL commando ook aan te passen. 500 records is ongeveer de limiet begrijp ik, dat lijkt inderdaad best acceptabel. Maar dan moeten er niet meerdere portalen op de layout staan denk ik zo. En via het WAN ? zal de limiet nog eerder bereikt zijn. En is dat met een lichte tabel of uitgebreide tabel? Beetje mee oppassen zou ik zeggen, perfomance is toch belangrijker dan funky stuff. Zou het toch niet zo snel inzetten. Wellicht kan je het tweaken met de SQL limit functie maar volgens mij wordt deze niet door FM ondersteund. Zou mooi zijn als FM het eens inbouwd en dan ook meteen dat je de breedte van een kolom kunt wijzigen. Groet, WJ

Mooie techniek, Ik vraag me alleen af hoe het zit met de snelheid. Je vraagt immers alle records op gesorteerd op. Vervolgens laat je ieder records uitrekenen welke positie hij inneemt in deze lijst. Daarna sorteer je op deze unstored. Hoe zit het met grote datasets gaat dat goed ? Groet, WJ

Ik heb niet het hele verhaal gelezen wat jullie achter de rug hebben,sorry geen zin in. Dus wellicht is mijn opmerkingen niet geplaatst maar ja kijk maar of je er wat aan hebt: Wat wij doen is het downloaden van de nieuwe versie via de nieuwe scriptstap insert via url dat werkt prima. Het grappige is dus dat je de nieuwe versie eerst in een container opslaat in je oude versie. Groet wj

Een layout wordt in punten weergegeven. 1 punt is bij retina 4 pixels. 1 punt bij normaal scherm is 1 pixel. Layouts blijven even groot alleen worden haar scherp. Groet WJ

Last functie. First kent filemaker niet maar ja die kan je altijd gewoon grijpen. http://www.filemaker.com/12help/html/func_ref3.33.45.html

Herinnering. Morgen is het zover voor wie het vergeten was. Leuk als je komt. Groet, Willem-Jan

Zonder het bestand lastig maar als je wel de datum uit de relatie kan pakken waarom pak je dan ook niet het bedrag uit de relatie. Je hebt de max functie niet nodig je kunt gewoon de relatie sorteren en dan krijg je het juiste record "bovenaan" en kan je die pakken zonder max. Een truuk om een relatie te laten dwingen te evalueren zonder een refresh flush. Is een global als cartesian opnemen in de betreffende relatie en die veranderen dan "weet" FileMaker dat de relatie gegevens opnieuw moeten worden opgehaald. Groet, WJ