Banach

Even voor mijn beeldvorming; waarom wil je weten of een database op een lokaal of een remote volume staat? Wanneer het om een bestand onder FMS gaat krijg je trouwens fmnet:/... terug bij Get[filepath]

Kijk eens hier: http://www.filemakertips.nl/?p=406

Kan het zijn dat je een relatie met de tabel zelf hebt? Wanneer dat een relatie op artikel is met daarbij aangegeven dat ook de gerelateerde records moeten worden verwijderd wanneer een record verwijderd wordt is dit gedrag geen fout van FMPA maar van....

Probeer het eens terwijl Outlook is afgesloten (niet draait).

sterretje er achter.

Kies in het afdrukvenster voor - alleen huidige record - ipv reeks van records: Zorg er wel voor dat je op het juiste record staat.

Je hebt niets extra nodig: http://www.filemaker.com/help/14/fmp/nl/html/scripts_ref1.35.47.html#1144639

Academisch gezien zal je bovenstaande als onzin moeten kwalificeren. Men gaat hier voorbij aan het verschil tussen een tekenset en een encoding. Ook de bewering dat dit 'up to two bytes of information per character' nodig heeft is 100% onjuist. Daarmee zou je immers slechts zo'n 65.000 tekens kunnen vastleggen. De huidige Unicode standaard bevat zo'n 113.000 tekens, dus dat red je niet met 2 bytes. Ook ga je, academisch gezien, twijfelen aan andere informatie in FTS (waar staat dat voor?) wanneer men in 1 zin al tweemaal onzin schrijft. Of is men bij Filemaker blijven steken bij Unicode versie 1.1 van meer dan 20 jaar geleden (1993)? Ik ben het met Peter eens dat een leerboek voor specialisten 100% juist moet zijn, dat lijkt hier niet het geval.

Een must read artikel over Unicode en encodings is dit: http://www.joelonsoftware.com/articles/Unicode.html van Joel Spolsky. Ook zijn andere artikelen zijn trouwens het lezen meer dan waard. Hij geeft aan dat UTF-8 uit 1 tot wel 6 bytes kan bestaan. UTF-8 is zodanig geconstrueerd om in de eerste 127 codepoints exact de ASCII tekens te bevatten. UTF-8 heeft dan maar één byte nodig. Dit houdt dus in dat wanneer je tekst hebt die niet voornamelijk uit ASCII tekens bestaat je vaak meer bytes nodig hebt om het juiste Unicode teken weer te geven. Heb je alleen Engelstalige tekst dan zult je in 4GB meer tekst kunnen opslaan dan tekst in een Europese taal. De Aziatische talen hebben in een UTF-8 representatie nog meer ruimte nodig zodat je in 4GB nog minder tekst in zo'n taal kwijt kunt. Aan de andere kant is 4GB aan tekst in FM verre van praktisch. Al bij enkele tientallen MB's heb je seconden lang die vervelende strandbal in beeld, simpelweg voor de presentatie van de eerste paar regels van een dergelijk veld.

Klopt. 14v1 is destijds onder 10.10 geïnstalleerd. Dank voor je suggesties. Ik wacht dan wel even op een versie van de update die wél compatibel is met 10.11

Het lukt mij niet om onder Mac OS X 10.11 een FileMaker Server 14v1 te updaten naar 14v3. De melding dat FMS nog running is blijft maar komen en de update wil niet draaien. Alles proberen te stoppen met de opdracht sudo launchctl stop com.filemaker.fms van een forumlid alhier, maar ook dat gaf geen oplossing. De logviewer geeft aan dat alles gestopt is: In het status opverzicht draait er ook niks meer: Web publishing staat ook uit. Toch hou ik deze foutmelding: Ik weet het even niet meer. Weet iemand wat ik nu moet doen?

Heb je al een complete reset van je iPad gedaan? Dit wil nog wel eens wat rommel opruimen waardoor e.e.a. weer wat soepeler loopt. Maar idd IOS9 is niet zo geschikt voor de iPad 2. Ik zal het niet zo gek vinden dat men zo langzamerhand de voorkeur aan Android tablets danwel WIndows tablet zal gaan geven. Niet zo direct vanwege het OS maar toch wel vanwege de prijsstelling.

Unicode is wat anders dan UTF-8 of UTF-16. De laatste twee zijn 'encodings'. De basis voor deze encodings is Unicode, maar is dus niet hetzelfde.

