Ga naar inhoud

WJ

Leden
  • Items

    505
  • Registratiedatum

  1. Account corrupt denk ik. Gewoon account vervangen voor nieuwe. Groet WJ
  2. Thanks werkt erg leuk en is robuust.
  3. 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
  4. Er is maar 1 admin console en dat is die op de master....
  5. Hoi Superwimmie, Ken het fenomeen niet. Ik weet wel dat windows 2012 sterk wordt aangeraden vanwege IIS8. Betere prestaties. Groet WJ
  6. 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
  7. 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
  8. 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
  9. 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.
  10. 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
  11. 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
  12. 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.
  13. 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
  14. 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
  15. 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
×
×
  • Nieuwe aanmaken...