Marsau

Je kan ook Livetext proberen. Native FileMaker.

Nog een alternatief is een virtuele lijst waarin je een x aantal records de waarden uit een global veld/variabele naar een x aantal velden haalt. Ook multi-user De eerste regel(s) van de waardenlijst (of xml / json array) moet dan een veldnamen-regel zijn. Nog een optie is om een Excel cel voor cel scriptmatig op te bouwen met Scribe of Monkeybread. Je kan dan ook opmaak finetunen. Maar de datatables aanpak vind ik wel erg interessant.

Binnenkort!

Aanvulling voor wat betreft analyse en dashboard: Ik denk dat je separaat ook per enquete een soort analyse-model moet hebben. Misschien kan je per vraag al één of meer SQL-query's vastleggen, die je uitvoert als je het dashboard laadt. Kan me ook voorstellen dat er analyse tussen verschillende vraag/antwoord combinaties nodig is.

Nog even doordenkend.. Enquetes zijn fascinerende data-dingen. Belangrijke ontwerp-gegeven is of de tool een gelegenheidstool is of niet. Zo nee, dan moet je het misschien nog generieker opzetten. - vragensets (versies van enquetes) - in de vraag zelf het antwoord-model vastleggen: meerkeuze (wederzijds exclusief of niet), een cijfer op een schaal, open tekst. Dus geen aparte keuze tabel; wel een vraag-typologie en een model-antwoord, en eventueel validatie-criteria. - wel een aparte antwoord-tabel (records per deelnemer/sessie/id-vragenset).. - ik zou per deelnemer een sessie-record aanmaken: welke vragenset, en check alle vragen beantwoord. Daar kan je dan ook aanvullende data in opslaan (start en doorlooptijd, etc)... - NB dit is nog een 'platte' enquete. Nog complexer/leuker wordt het als er als dan niet voorwaardelijke subvragen zijn te stellen. Dan moet je ook nog de beslisboom of de proceslogica er in zien te krijgen. Het heb het wel eens in FileMaker gemaakt, maar interface-technisch zijn er wel wat (leuke) uitdagingen.

Ja, beide tools gebruiken de data migratie tool. Traag zal het niet gaan; ik denk dat je je vergist. Het gaat juist razend snel; maar wellicht kan het even duren met 100GB+ bestanden. 360Works Deploy kan de migratie ook geautomatiseerd/scheduled uitvoeren, als je de applicatie een beetje aanpast; Otto van Proof&Geist ook en nog veel meer, maar heb ik geen ervaring mee. Ik begrijp dat je in een andere richting zoekt; geen versiebeheer van de applicatie, maar versiebeheer van afzonderlijke scripts. Onder versiebeheer versta je vooral testen/ontwikkelen voor vrijgeven/live zetten. Ik zelf ben geneigd om versiebeheer eerder op te vatten als het tracken van wijzigingen over versies heen. Wellicht bedoel je dat ook. Hoe dan ook: - de tip om om een ontwikkelomgeving te gebruiken en voor release data-migratie lijkt mij vooralsnog zinvol. - release kan je dus zelfs automatiseren; als de migratietijd behapbaar is zelfs met hoge frequentie :-) - vanwege de mogelijke grote verwevenheid van scripts met alle applicatie-elementen zou ik afraden om naar afzonderlijke scripts te kijken. Je hebt de grote samenhang nodig om problemen te kunnen analyseren (toch de enige reden om aan tracking te doen, nietwaar?) - per script altijd standaard een stukje colofon/metadata bij te houden: versiedatum, beschrijving wijziging, opzetdatum, beschrijving functionaliteit, datum, evt. wie. En zet desnoods een versienummer in de scriptnaam. Althans, zo doe ik het. - versiebeheer is mogelijk met de XML-copy of DDR van de applicatie. Op de XML-copies kunnen analyse/tracking tools worden losgelaten (of bouw er zelf eentje). Zo is dan tracking op het kleinst mogelijke element mogelijk. Denk aan tools als Inspector Pro van Beezwax, FMversion of FMPerception i.c.m. Comparison . Als je scripts dan ook nog goed gedocumenteerd zijn heb je een uitstekende versie-tracking. - het is mogelijk deze tools server-side en geautomatiseerd te voeden met nieuwe XML-copies. Succes!