Wanneer je dan toch al vanuit de tabel met de gerelateerde records (CONTACTEN) die records van een bepaalde klant wilt hebben is een eenvoudige zoekopdracht op records met dat klantnummer nog weer een stuk simpeler. Je hebt dan GTRR helemaal niet nodig.

viewtopic.php?f=46&t=9210

Zie daar het probleem. Wanneer je gerelateerde records wilt zoeken moet je dat vanuit het hoofdrecord (parent) doen en niet vanuit die gerelateerde records. In mijn voorbeeld van KLANTEN en CONTACTEN zul je de GTRR opdracht moeten uitvoeren vanuit een layout met TOC KLANTEN. Doe je dit vanuit een layout met CONTACTEN als TOC dan weet je niet bij welke klanten je de contacten zoekt. Dit kan wel maar dan moet je e.e.a. anders inrichten. Hier geldt dat je eerst naar de layout met TOC KLANTEN moet gaan voordat je via GTRR de bijbehorende CONTACTEN kunt vinden.

GTRR (Go To Related Record) werkt vanuit de TOC (Table OCcurence) die aan de layout gekoppeld is vanwaar uit je de GTRR opdracht uitvoert. Dit heet de context. Wanneer je een knop hebt met enkel de opdracht GTRR doe je dit vanuit een bepaalde context. b.v. vanuit een layout met de TOC van KLANTEN en geef je aan dat je via de relatie CONTACTEN de aan die bepaalde klant gekoppelde contacten wilt zien. In een script wordt de context bepaald tijdens het runnen van het script. Wanneer je dan het script met GTRR laat runnen vanuit een layout met een TOC die geen enkele relatie heeft met CONTACTEN, b.v. de PRIJSLIJST zullen er geen records uit CONTACTEN getoond worden omdat er geen relatie tussen deze twee TOC's bestaat. De oplossing is dan ook om in het script eerst de juiste context op te roepen. Dat kan door je script te laten beginnen met een opdracht als Go To Layout waarbij je dan de layout aangeeft met de TOC KLANTEN. Vervolgens worden alleen CONTACTEN getoond wanneer er ook daadwerkelijk contacten aan het klantrecord gekoppeld zijn via de in de GTRR aangegeven relatie.

Bestand even sluiten in FMserver en dan met FMPro client je instellingen goed zetten. Daarna kun je het weer openen in FMserver

De V2 map terugzetten van je backup en dan rebuilden is zomaar een suggestie. Maar dit is geen Apple forum Wanneer rebuilden bij veel mensen wél de oplossing is wil het m.i. zeggen dat er sowieso al een fout in de mailbestanden zit. Dus al voordat je bent gaan updaten. Dat er problemen zijn met El Capitan wil ik niet ontkennen maar daar zijn andere fora voor.

Klopt. En de oplossing staat er ook bij; postbussen rebuilden.

Let op, de Filemaker grafieken werken niet in runtime oplossingen!

Danny, val de IT verantwoordelijken niet al te veel af, want wie worden geacht de veiligheid en betrouwbaarheid van het netwerk te waarborgen? Ieder zijn vak zal ik maar zeggen.

Dat vind ik dan weer niet. Maar laat dit geen discussie zijn over het platform. Het ligt er immers maar aan wat je gewend bent. Wel zou men bij FileMaker wat meer aandacht mogen hebben voor veranderingen in de platforms die men zegt te ondersteunen.

Toch raar dat dit pas weken ná de introductie van 10.11 komt. Je zou haast denken dat FileMaker Inc helemaal niets met Apple te maken heeft en ze geen mogelijkheden hebben om dit van tevoren even uit te testen. Hebben we dit niet al eens eerder meegemaakt? Ik vind dit uitermate knullig.

Ik zie geen meldingen van deze problematiek op de NL apple fora. Daar zou dit toch wel snel opgepikt zijn, niet? Weet je dan zeker dat dit een algeheel probleem is van 10.11 of alleen iets dat onder zeer specifieke omstandigheden optreedt. Een backup maken vóórdat je gaat updaten is trouwens nimmer een overbodige luxe, dus maak een backup, ga updaten en kijk of je dit probleem kunt reproduceren. Een probleem dat overigens niets met FM maar alleen met Apple Mail te maken heeft denk ik zo.