bigbadwolf

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.

Misschien door een pdf te maken en die via een shellscript naar een printer te sturen?

Is een bekend probleem… Waarschijnlijk heb je een ‘onLastWindowClose’ script trigger? Dan staat daar zeer waarschijnlijk een Close File in. In het verleden werd dit genegeerd, nu wordt daarmee het volgende actieve venster gesloten… een soort van Droste-effect dus… want als die ook een Close Window heeft… etc. Oplossing is in het script de Close Window eruit te halen. Maakt niet uit of het Windows of macOS is…

Yep. Wireshark is er ook voor macOS. https://www.wireshark.org/download.html

Zou mogelijk moeten zijn, het is ‘gewoon’ een QR-code. Denk alleen wel dat je iets nodig hebt om hem te ‘begrijpen’. Gewoon een foto maken met je iPad/iPhone snapt FileMaker niet, dan krijg je een foto van je scherm. En als je met je camera de code scant geeft hij aan er niets van te snappen.

Ik twijfel er niet aan dat we iets over het hoofd gezien hebben. Morgen gaan we met een verse PC aan de slag, dus hoop ik in ieder geval aan de client kant schoon te starten. Pakken we er morgen gelijk het artikel bij. Dank voor de link.

We zijn een nieuwe server aan het optuigen (draaien nu op 17, wordt tijd om naar 19.3 te gaan)… maar wat ons voor nu tegenwerkt is dat de benodigde ODBC-koppeling niet wil werken. En helaas is dat een optie die nodig is om verder te komen. Server is nieuw geïnstalleerd met 19, en vorige week bijgewerkt naar 19.3. Voor zover ik kan zien staat alles aan en open, maar vooralsnog krijgen we op de ODBC geen response. Het enige wat (nog) ontbreekt is een SSL certificaat, maar voor zover ik kan beoordelen zou dat niet noodzakelijk hoeven te zijn voor de verbinding. Iemand nog een idee waar we kunnen kijken?

Dank… ik heb een API-key, maar toch lukt het (nog) niet. Authorisatieproblemen. Zal ze eens aan hun jas trekken waarom het niet lukt.

Voordat ik er zelf tijd in ga steken om het wiel opnieuw uit te vinden… heeft iemand toevallig ervaring met het opzoeken van postcodes bij Postcode.nl? Ik weet dat ze een API hebben, maar als iemand dit al eens gedaan heeft en het wil delen…

Eigenlijk mogen we nog blij zijn dat het door deze ‘truc’ toch nog werkt. Ze zijn er gek genoeg voor om de API gewoon helemaal de nek om te draaien…

Heb één van mijn servers bijgewerkt naar 19.3.2. Ben benieuwd. Update verliep voorspoedig, behalve dat ze kennelijk een hekel hebben gekregen aan php, want die wordt nog steeds gewist.

Het zou inderdaad eens tijd worden… die hebben ze al lang geleden beloofd… De aanpassing van EULA zou niet nodig zijn geweest als FileMaker een redelijk bedrag zou vragen voor ‘web’-licenties. En dan niet voor iedere mogelijke gebruiker een licentie, maar gewoon gelijktijdigheid.

Kleine nuance… de Close File wordt niet genegeerd, hij sluit het volgende bestand. Als dat bestand dan vervolgens ook weer een Close File in het sluitscript heeft zal die ook weer de volgende sluiten. Dus in plaats van negeren omdat het bestand al gesloten is wordt de actie uitgevoegd op het volgende bestand wat geselecteerd wordt.

Sinds gisteren is er een patch voor FileMaker 19.3. En één ding is niet gecorrigeerd (ook als is het misschien een overbodige stap)… wanneer je in een sluitscript Close File gebruikt sluit hij nog steeds alle databases die je open hebt staan. Normaal negeert FileMaker onlogische stappen, maar kennelijk heeft een licht bij Claris ervoor gekozen dit bij deze stap niet te doen. Helaas zullen zij het niet als een BUG zien, maar iets wat altijd gewerkt heeft ineens veranderen is geen goede keuze.

Verbaasd me niet dat dit niet herkend wordt. De Json_Line is vermoed ik een veld in je database waar je zelf JSON ingezet hebt? Ik heb het eerder gezien. Eigenlijk zouden we een (text)object moeten kunnen markeren zodat je kunt aangeven dat het JSON-content heeft. De reden waarom je dit krijgt is omdat de API het ziet als ‘gewone’ tekst, het kan geen onderscheid maken op basis van de inhoud.

Dat zullen ze niet snel honoreren… daarvoor heb je al scripttriggers en sorteren… Je idee is niet verkeerd, maar staat me iets van bij dat er al iets op de Community site staat waar je ook kunt stemmen.

Dit zou je op kunnen lossen door je CF parameters als JSON mee te geven… ;o)

Zal ik niet uitsluiten… maar het is en blijft een probleem van Claris wat ze op moeten lossen… en helaas is het geen optie om terug te gaan naar Mojave. Voor nu heb ik 19.3 er maar weer afgegooid en ben terug naar 19.2. Denk dat ik maar wacht op een volgende update. Zoveel spannends is er niet te vinden in deze update.

Bestanden hebben geen link met elkaar, en tot 19.2 werkte het allemaal prima. Ik draai op BigSur en server 19. Ben er inmiddels wel achter wat het probleem veroorzaakt. Wanneer je een ‘onLastWindowClose’ gebruikt sluit hij niet alleen zichzelf af, maar ALLE openstaande bestanden. Niet bepaald de bedoeling als je alleen maar het huidige bestand wilt afsluiten. Voor de goede orde… dit deed hij t/m 19.2 niet, en de scriptstap is Close File (Current File).

Ben benieuwd of ik de enige ben… maar als ik nu een bestand sluit terwijl er meerdere open staan worden ze ineens allemaal gesloten…