bigbadwolf

Nog een reden om Exact niet aan te bevelen… nooit fan geweest, maar als ik dit lees zal ik het waarschijnlijk ook nooit worden…

Dit was zeker wat… Wederom heeft mijn aversie voor Windows er een turfje bijgekregen. Het is toch te zot dat je een pdf niet kunt schrijven zonder dat je de benodigde fonts hebt. Natuurlijk hij zal er niet uitzien, maar het hele idee achter de pdf is ook dat er een techniek in zit die zijn best doet het te evenaren. De fonts zijn opnieuwe geïnstalleerd en nu wel voor ALLE gebruikers. Moet zeggen… FileMaker gaat in dit geval niet vrijuit. Het wordt echt tijd dat ze hun foutmeldingen beter op orde krijgen, zij zouden in plaats een algemene ‘kan niet geschreven worden’ ook eens moeten nadenken over iets meer terugkoppeling. Immers… zijn weten/kunnen weten waarom hij niet geschreven kan worden. Dat ik niet in eerste instantie aan de fonts dacht heeft mogelijk ook te maken met de gelijktijdigheid van de introductie van OneDrive op de systemen. Gelukkig geldt in dit soort gevallen dat het resultaat telt… en dat is dat het opgelost is. Dus mocht iemand hier nog eens tegenaan lopen en zeker weten dat de toegang tot de schijf en de naamgeving het probleem niet zijn… installeer de fonts opnieuw (voor ALLE gebruikers).

Kan ik me niet voorstellen. De ‘eigenaar’ van de App staat log van de functionaliteit. Alleen als je de App wilt updaten zal hij vragen naar de login van de het andere AppleID. Denk eerder dat het een configuratieprobleem is (al moet ik bekennen dat ik niet zo snel weet waar je het moet zoeken).

Dat is dus niet waar… in hetzelfde script worden xlsx-bestanden gemaakt die wel geschreven worden… Het lijkt zich vooralsnog toe te spitsen op de pdf.

Als ultieme oplossing had ik ook in die richting zitten denken. Liever niet, maar als het dan wel werkt… Op de server draaien we met MBS dus het in de container krijgen van de pdf is geen probleem.

Dat fenomeen ken ik, maar in dit geval zou dat niet logisch zijn. Op macOS mag het wel (dat zou nog kunnen), maar ik heb getest op systemen die géén OneDrive hebben en daar is het wel ok. Dus verboden tekens zou vreemd zijn, dan zou het op die systemen ook niet moeten werken. Op deze systemen heeft het ook gewerkt… totdat OneDrive geïnstalleerd werd.

We hebben ook getest op niet OneDrive PC’s. Daar gaat het goed, dus we kunnen redelijkerwijs vaststellen dat het script niet het probleem is (hoewel er een grijs gebied blijft). Bewaren op de desktop heeft geen zin, die is overgenomen door de OneDrive. Vreemd genoeg worden in dezelfde sessie (soms) ook Excel-bestanden gemaakt die wel zonder problemen bewaard worden. Maar ook wanneer ik het temporarypath gebruik komt hij met dezelfde (vage) foutmelding (800, wat vervolgens eigenlijk volstrekt weer niet zegt waarom het bestand niet geschreven kan worden, alleen dat het niet geschreven kan worden… nog een lange weg te gaan voor FileMaker in duidelijk zijn waarom iets niet werkt). Dank voor het meedenken. We blijven voorlopig nog even zoeken naar de ultieme oplossing (helaas is dat niet OneDrive in de trash schuiven).

Ben er nog niet helemaal uit, maar ik heb het ook nog even op een andere PC getest en daar werkt het wel goed (net als op mijn eigen Mac). De enige onbekende factor in het verhaal is dat de systemen waar het niet op werkt hun documenten standaard bewaren op een ONE Drive. Maar of dat invloed heeft?

Geen idee waarom dit ineens zo is, maar een script wat al langer in gebruik is mag ineens geen pdf meer bewaren. Het pad wat ik gewoonlijk gebruik is get ( TemporaryPath ) & "bestandsnaam.pdf". Niet zo heel veel bijzonders zou je zeggen. Een tijdelijk script wat ik gemaakt heb wat een pdf op dezelfde plek wil schrijven heeft er echter geen problemen mee. Kennelijk zie ik iets over het hoofd, maar de logica ontgaat mij op het moment even. Hopelijk heeft iemand nog een idee waar ik kan kijken.

Soms ligt de focus zo op het lastige dat je het voor de hand liggende niet meer doet… ;o)

Nooit wat van gemerkt. Is volgens mij ook niet zo (misschien de eerste query als er nog geen indexen zijn).

Dat weet ik, maar het is juist de bedoeling om het WEL te kunnen gebruiken. Dus als ik het op de lay-out uitzet werkt het helemaal niet meer.

Het heeft even tijd gekost, maar ik ben toch maar op een kopielay-out elk object afgegaan en gecontroleerd of de quickfind aan staat… en ergens diep verborgen stond er toch nog eentje (gerelateerd) die wel aan stond. Blijft wonderlijk dat hij dan toch zo langzaam werd want die gerelateerde tabel heeft ook maar een kleine 7.000 records. Dank voor jullie response.

Als je 7 seconde moet wachten op een resultaat, dan is dat in mijn beleving ook niet meer gemakkelijk… Ik heb als test de drie velden op een nieuwe lay-out gezet en dan is de response direct… dus kennelijk zit er iets op de lay-out wat de storing veroorzaak. Dus wat rest is de lay-out stukje voor stukje ontmantelen om te zien waar het ‘verborgen’ element zit wat stiekem toch meedoet in het zoeken. Vervelende is dat je niet in één keer kunt opvragen welke elementen op de pagina meedoen met de quickfind. @Marsau: juist het feit dat je een overall zoek kunt doen maakt het prettig. Vroeger gebruikt ik het ook bijna niet, maar tegenwoordig pas ik het regelmatig toe. En over het algemeen ben ik er tevreden over. Alleen in dit specieke geval niet erg…

OK. Misschien een wat overdreven statement, maar niet geheel zonder reden. Wat mag je verwachten als je een lay-out hebt met welliswaar tientallen velden, maar waarvan er slechts 3 actief zijn voor de quickfind. Je zou toch zeggen dat een resultaat binnen een ‘vloek-en-een-zucht’ gevonden zou moeten kunnen worden. Alle (3) velden zijn geïndexeerd en… de tabel bestaat uit net aan 400 records. Toch kost het FileMaker ruim 7 seconde om een resultaat tevoorschijn te toveren. En nee, de drie velden zitten niet vol met data. Al met al is het waarschijnlijk nog niet eens een A4-tje aan tekst. Het waarom is mij een volkomen raadsel.