Jump to content
  • 0

Server side script en externe tabellen


Marsau

Question

Server side script en externe tabellen

 

Een raadsel..

 

Ik werk aan een bestand dat niets anders doet dan twee systemen synchroon houden. Een synchronisatie-systeem dus. Het draait op server A, waar ook het bron-systeem staat, en synchroniseert met verschillende sets van logische regels naar systeem B, dat op een andere server staat. Het relatieschema bevat de relevante tabellen van beide systemen, en deze zijn verbonden via sleutelvelden. Ik heb een set van synchronisatiescripts die in één run alle tabellen gelijktrekt. Het is de bedoeling dat dit met een schedeled serverscript gaat werken.

 

Het is een tweede systeem met dezelfde setup, verwijzend naar dezelfde externe server (maar een andere database). Het eerste systeem werkt prima.

 

Het tweede systeem werkt ook prima. Althans vanaf de client. Op het moment dat perform script on server wordt gebruikt, of een handmatige start in de server console, dan krijg ik rotzooi. Nadere analyse leert dat FMS niet is in staat om de externe tabellen te lezen, en dus de informatie met elkaar te vergelijken.

 

Ik denk alles gecheckt te hebben, maar kan het niet vinden. Waarom kan de server het externe bestand niet lezen? En waarom is lokaal openen geen enkel probleem? Heb alles gecheckt, en vooral ook vergeleken met de eerste setup. Kan geen verschil vinden.

 

Hebben jullie ideeën?

Link to comment

25 answers to this question

Recommended Posts

  • 0

Nee, Peter. Nog steeds de hypothese dat dit bij  FMS ≤ 14 niet werkt, zoals ook door jou bevestigd.

Ondertussen doet een robot de noodzakelijke syncs, waardoor de druk om een oplossing te vinden er niet bepaald is.