Hi Gerard, begrijp ik goed dat je de scripts als txt opslaat in een tabel? Zo ja, hoe activeer je ze dan?

Dank je, heel interessant. Ik heb het even bekeken. Voor zover ik het begrijp doet het nog niet wat ik bedoel: tekst omzetten naar plakbare FileMaker code.

Er is m.i. geen optie om dynamisch velden toe te voegen. Je zou overigens kunnen redeneren dat het sowieso onzin is om juist deze velden toe te voegen, omdat ze niet binnen de database zijn gegenereerd. Het makkelijkste is - als het zo belangrijk is - om het toe te voegen aan het import-materiaal. Daarna moet je de nieuwe velden van auto-enter opties voorzien voordat je de import doet. Een andere optie is: a. maak een lege tabel met je default fields; zorg dat de auto-enter opties goed staan b. doe de import met aanmaak van een nieuwe tabel c. kopieer en plak de velden d. importeer de importtabel in de laatste tabel. Zorg dat de auto-enter opties goed staan. Best veel gedoe, maar te doen.

Zoals verwacht. Maar elke setup heeft grenzen.

Ja, doe een ontwikkelstraat en gebruik de migratie tool om nieuwe productie versies te genereren. Als je die zo aanpast dat hij de hele set in één keer genereert heb je ongeveer wat je zoekt. Je kan ook denken aan Deploy van 360works (dat wij in een aangepaste vorm intensief gebruiken om ineens tientallen databases te updaten) vanuit een ontwikkelversie, of de 'Otto' odd Geist

Wezenlijk een andere vraag dan het subject, maar ook heel interessant. Ik weet dat je met MBS code kunt uit-kopiëren, maar in-plakken? Het zou een zeer welkome mogelijkheid zijn. Ik gebruik zelf TextExpander om snel snippets in te voeren, maar dit beweegt zich binnen scriptstappen en nooit erover heen. Het punt is natuurlijk dat wat je inplakt in essentie een XML-object is met een bepaald codering zodat het op het klembord alleen geschikt is voor het doel waarin het geplakt kan worden. En dat klembord laat zich niet tussen een Mac- en windowsomgeving transporteren. Ik vond dit op Github van Dan Shockley: https://github.com/DanShockley/FmClipTools

Ik heb dit vooral op windows servers draaien, server-side en geen probleem. Kennelijk wordt de url niet goed geïnterpreteerd. Ik zie niet direct wat hier het probleem is. Check even: https://help.claris.com/nl/pro-help/content/convert-from-filemaker-path.html of https://www.soliantconsulting.com/blog/filemaker-path-conversion-function/

Handig. Ik gebruik: Variabele instellen [ $pad ; Waarde: Get ( Documentpad ) & $filename & ".pdf" ] Variabele instellen [ $url ; Waarde: ConvertFromFileMakerPath ( $pad ; URLPath ) ] # […] Invoegen vanuit URL [ Selecteren ; Met dialoogvenster: Uit ; Doel: Facturen::Document ; $url ; URL niet automatisch coderen ] Voor zover ik weet geen issues met pdf weergave. @Menno: is er een specifieke overweging om voor de data file scriptstappen te kiezen?

Je zou wellicht ook kunnen denken aan het samenvoegen van een pdf, en die dan afdrukken. Uiteraard krijg je gedonder als AV of factuur meerdere pagina's gaan omvatten, maar ook dan zou je een constructie met pdf manipulatie kunnen bedenken. Dus genereer de pdf als factuur in een tijdelijke map, voeg met een tweede scriptstap de AV toe, en met een derde een print opdracht (send Event). Ben het met Banach eens dat de overleggen van de AV bij de factuur veel te laat is (en ook juridisch problematisch), maar dat het geen kwaad kan om je klant van 'reminders' te voorzien.