marspan

Bij een klant zijn we (eindelijk) overgegaan van FileMaker 14 (server en clients) naar FileMaker 17. Bepaalde portalen zijn bij sommige gebruikers nu soms, en pas na enige tijd, leeg. Alleen herstarten van FileMaker Pro helpt dan. Heeft iemand een idee waardoor dit kan komen? Het gaat om 2 portalen, en beide hebben een relatie die op diverse velden is gebaseerd.

Ha Menno, Hartelijk dank!

Vaak komen er afspraakuitnodigingen mee met een email, in de vorm van een ics-bestand. Daarin staan alle gegevens van de afspraak in iCal-formaat (RFC 5545). De bedoeling is nu om van zo'n afspraakuitnodiging een FileMaker-afspraak te maken. Ik ben bezig custom functions te ontwikkelen om de gegevens uit zo'n ics-bestand te halen. Dat gaat heel aardig, maar nog niet altijd goed. Vervelend is dat het iCal-format erg veel vrijheid biedt, zodat je er nooit zeker van bent hoe bepaalde zaken vermeld worden in een ics-bestand, omdat elke agenda (Outlook, Google, iCal en noem maar op) zaken anders weergeeft. Maar met wat moeite kom ik daar wel uit. Of weet iemand een kant en klare oplossing: plug-in / javascript / custom functions? Er is één belangrijk probleem waar ik niet goed raad mee weet: zomer/wintertijd-correctie. Afspraken worden (gelukkig) meestal weergegeven in UTC-tijd, bijvoorbeeld: DTSTART:19970903T163000Z DTEND:19970903T190000Z is een afspraak op 3 september 1997 van 16:30 tot 19:00 in UTC-tijd (de Z aan het eind). Het uur-aantal berekenen waarmee een tijd moet worden gecorrigeerd voor DIT moment kan met de formule: hour( Get ( CurrentTimeStamp ) - GetAsTimestamp ( Floor ( Get ( CurrentTimeUTCMilliseconds ) / 1000 ) )) (Berekening van: BowdenData 1-aug-2014 op https://community.filemaker.com/thread/77489) Maar dat is voor NU. Hoe doe je dat voor een willekeurige datum in de toekomst (en dan dus ook in het verleden)? Of moet je een tabel gebruiken van de datums waarop zomer- en wintertijd in gaan?

dit is de tekst.

Dank voor de reacties. Zo'n substitute gebruikte ik ook, en die werkte op Mac vlekkeloos. Gisteravond begreep ik eindelijk wat de oorzaak van het probleem was. Je moet xml bestanden liefst wegschrijven als UTF-8. Ik gaf helemaal geen codereng op. Wij gebruiken de Troi File plug-in om de exportbestanden weg te schrijven en te vullen, en die heeft daarvoor gewoon een switch ( -encoding=UTF-8 ), het kan haast niet eenvoudiger. Voor de zekerheid ook in de xml expliciet aangegeven dat het de encoding UTF-8 is, en het gaat nu helemaal goed. Geen substitute nodig, op de tekens na die echt niet in xml mogen staan, zoals < > etc.

Bij het exporteren in xml-format - niet via XSLT, maar met een eigen systeem met enkele custom functies - moet alle tekst er xml-veilig uitkomen. Behalve het encoderen naar 'echte' xml tekens - zoals > naar > - mogen er ook geen diakrieten in voorkomen, zoals ï of è of ñ. Daarvoor heb ik een cf gemaakt met een uitgebreide substitute, die het op Mac uitstekend doet en alle diakrieten omzet naar hun kale versie, in dit geval i, e of n. Maar op Windows werkt het niet of niet goed. In eerste instantie had ik alle diakrieten gewoon ingetypt, in tweede instantie heb ik ze vervangen door hun Char( ) variant. Ook dat helpt niet. Zou het kunnen komen omdat die cf wordt aangeroepen binnen de berekening van een variabele? We werken momenteel nog onder FMP11, binnenkort gaan we over naar 14. Kan het met 11 te maken hebben?

Wij gebruiken een web viewer om de inhoud van gekoppelde bestanden te viewen, voornamelijk pdf en Word. Sinds de klant is overgegaan naar Word 2010 zie je in de web viewer de complete Word toolbar. Je kunt er niets mee doen, er is geen knop die werkt, en hij neemt veel ruimte in. Is er een manier om dat ding niet te tonen? In dit geval werken we nog met FMP 10/11 en onder Windows.

Nog even voor de duidelijkheid: mijn verslagje gaat over FM pro versie 11, niet om versie 12, niet om FMServer. En het werkelijk problematische is dat steeds weer niet-responsief zijn. Wie heeft ervaring met FMP11 onder Mavericks?

Ik heb eergisteravond Mavericks geïnstalleerd over de laatste versie van 10.8 en mijn ervaringen waren niet goed. Exporteren. Het eerste wat ik merkte was dat FMP11 advanced (maar ik kan me niet voorstellen dat de gewone 11 het wel zou doen) niet meer kon exporteren, want daar was Rosetta voor nodig, was de melding. Dan maar via de Troi File plug-in, dat kon in dit geval wel, het maken van een export van banknummers voor conversie naar IBAN. Maar er zijn allerlei exporten waar dat geen optie is. In de loop van de dag begon FileMaker steeds meer te haperen. Dat je even niet kunt typen in de script-omgeving, of in de velddefinities. Ik kreeg de indruk dat dat ook steeds langer begon te duren en steeds vaker optrad - het was meer dat je af en toe wel kon typen, dan het omgekeerde. Activiteitenmonitor liet zien dat FMPa11 voortdurend stond te flipperen tussen 0 en 15 of 25% terwijl ik niets aan het doen was. Nog niet al onze klanten zijn over naar 12 en de overgang is geen sinecure. Het is mijn werk, dus dit kan niet. Ik ben nu bezig de vorige versie terug te zetten vanuit mijn Time machine back-up van de dag ervoor. Nog niet zeker of dat helemaal goed gaat.... Iemand anders ook deze ervaring?

Ik denk ook niet dat de combi FMP10/WIN8 de oorzaak is, maar ik hoop op reacties van 'ervaringsdeskundigen'.

Heeft er iemand ervaring met FMP 10 op een Windows 8 machine? Ik weet dat FileMaker Inc. dat niet ondersteunt, maar het draait wel, alleen langzaam. De vraag is, ligt dat aan de combi FMP10 + Windows 8 of is er iets anders aan de hand, zoals bijvoorbeeld een te aggressieve virusscanner.

De duur van de back up is puur een hardware kwestie. Hoe sneller de hd, hoe sneller de bu. FMS 12 is zeer efficient ein bu's: als er niets in een bestand is veranderd verwijst de bu naar een oudere bu. Misschien kun je dat ene grote bestand splitsen in een bestand waar veel in wijzigt en een waar weinig in wijzigt. Hardware: van en naar een SSD en dan daarna door het OS naar een harde schijf, bijvoorbeeld. Beetje meer lezen, beetje meer nadenken, beetje minder klagen.

Dat suggereert dat jij vermoedt dat WINWORD de oorzaak is, maar ik denk dat de webviewer het probleem is. Het lijkt er op dat de webviewer het bestand niet vrijgeeft, ook al maak ik de webviewer uitdrukkelijk leeg. Het bestand wordt getoond in de webviewer met de opdracht "data:text/html,file://" & bestandspad. Voordat het bestand wordt geopend wordt de webviewer geleegd, door hem in te stellen op "data:text/html," - dus zonder iets daarachter. Is het verstandiger een andere opdracht naar de webviewer te sturen, of om het venster met de webviewer er in te sluiten? Of nog iets anders?

Situatie: word-doc tonen in webviewer. Dan het bestand openen in Word via de Troi File plug-in, mbv launch( pad ). Voordat het bestand wordt geopend, wordt de webviewer geleegd en even gewacht. Desondanks blijft het bestand bezet, en kun je in Word niets doen, zelfs geen menu opentrekken. Als je nu WINWORD killt en het bestand opnieuw vanuit FMP opent, kun je het wel bewerken. Heeft iemand een idee hoe dit gedrag te voorkomen?

Het blijkt wel te kunnen! Op FMGo moet er niet "files:///Volumes" voor het pad staan! Hoe eenvoudig. Antwoord via het FileMaker Developer Forum gekregen.