menno

Dat is een kwestie van je gegevens goed organiseren. Je hebt kennelijk gezinnen, met personen met eigen kenmerken. Dus je maakt kolommen voor het gezinsID, FunctieID (Papa, Mama, Kind oid) en dan sorteer op achtereenvolgens GezinsID en dan FunctieID. Jij ontwerpt de DB, dus jij kan dit soort dingen gewoon zelf bepalen

Klopt voor MacOSX helemaal, maar op windows kan je een 32-bits versie installeren en dan werken de meeste plug-ins. Uitzonderingen zijn bijvoorbeeld verouderde 360works plug-ins zoals de email 1.972 moet je vervangen voor 1.981 (of upgraden naar versie2) en de scribe 1.401 moet je vervangen voor 1.43, de rest van 360Works gebruik ik niet, dus daar kan ik niets over zeggen.

Je records sorteren op een specifieke kolom en als het goed is gaat FM proberen de records gesorteerd te houden als je records toevoegt en vastlegt

Je kan ook in "beveiliging beheren" bij een "eigen" privilege set de "beschikbare menu-opdrachten" op "minimum" of "alleen bewerken" instellen, moet je een beetje experimenteren

Ja en ik vind het een echte vooruitgang, de script-workspace, het nieuwe "top navigation" layoutgedeelte, de ikoontjes bij de veldnamen voor de veldtypen, het buttonobject en de syntax-coloring zijn wel de meest opvallende vernieuwingen/verbeteringen. En nog steeds fmp12-bestandsformaat, dat is ook wel fijn.

In de afgelopen 11 jaar zijn er slechts 2 versies in de winter uitgebracht en de overige versies zijn allemaal in het (vroege) voorjaar en in de zomer uitgebracht: FM 7 Mei 2004 FM 8 Aug 2005 FM 8.5 Jul 2006 FM 9 Jul 2007 FM10 Jan 2009 FM11 Maa 2010 FM12 Apr 2012 FM13 Dec 2013 Ik gok er dus op dat FM14 vóór het einde van de zomer uitkomt .... zin om een poeltje op te zetten?

Heb fii een macserver geïnstaleerd. Je kan vanaf de commandline een bestandje in documents schrijven met: fmsadmin list clients -u -p > /Volumes/Macintosh\ HD/Library/FileMaker\ Server/Data/Documents/log.txt Werkt dus identiek als onder windows, behalve dat fmsadmin gewoon bekend is bij het systeem en je niet naar de map met de executable hoeft te wisselen Automatiseren kan op de volgende manier: 1) Maak een scriptbestand log.sh (opslaan als platte tekst) in /Volumes/Macintosh\ HD/Library/FileMaker\ Server/Data/Scripts/ met de volgende inhoud: #!/bin/sh fmsadmin list clients -u -p > /Volumes/Macintosh\ HD/Library/FileMaker\ Server/Data/Documents/log.txt 2) Pas de permissies van het bestand aan met: chmod 755 /Volumes/Macintosh\ HD/Library/FileMaker\ Server/Data/Scripts/log.sh 3) Maak een schedule in FMS:

Het schrijven van het log-bestandje in de documentenmap lijkt met het beste gewoon door de server te laten doen dmv een schedule. Het vullen van het fm-bestand zou je prima met psos kunnen doen, maar dan zie ik twee bezwaren: #1: deze is niet heel belangrijk, maar je weet niet wanneer een client is ingelogd en #2: Je zit in een multiuser-omgeving en met 2 of 3 gebruikers zal je elkaar bij het vullen van het fm-log-bestand niet heel snel in de weg gaan zitten, met 25 of 50 gebruikers is dat mogelijk anders.

