Philip Van Landuyt

Probleem opgelost, foutje ingeslopen, en niet gezien

Ik heb een database op FileMaker Cloud staan. FileMaker Cloud vereist encryptie. In de database zit een tabel waarbij ik foto's extern bewaar (secure). Als ik nu een update van de oplossing wil doen (importeren van alle data in een lege versie), doe ik eerst een download van de database in de cloud. Op het moment dat ik iets wijzig aan de oude database (encryptie verwijderen via Tools, wijzigen van de naam van de (gedownload) database) verdwijnen alle records in die tabel. Iemand enig idee wat hier gaande kan zijn ? Groetjes, Philip.

Als je FileMaker opent in Rosetta (Get info van de FileMaler app, open using rosetta aanklikken) werken niet aangepaste plug-ins wèl. Het mist een beetje het punt, maar voor wie de nieuwe versie wil gebruiken is het wel een workaround.

Peter, Net geprobeerd met een Vasco DP905 (v2.0), en dat blijkt te werken. Wij zullen verder experimenteren. bedankt in elk geval. Groetjes, Philip.

Wij zijn een jarenlange gebruiker van de eID plug-in, Voor zowel Mac als Windows. Aangezien MyFMButler de ontwikkeling en support voor hun producten heeft stopgezet, zijn wij op zoek naar een alternatief voor de eID plug-in. MBS biedt enkele mogelijkheden, maar heeft iemand weet van andere alternatieven ? Groetjes, Philip.

Bestes, Hard opletten vooraleer je beslist om de upgrade naar 19.1.2 uit te voeren. Er is namelijk een probleem met het maken van DDR files: Zie ook https://support.claris.com/s/article/FileMaker-Pro-19-1-2-crashes-when-creating-a-Database-Design-Report?language=en_US met vriendelijke groeten, Philip Van Landuyt

Beste Forumleden, Wij hebben een oplossing draaien bij verschillende klanten (zowel single user als multiuser). Deze oplossing wordt intern verder ontwikkeld, en als we een update bij klanten installeren doen we een (geautomatiseerde) import van hun gegevens. Dat gebeurt als volgt: Ik heb een aantal layouts gemaakt met als naam 'IMP_' + de naam van de tabel (bv IMP_CONTACTEN). Op die layout doe ik éénmaal een manuele import. Tijdens de update vertrek ik met een leeg doelbestand, en sla het pad van het bronbestand op in een variabele. Daarna ga ik in een script doorheen alle layouts, en importeer alléén als de bestandsnaam begint met 'IMP_'. De importvolgorde wordt niet meegegeven, FileMaker onthoudt die van de manuele import. Echter, sinds FM 18, vergeet FileMaker die importvolgorde, en doet dat nogal consistent. Hij importeert telkens de eerste tabel die we ooit hebben aangemaakt. Dat is nogal vervelend, dan moeten we doorheen een 40-tal layouts lopen om die import weer goed te zetten. Ik kan natuurlijk een script maken om alle tabellen scripted te importeren, maar dat is naar onderhoud een pak omslachtiger. Iemand een idee ? Philip Van Landuyt

Geen succes. Het enige wat ik te weten kom is dat het een Windows OLE object is. Andere info krijg ik niet te pakken. Bij het converteren naar FMP12 formaat is geen info meer beschikbaar, en werkt ook OLE niet meer. In FileMaker 11 werken sommige van de links wel nog, maar de FileNaam kan ik niet in een veld krijgen. Manueel meer dan 3000 files opzoeken en terug importeren is niet direct een optie.

Beste FM Collega's, Ik heb een project waarbij ik een oude (zelfgemaakte) FP7 database moet ombouwen naar de laatste technologie. In de oude database zitten een aantal container velden, waarin documenten zijn opgeslagen met 'insert object' (rechter muisknop). Deze bestanden zijn beschikbaar op een fileserver, maar ik moet wel de bestandsnaam kunnen recupereren. Dan kan ik (gescript) de documenten terug importeren en door FileMaker op de server laten bewaren. Heeft iemand een idee hoe ik de bestandsnamen van een ingevoegd object ik een (tekst-)veld kan zetten ? Oude situatie: W10 Pro, FM10, Database is single user, staat op een FileServer, samen met de geïmporteerde documenten. Nieuwe situatie: W10 Pro, FM16, FMS16 Groetjes, Philip.

Dag Peter, Ik vermoed dat dit te maken heeft met wat de remote 'server' doet. Enkele voorbeelden met bijgevoegde screenshots: vanlanduyt.eu is een domain waar alleen een mailadres op zit, geen andere functies: 13 milliseconden (waarschijnlijk reactie van DNS, ERR_NAME_NOT_RESOLVED ) Elvee.eu en Clarify zijn wel geldige domains, met functies: resp: 30216 en 6210 Milliseconden De twee blurred URL's zijn mijn development server, vanop afstand. Eénmaal met de database "AYD_Server" gesloten, en éénmaal met de database in normale geopende toestand. Ik vermoed dat hier FMServer zelf direct doorgeeft dat de database niet beschikbaar is, vandaar de snelle reactie. Groetjes, Philip.

"Nou breekt mijn klomp" zeggen onze noorderburen. Ik heb eens getest met "nu.nl", en inderdaad: 80 seconden. "fileMaker.com" geeft 10 seconden. Mijn eigen testservertje: tussen de 0,1 en 3 seconden. Ik vermoed dat dit met caching te maken heeft. Ik zoek bij gelegenheid eens verder. met mijn excuses voor de "dooie mus" Groetjes, Philip.

Bij mij lukt dat meestal in minder dan een seconde. Ik heb een voorbeeldje bijgevoegd, met zowel een server als een locale database. De locale database roept een scriptje aan in de server database, die dan een antwoordje geeft, met datum en tijd erbij. Paswoord voor beide files: Admin - Admin. Let op: je moet wel testen op Get (LastError) = 0, je kan immers nog andere fouten terugkrijgen. Philip AYD.zip

Je kan ook het extern script aanroepen via een "open URL" scriptstap, en dan het fmp: protocol gebruiken. als je daarop een fout "802 - Unable to open file" terug krijgt dan is het extern bestand niet beschikbaar. Naar mijn gevoel loopt dat veel sneller. Bij mij (vanop Mac naar mijn development servertje over internet: minder dan één seconde) Groetjes, Philip.

Andries, Jou opmerking over die Cache houdt steek ! Ik heb in mijn scripts een refresh windows met flash Cache gezet, en voorlopig lijkt dat te werken! Bedankt voor het meedenken ! met vriendelijke groeten, Philip Van Landuyt

Ik heb inderdaad gecheckt. Als ik het veld op de layout zet, krijg ik de juiste waarde, maar de relatie werkt alsof de oude waarde gebruikt wordt. Let wel dit is slechts zo voor enkele records.