Klant wil nu niet investeren in een upgrade naar de laatste versie :-(

Link to comment
  • 0

Het is niet mogelijk om de bestanden, tabellen en layouts die op een willekeurige andere FMServer draaien te benaderen vanuit jouw FMServer. Je kan wél scripts triggeren, maar geen enkele data (geen recordinhoud, geen layoutinhoud, ook geen scriptparameters en geen scriptresults. Dat kanaal is volledig dicht, het enige wat je kan doen is een script triggeren, alles gebeurt dan op die andere server en ook alle gegevens blijven daar.

 

Je kan op een client wél op meerdere FMServers bestanden openen en via die client over en weer bestanden openen en data heen en weer laten gooien op allerlei manieren. Je zou dus verwachten dat je dat op een server met PSOS en met server-side-scripts ook zou moeten kunnen doen.

 

Het enige dat je kan doen is in bestand A op server A een PSOS-script aanroepen in bestand B op server B. Op server B wordt dan het script uitgevoerd, maar je krijgt geen enkele feedback, geen foutmelding, helemaal niks. Je kan ook geen script-parameter meegeven, die komt niet aan in bestand B. Verder gaat dit alleen maar als je op de Server A een schedule aanmaakt die het script in bestand A triggert, die dan weer PSOS-script in bestand B triggert.

 

Tijdje terug kwam deze vraag in FMCommunity voorbij en toen had ik er toevallig net zelf iets mee aan de hand gehad.

Link to comment
  • 0

Dank je wel, Menno. Een leerzaam antwoord!

 

Het aanroepen van PSOS in een extern bestand, door de server, is een interessant scenario. Ik zie nog geen directe toepassing.

 

Dat FMS geen externe bronnen kan aanroepen blijft mij evenwel verwarren. Eerder realiseerde ik sync-oplossingen die wel werkten/nog steeds werken.. Ben nog niet echt aan een verschillen-analyse toegekomen, evenwel.

 

Filemaker vermeldt natuurlijk dat bij POS de bestanden op één host moeten staan.

http://www.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Frunning-scripts-on-server.html%23

Ik vond dat niet helemaal duidelijk, want hiermee is nog niets gezegd over TOC's van externe tabellen. Maar zoals jij het stelt, vallen die daar ook onder.

 

Heb het in de tussentijd even opgelost met een robot client.

 

Mars

Link to comment
  • 0

Als je een occurrence van een file die op een andere server gehost wordt, in je FileMaker Relational Graph plaatst, dan kan je ook layouts en scripts maken die gegevens op die andere server manipuleren.

 

Ook server side.

 

Je server side script kan dus wel degelijk aan andere FileMaker servers. Ik weet dit zeker want ik heb zo'n server side scripts lopen. Denk erom dat ik ook veronderstel dat je versie 16 gebruikt.

Misschien werkt dit alleen met schedules, en niet met PSOS (perform script on server).

 

Als je eenmaal zwaar aan de slag gaat met server side scripts, dan merk je dat je echt wel in een gebied terecht komt waar weinig of geen documentatie van FileMaker bestaat. Het is natuurlijk gemakkelijk van FileMaker om te documenteren dat iets niet werkt, en als het dan toch werkt, dan ben je van alle bugs af, want dan noem je zoiets "niet ondersteund".

 

Als je bedenkt hoe schrijnende de bug i.v.m. record locking en server side scripts is, die onlangs op de fmSummit getoond werd, dan is het inderdaad best dat je met client side robotjes blijft werken. Alleen jammer dat je dan extra gebruikerslicenties en meer hardware nodig hebt.

Link to comment
  • 0

ik heb op dotfmp een sessie gezien van iemand (ik weet niet meer wie...) die server side scripts continu in loop had doen draaien.

 

Ik vond het toen maar raar, maar nu gebruik ik dat wel om bijvoorbeeld taken op een tabel allemaal te kanaliseren naar 1 script dat op de server draait, om net die recordlocking, unique validation etc te voorkomen...

Link to comment
  • 0

Is toch fascinerend, Peter. Dat weerspreekt de stelling van Menno en dus ook documentatie van Filemaker (al zou je kunnen stellen dat die niet zo precies is op dit punt).

 

Blijft de vraag waarom het in het ene geval kan werken en in het andere geval niet.

 

Ik laat het robotje voorlopig draaien.

Link to comment
  • 0

Ter aanvulling op dit issue, naar aanleiding van verder onderzoek, en ten behoeve van deze gemeenschap.

Het kan niet en het kan wel. Twee observaties:

- er is een verschil tussen halen en brengen. Je kan gegevens ophalen van van de remote server, en op de lokale server opslaan. Dat levert in ieder geval een eenzijdige sync-mogelijkheid op. Wegschrijven naar de remote server gaat echter niet.

- de versie van de server lijkt relevant. Remote server versie 13 en 14 lijkt niet te werken. Heb echter een werkende opzet met FMS, tweezijdige sync. 

 

Link to comment
  • 0
Citaat

Is toch fascinerend, Peter. Dat weerspreekt de stelling van Menno en dus ook documentatie van Filemaker (al zou je kunnen stellen dat die niet zo precies is op dit punt).

Dat is het inderdaad. En de reaktie van Menno begrijp ik, omdat we hier in een grijs gebied zitten, waar FileMaker nul de ballen documenteert. Als ze straks doorhebben dat ik ondertussen bij sommige klanten met 30 server side robots draai, gaat FileMaker zeker hun licentie schema aanpassen, zodat ze hier ook weer aan kunnen verdienen. Maar ik ben er zeker van dat niemand van FileMaker echt begrijpend leest wat er op de fora gebeurt, dus ons geheim is veilig.

Citaat

- er is een verschil tussen halen en brengen. Je kan gegevens ophalen van van de remote server, en op de lokale server opslaan. Dat levert in ieder geval een eenzijdige sync-mogelijkheid op. Wegschrijven naar de remote server gaat echter niet.

Dat begrijp ik niet. Heb ik nog geen problemen mee gehad. Bedoel je "Set Field" instructies of probeer je de "import" script stap?

Citaat

de versie van de server lijkt relevant. Remote server versie 13 en 14 lijkt niet te werken

Inderdaad. Dit werkt pas vanaf versie 15.

Link to comment
  • 0

Andries, ivm met die record locking. Ik heb een gesprekje gehad met Christian van MBS, en hij vertelde me dat hij mutex objecten gebruikt voor de variabelen. Gezien plug-ins shared memory space gebruikten op de server ( een andere "schitterende" design beslissing van FileMaker ) kan je dus variabelen zonder problemen of crashes lezen en zetten vanuit de respectievelijke robots en zo records en record locking bugs vermijden. Ik heb mijn robot loops omgebouwd, en hierdoor gebruiken ze nu ook nog minder resources van de server. En is het systeem uiterst stabiel geworden, omdat de loops nu alleen maar geheugen gebruiken, en niet met de database interageren.

Link to comment
  • 0
Op 16-3-2018 om 23:50 zei Peter Wagemans:

Gezien plug-ins shared memory space gebruikten op de server ( een andere "schitterende" design beslissing van FileMaker ) kan je dus variabelen zonder problemen of crashes lezen en zetten vanuit de respectievelijke robots en zo records en record locking bugs vermijden.

Houdt dit in dat wanneer ik vanuit een server-side script een (global) variabele instel, dat deze óók geldig is voor een ander gelijktijdig draaiend (server-side) script?

Of gaat het hier om een ander soort variabelen die alleen door (jn dit geval de MBS) plug-ins worden gemaakt? Kan je dat in dat geval hier heel kort uitleggen? Ik ben zeer geïnteresseerd!

Link to comment
  • 0
Citaat

Houdt dit in dat wanneer ik vanuit een server-side script een (global) variabele instel, dat deze óók geldig is voor een ander gelijktijdig draaiend (server-side) script?

Nee, globals zijn daar in de private geheugenruimte van de FileMaker instance zelf.

Citaat

Of gaat het hier om een ander soort variabelen die alleen door (jn dit geval de MBS) plug-ins worden gemaakt? Kan je dat in dat geval hier heel kort uitleggen? Ik ben zeer geïnteresseerd!

Inderdaad. Het gaat over de plug-in geheugenruimte. Het is daar een heel gezellig onderonsje, met alle gevolgen van dien. Daar gaan dus scripts onbegrijpelijkerwijze plots van mislopen, en natuurlijk ook crashen, waarbij natuurlijk met de vinger gewezen wordt naar de plug-in developers, maar het is eigenlijk FileMaker die hier iets heel erg verkeerds doet. Ik merkte dit voor het eerst op toen ik met DoSQL in FileMaker Server 11 problemen kreeg met gevonden sets, en onverwachte crashes. Ik heb toen de vraag gesteld aan Clay Maeckel tijdens de jaarlijkse plug-in developer meeting en stond wel even versteld van het antwoord. Gewoon mee rekening houden was dat.

Maar je kan dit dus inderdaad tot je voordeel aanwenden, tot FileMaker natuurlijk plots plug-in geheugenruimte reserveert per server side proces. Of de hel bevriest, wat er ook eerst gebeurt.  Ik denk niet dat dit op de prioriteitenlijst van FileMaker staat, en moest dat zo zijn, dan zou FileMaker Server ook een ander programma zijn. In een parallel universum. Waar de dieren nog praten. Door dit design kan je dus inderdaad dingen definieren met proces 1, en dan lezen en zelfs veranderen met proces 2,  het moet natuurlijk wel in het plug-in geheugen gebeuren. En daarom was het ook zo belangrijk dat MBS die mutex objecten gebruikt, waardoor de boel niet gaat vastlopen. Als je er inderdaad mee rekening houdt, dan kan je er dus leuke dingen mee doen.

Zoals Andries opmerkte, tijdens de dotfmp vorig jaar heb ik een demo gegeven, waarbij een 20-tal server processen samen iets meer dan 200MB geheugen gebruikten. Als die dingen in hun wachtloop van 1/3 seconde zaten, dan was de quad core server minder dan 1% CPU geheugen aan het spenderen. Ik had nog wat problemen met de record locking/broadcasting, een bug waarbij server side processen problemen hebben met het "zien" van record updates door andere server side processen. Door die bug draaide alles nog niet rond.

Door echter gebruik te maken van de MBS ( "FM.VariableSet" ) en MBS ( "FM.VariableGet" ) kon ik later echter de loop puur in het geheugen laten lopen. Elke process heeft z'n eigen AccountName, hierdoor kan een dynamische variabele gemaakt worden die als naam een keyword & die AccountName heeft, en die als waarde de TimeStamp krijgt als de "robot" door de loop passeert. Hierdoor kan een scheduled script alle variabelen van alle robots checken. Elke robot noteert waar hij mee bezig is, en hoe lang dit maximum mag duren. Als het scheduled script ziet dat de robot te lang weg blijft, start het via een XML call een nieuwe robot "instance" op. Omgekeerd, als een robot ziet dat die te laat arriveert, vernietigt de robot zichzelf simpelweg via "Halt Script", waardoor AccountName/Robot combinatie maar 1 keer kan voorkomen. De "robot checker" schedule draait dus server side, elke minuut, en opent een script in een lichtgewicht dummy filetje, want hij heeft eigenlijk alleen maar het geheugen nodig.

Het XML truukje gebruikt ik omdat dat een manier is om in een server side script een nieuw server side script te starten, in de volksmond wordt dit "forken" genoemd. Een server side script kan geen "perform script on server" uitvoeren omdat die script stap niet compatible is. De XML engine dateert echter van een periode waar de begrippen "server side" en "client side" nog niet bestonden. En daar is de script stap wél compatibel. Het is dus het XML script op de server dat "perform script on server" uitvoert en natuurlijk niet wacht op een resultaat. Waardoor een nieuwe robot geborden wordt.

Met de XML call kan de robot onmiddellijk met de juiste credentials aan de slag, omdat de credentials deel uit maken van de call. Vanuit het FileMaker dashboard gaat dat niet, omdat je server side script begint met jouw credentials. Dus scripte ik server side een re-login, wat pas werkt sinds v15. De server side loops reageren netjes op een disconnect request, zodat je altijd je server zonder problemen kan herstarten, na bijvoorbeeld een Windows Update. De Server side "robot checker" start 1 minuut na opstart van de server, ziet dat de robots niet draaien, en start ze netjes op. Geen omkijken naar.

Zorg in je configuatie van je server dat de server 3 x het aantal robots als aantal parallelle scripts aan kan. Zo zijn er genoeg script "slots" om het systeem te doen ademen. Er is een bug in FileMaker Server 16 waarbij je script slots kan verliezen onder bepaalde omstandigheden. Dus een beetje ruimer inschatten dan wat je nodig hebt.

Je FileMaker Server is zo in staat om heel snel taken in de achtergrond uit te voeren voor verschillende gebruikers. Ik heb op het ogenblik een project met 30 server robots lopen, draait prima. Die scripts gaan met 5 tegelijk ( parallel dus ) in gang om een SOAP request naar 5 verschillende servers te maken, en dit zorgt dat de antwoorden snel terugkomen terwijl de client gewoon vrijblijft en even naar een web viewertje met een animatie krijgt, om aan te geven dat er hard aan de zaak gewerkt wordt.

In ander project met 25 robotjes, maakten we een FileMaker Go oplossing supersnel, doordat ze niet meer rechtstreeks op het grote systeem moest inloggen, maar dat kon opvragen en wegschrijven via die robotjes. De FileMaker Go file heeft bijna geen layouts en scripts, alleen maar een paar buffertabellen. Via het GSM netwerkt loggen de FileMaker Go clients nu op minder dan 5 seconden in, een re-connect gaat natuurlijk nog sneller. Moesten ze op het grote systeem inloggen, dan zou dat meer dan 2 minuten duren. De robots maakten deze oplossing dus werkbaar.

In nog een ander klein project, leest een robot loop de mail, via IMAP ( ook dus de MBS plugin ). Alle te verwerken mails komen dus netjes in FileMaker records binnenlopen, live.

Als je de mogelijkheden ziet, is het moeilijk om hier niet enthousiast over te zijn.:D

Link to comment
  • 0

Wow Peter, dat is veel info! En eerlijk gezegd, nieuw voor me! Ik ga me er in verdiepen, dankje! 

Momenteel heb ik een issue met PSOS, waar een PSOS niet wordt uitgevoerd. Ipv dat het script wordt uitgevoerd, krijg ik een foutmelding: "De maximale capaciteit van de server is bereikt" en ik heb het vermoeden dat ik de oplossing voor dit probleem in deze hoek moet zoeken.

Link to comment
  • 0
Op 3/21/2018 om 16:20 zei Marsau:

Dank je, Peter. Ik bedoel de 'set field' stap. 

Het server log geeft geen error? Dat log zou een scriptnaam, een lijnnummer, een scriptstap naam én een foutcode moeten bevatten. Het kan zijn dat je script ermee stopt door oncompatibele instructies. Als je “onderbreken door gebruiker” niet AF hebt gezet, zal je server side script er uit vliegen om de domste redenen, het is dus gevoeliger dan een client side script. Dus gebruik zeker de script stap “onderbreken door gebruiker” AF. Truukje: gebruik de re-login script stap met een commentaar als login naam. Dit genereert een foutmelding in het log... met jouw commentaar. Ideaal als je wil debuggen.

Link to comment
  • 0

Sorry voor dit late antwoord, Peter.

Het is een tijdje buiten mijn aandacht geweest. De robot doet zijn werk op zich prima, maar vergt voortdurend aandacht. 

Ik heb het vraagstuk niet opgelost: ik heb de ervaring dat het werkt (ook jouw statement), en dat het niet werkt (Menno), en begrijp niet wat hier de bepalende factor is. 

Op dit moment weer een aantal zaken werkend gekregen, maar kan niet aanwijzen wat ik anders heb gedaan.

Server side scripting is idd een grijs gebied.

Mars

Link to comment
  • 0

Hi Mars,

ik heb toevallig gisteren bij een klant met FMS16 een server-side script dat in een Table-Occurrence (TO) van een bestand op een andere FMServer (FMS17) op internet leest en schrijft. Dus je kan in elk geval met FMS 16+ en de juiste toegangsprivileges, de data van bestanden op externe FMServers lezen en schrijven via een TO vanuit je eigen bestand.

Verder heb ik niks getest, dus ik weet bijvoorbeeld niet of je een bestand op afstand vanuit de lokale FMServer kan openen en dan scripts van dat bestand kan afdraaien.

Link to comment
  • 0

Hoi M&M,

Via een externe TO werken kan ik ook bevestigen: werkt prima. Formeel "Open File" gebruiken? Inderdaad, geen idee.

FileMaker Server is een PITA, als het over logs lezen gaat. Het wordt er niet simpeler op om je server side scripts te debuggen. BTW, in mijn opinie is Server 17 de slechtst werkende versie van Server die FileMaker ooit gereleased heeft. Het doet me sterk denken aan OSX Server Lion. Features verdwenen en dingen die slecht werken, en de interface is gewoon ondoordacht, en ongebruiksvriendelijk. Ik begrijp dat FileMaker weg wilt van Java, en naar HTML5 wil, maar de admin interface is eigenlijk nog een beta versie, met een ellenlange lijst van problemen die nog opgelost moeten worden, en ook een stevige lijst van features die ontbreken t.o.v. van de vorige versie. Gelukkig doet de server engine het goed, maar over de admin interface ben ik absoluut niet te spreken.

Dit macOS bash scriptje gebruik ik al een 2-tal maanden. Het werkt redelijk goed voor de event.log, en helemaal niet goed voor de wpe.log. Ik heb de indruk dat dit komt door de manier waarop server naar die wpe log schrijft. Dit laat me terug toe om server side scripts live te debuggen. Nogmaals, schande dat dit vandaag op deze manier moet.

Je gebruikt 'm zo:

perl ftptail -s 5 -n 30 -f --password-file=pw.txt <login>@<server>:21/logs/Event.log

Waarbij mijn paswoord in het pw.txt bestandje staat. Op de server is natuurlijk een FTP instantie opgestart die als root de FileMaker Server folder heeft.

Nog beter:

perl ftptail -s 5 -n 30 -f --password-file=pw.txt <login>@<server>:21/logs/Event.log > Event.log

Piped de output naar een lokaal bestandje, en BBEdit gaat dit ook mooi updaten, zodat je terug een log hebt zoals het hoort.

Wie dit met SSL FTP wil laten werken, moet in het perl script duiken en wat libraries en instructies veranderen. Ik heb geen perl expertise, dus daar blijf ik even van weg.

ftptail

Link to comment
  • 0

Het is een beetje verwarrend om met zo'n goed geïnformeerde Pipo te spreken :-) Dank voor de tip. Wellicht is het een leuk idee om die logs direct in een Filemaker bestand te verwerken,  of krijg je dan het Droste-effect:-)

Wederom ook een bevestiging van mijn zijde vwb het server side scripten met externe tabellen: het werkt echt. 

Voor wat betreft 'platte' data-uitwisseling in ieder geval. Remote triggeren van scripts was (nog) niet mijn doel.

 

 

Link to comment
  • 0

@Peter Wagemansik ben het met je eens dat console wel een beetje kan worden verbeterd. Überhaupt is het beheer en het loggen een ramp bij FMS17. Er is GEENEEN interface waar je alles mee kan!!!!! De console (C) mist dingen, de command-line (CL) mist dingen én de admin-API (AA) mist dingen (Samen: CCLAA).

Met de optelsom van alledrie kan je nog steeds niet alles, want om fmp-bestanden te uploaden heb je óf FileMaker Pro nodig óf je moet het via het OS doen! Via de CCLAA kan dat namelijk niet (tenzij je het progje scp van terminal tot CL rekent, maar dat is op windows niet beschikbaar)

Als FMI dan die AdminAPI verder wil promoten, dan moeten ze gaan zorgen dat écht alles met die API kan ... wat er in zit werkt wél heel goed, dat dan weer wél.

Link to comment
  • 0

En zo kunnen we doorgaan:

  • je kan niet meer onmiddelijk zien welke files een user open heeft, dat kan alleen als je hovert over een user, dan komt er zo’n dom tooltipje tevoorschijn.
  • Hierdoor kan je ook niet meer zien met welke rechten een user een bestand open heeft
  • In de backup schedules interface is een uurlijkse backup een dagelijkse backup met opties. Wat?

Ondertussen heb ik bovenvermeld tail perl script helemaal aangepast aan mijn noden, het doet nu ook FTP over SSL. Geen idee of dit interessant genoeg is, wie er om vraagt krijgt dit bestandje.

 

Link to comment
  • 0

Ze willen, zo lijkt het, de admin-api een beetje doordrukken. Met

https:/ipserver/fmi/admin/api/v1/databases

krijg je een json terug met alle gesharede bestanden en welke clients daarop zijn ingelogd met welke rechten. Dat werkt best aardig, maar als  je ik noem maar wat 80 bestanden en 130 actieve gebruikers hebt, dan is het JSON-netje aan de forse kant. Je zou dan je query een beetje moeten kunnen beperken met 

https:/ipserver/fmi/admin/api/v1/database/db-naam

Het is echter niet mogelijk om van slechts één DB die gegevens op te vragen (ook niet hidden, heb ik geprobeerd).

Er zijn inmiddels wel een paar aardige tools gemaakt door FellowFMDevelopers:

https://thebrainbasket.com/?p=549 van Claus Lavendt

https://github.com/SoliantMike/FM-Admin-API-Tool Soliant (Anders, Marc, Wim, Mike?)

https://www.productivecomputinguniversity.com/courses/fm-server-manager Marc Larochelle

https://community.filemaker.com/docs/DOC-9074 (door FMI zelf)

Allemaal hebben ze voor en nadelen. Er is er geeneen helemaal af, maar je mag er zelf gelukkig alles aan wijzigen. 

 

Ben ik hier blij mee? ...... Nee niet echt......  Ik wil gewoon mijn DB's bouwen en bij mijn klanten neerpoten/onderhouden.

Dus waarom heeft FMI nu allerlei functionaliteit van de FMS-console weggehaald, die iedereen wel regelmatig gebruikt(e):

  • Bestanden uploaden in de console (kan al sinds 14 niet meer, maar ik baal daar nog steeds van)
  • Overzicht van users en gebruikte rechten
  • De live-statistieken zijn weg, dus je ziet de invloed van bepaalde acties op de performance niet meer
  • Struinen door de logs om server-side scripts te debuggen. Dat was eigenlijk al veel te summier met informatie, maar nu moet je die logs eerst aanklikken, downloaden, uitpakken, openen, filteren, scrollen en dan zie je pas wat nodig hebt. Wie bij FMI dát PVD heeft bedacht, verdient écht een wandelkaart!

Zo nu heb ik wel weer genoeg gezeurd ?

Link to comment
  • 0
22 uur geleden zei menno:

Bestanden uploaden in de console (kan al sinds 14 niet meer, maar ik baal daar nog steeds van)

Je moet dat dus via je client doen, maar wél eerst AL je bestanden sluiten, want anders wil FileMaker DIE gaan uploaden. FileMaker gaat er dus vanuit dat je alle bestanden die je lokaal open hebt op de server wil zetten. Is dat niet het geval - meestal niet dus, voor mij - dan mag je de je hele biotoop afsluiten om een filetje te uploaden, of een 2de instance van FileMaker opstarten.

In het geval dat je wél zou willen, dan is het eerste dat FileMaker zegt: je bestand zal gesloten worden. Duh.

Heb je helemaal geen bestanden open, dan kan je (eindelijk) de bestanden kiezen die je wil uploaden. Bravo FileMaker.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...