Ik heb het even zitten knutselen op mijn (windows-)server en het werkt prima met het volgende script: cd "%programfiles%\FileMaker\FileMaker Server\Database Server\" fmsadmin list clients -u -p > ..\Data\Documents\log.txt waarbij en moeten worden vervangen voor je eigen u/p van de fmserver-console. Het scriptje moet .cmd of .bat als extensie krijgen en in %programfiles%\FileMaker\FileMaker Server\Data\Scripts worden geplaatst. Vervolgens maak je in de FMS-console een schedule dat dit scriptje iedere minuut aftrapt. De volgende stap is een fmp-logbestandje maken. Daarvoor kan je het bijgevoegde voorbeeld gebruiken: Log.fmp12 en ook met dit bestand maak je in FMS een schedule dat óók iedere minuut wordt afgetrapt, met het enige script dat er in aanwezig is. In dit bestand wordt 5 seconden wacht voordat het gaat importeren, dat blijkt voldoende. Als je korter wacht of heemaal niet, dan mislukt de vorige schedule en kan je niks oplepelen uit het text-bestandje. Na de import wordt de data verwerkt .... nieuwe client ID's worden aan de lijst toegevoegd en oude ID's worden bijgewerkt. Is een client niet meer aanwezig, dan wordt de entry niet meer bijgewerkt en wordt ook de _Last tijdstempel niet meer bijgewerkt. Uiteraard moet dit bestand eigenlijk weer worden leeggegooid bij het opnieuw opstarten van FMS, want de clientID's worden dan namelijk gereset. Het is echter niet erg als dat niet gebeurt, want als je zoekt naar de grootste _Last-waarde dan weet je welke clients er op dat moment zijn ingelogd. Je weet dan alleen niet wanneer ze de eerste keer zijn ingelogd ... dit valt echter voorlopig buiten de scope, het gaat hier om de werking. Opleuken is voor later een zorg. Ik heb dit niet op MacOS geprobeerd, maar daar zie ik graag jouw bevindingen

Op een windows-server kan je met de commandline op de volgende manier de userlist naar een bestand laten uitvoeren: cd "%programfiles%\FileMaker\FileMaker Server\Database Server\" fmsadmin list clients > %userprofile%\documents\log.txt Op MacOS kan dat vast ook, het is een kwestie van uitzoeken hoe dit precies door FMS kan worden uitgevoerd om het te schedulen ... je zit vooral te emmeren met gebruikersrechten van fmsadmin en system. Ik zal het zelf ook eens proberen.

Als je een bestand hebt dat alle gebruikers open (zouden moeten) hebben, dan zou je get ( usercount ) kunnen gebruiken. Je weet dan echter nog steeds niet hoe, waarmee en met welke rechten ze zijn ingelogd.

HE ik heb geprobeerd dit te reproduceren met alle mogelijke illegale tekens in veldnamen, tabelnamen, maar ik krijg altijd keurig een lijstje terug met de veldnamen. Een paar scenarios om te testen met jouw bestand: 1) Exporteer de bewuste tabel naar een apart bestand met alle voorhanden veldnamen en kijk of het daar ook mis gaat. 2) Maak een clone van het bewuste bestand en kijk of het dan nog steeds misgaat 3) Maak van de clone een aantal kopieën en gooi iedere keer de helft van de berekende velden weg totdat je wel de lijst met veldnamen terugkrijgt. Daarna doe je hetzelfde truukje met de helf van de velden die je even ervoor hebt weggegooid, net zolang totdat je de boosdoener hebt. Verder heb ik geen suggesties. Succes en laat even weten of het lukt of niet mvg, Menno

Wat is de naam van de tabel?

Sorry ik zat niet op te letten, hierbij hetzelfde bestand in fp7 formaat Rekeningen.fp7

Je hebt niet verteld hoe je de periode selecteert, dus dat heb ik in dit voorbeeld achterwege gelaten. Dit voorbeeld bevat 2 mogelijke oplossingen, maar er zijn er nog veel meer. De eerste is de simpelste en maakt gebruik van de relatie tussen de rekening en de mutaties. Een knopo die alleen maar naar de gerelateerde records gaat toont alle mutaties bij een rekening. De tweede is ietsje moeilijker, maar lijkt veel meer op jouw oplossing en gebruikt een scriptje. Het rekeningnummer wordt als scriptparameter meegestuurd. In het script wordt van die parameter een variabele gemaakt en die variabele wordt als zoekargument gebruikt. Da's alles. Prettige reis verder Rekeningen.fmp12

Je kan toch een extra berekend veld maken waar je altijd een waarde inzet: If ( gefaald = "" ; "nee" ; "ja" ) //wel even het vinkje uitzetten bij "Niet evalueren als alle velden waarnaar wordt verwezen, leeg zijn" en vervolgens daar een relatie mee leggen? Of is "gefaald" werkelijk niet geïndexeerd en niet alleen maar af en toe leeg?

Dan is de vraag hoe je de DB hebt gehost of je "secure storage" hebt gekozen of niet. Het zou goed moeten werken (in de zin van bestanden downloaden en openen) als je op een FMS met secure storage werkt. Het kan zijn dat thumbnails door de beide platforms niet worden gegenereerd voor het andere platform, dat weet ik niet zeker want ik gebruik deze functie zelf nooit. (Ik gebruik zelf al jaren (sinds fm 4) een file-plug-in en toen bestanden in containers konden worden geplaatst, zijn wij de plug-in blijven gebruiken, maar dat terzijde) Je kan de bestanden wél openen, je ziet alleen de thumbnails niet? Of zie je ook geen wit bestands-ikoon?

Wat bedoel je met "laten zien"? Zijn bestanden wel downloadbaar en in orde voor de mac's of moeten de mac's gebruikmaken van de padverwijzing die in windows is gebruikt en opgeslagen?

2500 artikelen stelt qua aantal helemaal niets voor en je zou heel wat sneller je resultaat moet zien dan na 1 a 2 seconden. Ik verwacht eigenlijk dat er een restrictie in de ODBC-verbinding zit die je parten speelt. Je zou eens kunnen proberen een hulptabel te maken, waar je alle data van die 2500 artikelen in importeert en die daarna eens per dag oid als jullie er niet zijn gewoon synchroniseert. Natuurlijk kan dat alleen als er in die tabel niet teveel wordt gemuteerd, anders moet een andere oplossing worden gekozen. Hoe zit het met jullie hardware, waar hebben jullei FMS op draaien? Vlotte bak, voldoende geheugen en de software: welk OS, welke driver voor de ODBC-koppeling?

En dan doe je normale zoekopdrachten neem ik aan? Als het platte tabellen zijn waar je in zoekt, dan valt er via ESS niet veel snelheidswinst te behalen. Heb je relaties gelegd en zoek je gerelateerde data, dan kan het gemakkelijk trager worden. Hoe groot zijn de datasets die je doorgaans opvraagt als je 1 a 2 seconden moet wachten op het resultaat? Hoe dynamisch is de data? Verandert daar veel?

gebruik je ESS of doe een SQL-query met ODBC waarvan je het resultaat importeert?

Als je een beetje handmatig werk niet erg vindt, dan kan je nadat je de door jou gewenste lijst heb gevonden/gemaakt in FM, met de alt/option-toets + de command-toets (ctrl op windows) ingedrukt alle records kopiëren en daarna plakken in Excel. Als de volgorde van de velden in FM dezelfde is als in je Excel staan ze meteen goed. Je zou een record aan kunnen maken waarin je de gewenste kolomnamen neerzet, daarna sorteer je de records zodanig dat het eerste record het record met deze kolomnamen is, Vervolgens exporteer je naar excel (zonder de veldnamen van FM als kolomnamen te gebruiken). Je kan een virtuele lijst maken, dat is een extra tabel die alleen maar voor weergave en export dient. Je kan de veldnamen dan zo aanpassen dat ze aan jouw wensen voldoen. Zie bijvoorbeeld http://www.mightydata.com/blog/virtual-list-in-three-easy-steps/ en http://www.modularfilemaker.org/module/virtual-value-list/ Er zijn nog meer mogelijkheden, maar dit zijn een paar bruikbare en redelijk eenvoudige manieren. Ik heb zelf wel eens een xslt gemaakt icm xml en daarmee excel 2003 xml-formaat gemaakt. Werkt ook prima, snel en de excel is meteen mooi opgemaakt, met individueel opgemaakte kolommen etc. Het is alleen nogal veel werk om te maken en je hebt veel uitzoekwerk om het goed werkend te krijgen.

Door zowel in de basistabel als in de gegevenstabel alle velden te concateneren kan je een soort OR relatie leggen. Kijk in het bijgevoegde voorbeeld (is het bestand van Felix in aangepaste vorm) OR.fmp12

Een controleberekening kan je doen met een "11-proef". Een voorbeeld kan je vinden op de site van Brian Dunning (deze is gemaakt door mijn oud-collega Hartger). Het laatste cijfer van het BSN fungeert als controle-getal voor de rest van het BSN. (dus hier is ook de vaste lengte van 9 getallen weer van belang) Het BSN is geen getal, het bestaat alleen uit cijfers en is 9 karakters lang, dus het moet een gewoon tekstveld zijn dat je zal moeten filteren op 0-9 en controleren op de lengte van 9.

Ja dat klopt, volgens FMI is deze update er enig en alleen om een kwetsbaarheid in de SSL-implementatie van FileMaker op te lossen. Het versienummer is van 13v5 naar 13v9 gegaan omdat FileMaker Go op 13v8 zat en met deze update hebben alle producten hetzelfde versienummer.