Perform Script on Server in een ander bestand

[hans erik]

Ik kom een lastig probleem tegen met FMS13:

 

- twee bestanden, een interface bestand (=userfile) met scripts en layouts en een databestand (=datafile) met de gegevens, beide gehost op FileMaker Server 13.

- ik ben ingelogd op beide bestanden als administrator (full access), zelfde username en hetzelfde wachtwoord.

 

Nu probeer ik met behulp van Perform Script on Server (PSoS) een batch bewerking uit te voeren op het data bestand, maar dat werkt niet.

De userfile bevat twee scripts, een hoofdscript dat het tweede script aanroept. Het bevat 1 scriptregel:

 

Perform Script on Server [Wait for completion; “werk z_reserve bij”]

 

en het subscript 'werk z_reserve bij' doet dus de aanpassing (niet).

 

De serverconsole geeft een foutmelding:

 

Client "test - admin 74 (MiniServerFMS13) [127.0.0.1]" authentication failed on database "BD_dataT.fmp12" using "Admin [fmapp]".

 

Ik begrijp wat er gebeurt: het script draait in de userfile, maar wordt wordt uitgevoerd door een 'eigen sessie', vandaar het IP adres 127.0.0.1.

Maar wat ik niet begrijp is waarom FileMaker hier niet de login van de userfile overneemt in de datafile. De datafile moet voor de 'PSoS sessie' kennelijk apart geopend worden, maar dat gaat via dezelfde bestandsverwijziging dus zou je verwachten dat FileMaker het wachtwoord overneemt.

 

Het werkt namelijk wel wanneer ik het bijwerkscript in de datafile opneem en oproep vanuit de userfile, als volgt.

Ik draai dan hetzelfde script in de userfile dat maar met de volgende scriptregel:

 

Perform Script on Server [Wait for completion; “werk z_reserve bij” from file: “BD_data”] <= hier wordt aangegeven dat het script in de datafile zit.

 

Maar dan gebruikt ie toch ook dezelfde login?

 

Is hier een work-around voor?

 

HE

[Felix]

.

Edited October 5, 2015 by Guest

[hans erik]

Ja, ik ga dit wel melden.

 

Op de FMSummit werd wel verteld dat er iets met authorisatie is, maar dit is wel erg lastig.

En wat het nog lastiger maakt: je krijgt geen melding dat het script niet uitgevoerd wordt.

 

Samengevat komt het denk ik neer op het volgende:

- een script dat met PSoS uitgevoerd wordt moet deel uitmaken van het bestand waarop het werkt.

- als dat bestand een beveiliging heeft, moet het geopend zijn.

- filemaker draait het script onder een aparte sessie op de server die wel de account gebruikt van de login, maar daarbij alleen naar het 'eigen bestand' kijkt. Er is dus geen sprake van een 'carry-over' van de login en wachtwoord, zelfs niet als het andere bestand al geopend is.

 

HE

[elmystica]

Joris Aarts gaf de Sessie op FMSummit en heeft onlangs een Webinar rond dit onderwerp gepresenteerd:

 

https://www.youtube.com/watch?v=o8Fm4oR0scQ

[menno]

Maar dan gebruikt ie toch ook dezelfde login?

 

Is hier een work-around voor?

Bij gebruik van PSoS moeten alle bestanden die in een aangeroepen script worden gebruikt reeds zijn geopend op de client die dat script op de server laat uitvoeren.

 

Inlogcredentials worden nooit "doorgegeven", de "workaround" is dan het bestand op de client openen (verborgen is voldoende), voordat je de PSoS-aanroep start.

 

De sessie van Joris laat dit overigens allemaal heel duidelijk zien .... de beveiliging is in ongeveer de 30e minuut aan bod (voor de diegenen met haast )

 

Ik kan me voorstellen dat het zeer complex is om te beveiligen voor toegang met FMP, CWP, Webdirect én ODBC, zodat het "doorgeven" wellicht voor conflicten en security-issues zorgt, die wij nu ff niet zien. Om dan eerst te zorgen dat de credentials op alle betrokken bestanden voor de betreffende gebruiker zijn geverifieerd, lijkt mij gewoon een veilige keuze.

[Felix]

.

Edited October 5, 2015 by Guest

[menno]

In het algemeen is het met hacken zo dat een voet tussen de deur hebben meestal voldoende is om allerlei informatie te stelen. PSoS is niet het enige waar de toegang moet worden gecontroleerd.

 

Je opent met een client een bestand en PSoS is alleen maar een opdracht ván die client, dus als je via PSoS indirect bestanden gebruikt, moet de toegang gewoon al bekend zijn en doe je door die bestanden geopend te hebben vóórdat je met PSoS een script laat uitvoeren. Ik vind het daarom niet zo raar.

[hans erik]

Bij gebruik van PSoS moeten alle bestanden die in een aangeroepen script worden gebruikt reeds zijn geopend op de client die dat script op de server laat uitvoeren.

 

Inlogcredentials worden nooit "doorgegeven", de "workaround" is dan het bestand op de client openen (verborgen is voldoende), voordat je de PSoS-aanroep

 

Ja, dat begrijp ik, maar dat is dus juist het probleem:

- ik ben aan beide bestanden aangelogd met [full access]

- beide bestanden zijn geopend.

 

Maar ik kan dan ook niet een script via PSoS draaien vanuit het ene bestand dat een bewerking doet op het andere bestand.

Er gebeurt niks omdat filemaker kennelijk vindt dat het andere bestand niet geopend is, terwijl het WEL geopend is.

Het probleem zit hem in de extra sessie waarin Filemaker het script draait.

 

Ik zal het webinar van Joris Aarts eens nalopen. De presentatie op de FMSummit had alleen betrekking op 1 bestand...

 

HE

[menno]

joris heeft het ook over meerdere bestanden en legt vrij exact uit hoe je een script in een extern bestand kan aftrappen. Die handleiding heb ik gevolgd in mijn eigen situatie en het werkt als een zonnetje, ook met een account zonder full-access.

 

Je er wel rekening mee houden dat voor PSoS een aparte nieuwe sessie op,de server wordt opgestart die alleen maar zooang open is als dat het duurt om het script te laten uitvoeren. Eventuele scripttriggers zal,je moeten afvangen met bijvoorbeeld een $$notrigger oid.

 

Een ander punt om in gedachten te houden is dat jouw context niet direct wordt beïnvloed door wat PSoS oplevert (tenzij je iets verwijderd of wijzigt in de data van de gevonden set met records)

[hans erik]

joris heeft het ook over meerdere bestanden en legt vrij exact uit hoe je een script in een extern bestand kan aftrappen. Die handleiding heb ik gevolgd in mijn eigen situatie en het werkt als een zonnetje, ook met een account zonder full-access.

 

Ik heb de presentatie van Joris Aarts nog eens nagelopen (overigens: petje af, gedegen werk!) maar toch werkt het niet zoals je zou verwachten.

Met een iets vereenvoudigde testopzet alles nog eens nauwkeurig nagespeeld:

 

- bestand A en B geopend op FileMaker Server 13, beide zijn geopend met dezelfde username en wachtwoord. (met full access).

- bestand B bevat een tabel 'gegevens' met een veld dat ik wil wijzigen, bijv. met Replace Field Contents [No dialog; gegevens::wijzigB; Get ( CurrentHostTimeStamp )]

- uiteraard bevat bestand A een verwijzing naar B en ook een Table Occurrence van de tabellen van B, waaronder een TOC 'gegevens' met een layout 'gegevens'.

- ook bestand B bevat een TOC 'gegevens' met een layout 'gegevens'

- beide bestanden bevatten een script met drie regels:

 

Go to Layout [“gegevens” (gegevens)]

Show All Records

Replace Field Contents [No dialog; gegevens::wijzigB; Get ( CurrentHostTimeStamp )]

 

Er is dus geen sprake van een context-probleem en ook is het niet een gerelateerd veld dat gewijzigd wordt.

 

Situatie 1:

- knop in A => draait lokaal het script vanuit A. Werkt uiteraard, want draait niet op de server.

 

Situatie 2:

- knop in A => voer script in A op Server uit => werkt NIET, terwijl alle bestanden geopend zijn met de juiste credentials (maar auto-login is dus NIET enabled)

 

Situatie 3:

- knop in A => voer script in B op Server uit => werkt WEL

 

Maar volgens de informatie van Joris Aarts zou situatie 2 ook moeten werken wanneer je ingelogd bent.

 

NB als er geen username/ww is, werkt situatie 2 overigens WEL. Maar dat is natuurlijk geen reëele situatie.

Een work-around kan de auto-login zijn, maar niet iedere gebruiker wil dat. Bovendien moet elke gebruiker dat zelf instellen. Zet je het uit dan zijn de rapen gaar. En je krijgt geen foutmelding!

 

HE

[hans erik]

Ik heb ook nog de scriptstap 're-login' geprobeerd, maar dat werkt ook niet. Jammer dat filemaker geen optie 'log in als ...' heeft, waarmee je wel complete controle zou hebben.

[menno]

Ik heb fii een demo-tje in elkaar gedraaid.

 

Er zijn twee gebruikers: admin en user en hun wachtwoorden zijn eveneens admin en user geen enkele gebruiker logt automatisch in.

Het script uitvoeren start alleen wanneer de beide bestanden zijn geopend op een server.

Het bestand A.fmp12 is het leading bestand, dus dat moet je met je client opstarten.

Fouten worden niet onderdrukt

De scripts wachten op de uitvoering (anders kan je geen resultaat terugkrijgen)

De extended privileges "fmapp" zijn toegekend aan de gebruikers in beide bestanden

 

Het werkt bij mij probleemloos, het script in B wordt zelfs uitgevoerd als B aan het begin niet is geopend, de credentials komen zelf mee naar dat bestand. Dat laatste verbaast me, dus duik ik nog ff in, niet vandaag, want ik heb het iets te druk met wat anders

A_en_B.zip

[menno]

OK ik heb uitgezocht waar het verschil in zit. Het bestand B wordt gewoon geopend omdat het hoofdscript in bestand A eerst remote in A PSoS uitvoert en daarna PSoS in B. Het is dan niet nodig om B al open te hebben en als PSoS in B wordt aangeroepen, ook worden wél de credentials van dat moment meegestuurd aan B. Eigenlijk heel logisch dus

 

Waar je in een notedop rekening mee moet houden bij PSoS is:

• De context die je wilt bewerken zal je op de een of andere manier “mee moeten geven”.
  
• Je kan alleen scripts starten in bestanden die open staan op het moment dat je PSoS start.
  (en daar moet je de context ook “meegeven”)
  
• Gegevens bewerken vanuit PSoS kan alleen in bestanden die al open staan op de client.
  
• Inloggegevens (en dus ook de privileges) worden meegestuurd vanuit de bestanden die op de client open staan.
  (maar je kan natuurlijk een script(-stap) met “login als” laten uitvoeren.)
  
• Denk aan de compatibiliteit van de diverse script-stappen (zet in script-maker “Show Compatibilty” op “Server”)

[hans erik]

Menno

 

Bedankt voor al je moeite.

 

Ik heb je voorbeeld geïnstalleerd en het klopt allemaal in zoverre dat jij precies de scriptstap niet hebt opgenomen die bij mij dus het probleem oplevert.

 

Voor de duidelijkheid heb ik het veld 'dts' in bestand B hernoemd naar 'dtsB'. Dan zie je aan de scriptstap het verschil beter.

 

Jij voert twee scripts uit:

- replace DTS in bestand A en vervolgens:

- replace DTS in bestand B,

 

waarbij het eerste script het veld in bestand A muteert (wat natuurlijk goed gaat) en het tweede script het veld in bestand B aanpast (wat ook goed gaat, want dat script bevindt zich in bestand B)).

Maar ik heb het eerste script in A genomen en dat even aangepast, als volgt (voorzien van regelnummers ter referentie):

 

1. Go to Layout [“A with B opened” (A)]

2. Show All Records

3. Replace Field Contents [No dialog; A::dts; Get ( CurrentHostTimeStamp )]

4. Replace Field Contents [No dialog; B::dtsB; Get ( CurrentHostTimeStamp )]

5. Commit Records/Requests [skip data entry validation; No dialog; Force Commit]

6. Exit Script [Result: "$error=" & Get( LastError ) & ";$version=" & Quote ( Get ( ApplicationVersion ) ) & ";$file=" & Quote ( Get ( FileName ) )]

 

Regel 1 heb ik aangepast, om ervoor te zorgen dat het veld 'B::dtsB' bereikbaar is.

Regels 2, 3, 5 en 6 zijn ongewijzigd, regel 4 heb ik tussengevoegd. Deze wijzigt de inhoud van veld dtsB vanuit A. En die wijziging wordt dus NIET uitgevoerd, ofschoon bestand B geopend is, met admin / admin!!

 

NB in FMServer 12 was het overigens ook al zo: je kunt in de Admin-console een server side script in een schedule opnemen, maar ook alleen in het fysieke bestand waarop het script werkt. Het heeft natuurlijk te maken met het feit dat je eigenlijk met PSoS een tijdelijke client-sessie op de server opent. En die is qua functionaliteit beperkt. Toch denk ik dat ze bij FMI op het gebied van de login gewoon iets vergeten zijn in te bouwen.

 

Misschien geen bug-report, dan toch zeker een feature request!

 

De enige oplossing is om het script voor het wijzigen van dtsB in bestand B op te nemen, wat betekent dat je de context moet 'meegeven' oftewel moet creëren in B.

 

Wat wel jammer is, want ik probeer door scheiding van interface en data juist de datafile schoon en simpel te houden. Nu moet ik OF door scripts OF door extra TOC's toch allerlei interface-gerelateerde ballast gaan toevoegen.

Baal ik van.

 

Hans Erik

[menno]

Wat belet jou dan om vóórdat je PSoS afvuurt, dat gerelateerde bestand gewoon te te openen op de client? Als je het al hebt geopend met de juiste privileges, dan kan je stap 4 gewoon uitvoeren .... of mis ik dan wat?

[hans erik]

Je bedoelt dus dat je eerst een Open file[] scriptstap uitvoert in het client bestand dat het andere (data-)bestand expliciet opent? Heb ik nog niet geprobeerd.

Maar het bestand wordt toch via de layout + relatie automatisch geopend? En dat zou toch op zo'n 'server-based sessie' ook moeten werken? Zelfs WebDirect doet dat.

[hans erik]

Even wat zwaarder geschut in stelling gebracht:

 

1a Go to Layout [“A with B opened” (A)]

1b New Window (VIRTUAL WINDOW ON WEB) [Name: "tmp"; Style: Document]

2 Show All Records

3 Replace Field Contents [No dialog; A::dts; Get ( CurrentHostTimeStamp )]

4a Open File [“B”]

4b Select Window [Name: "tmp"; Current file]

4c Go to Layout [“A with B opened” (A)]

4d Replace Field Contents [No dialog; B::dtsB; Get ( CurrentHostTimeStamp )]

5 Commit Records/Requests [skip data entry validation; No dialog; Force Commit]

6 Exit Script [Result: "$error=" & Get( LastError ) & ";$version=" & Quote ( Get ( ApplicationVersion ) ) & ";$file=" & Quote ( Get ( FileName ) )]

 

Nu maak ik in de virtuele sessie een 'nieuw venster' aan (stap 1b) en wordt in stap 4a bestand B expliciet geopend. Daarna ga ik terug naar de layout in A en dan voer ik in 4d de Replace uit.

Je zou verwachten dat FileMaker nu door heeft dat B geopend is, maar stap 4d wordt NIET uitgevoerd.

[menno]

Is dit nu het script dat je op de server laat uitvoeren? EN je wilt dat B wordt geopend in dit script ZONDER dat je dit zelf van tevoren in je script doet .... toch?

 

Dat gaat echt niet werken.

 

In het voorbeeld-script in mijn voorbeeld-bestand wordt het bestand B in het script al geopend doordat de scriptstap:

Perform Script on Server [Wait for completion; "Replace DTS" from file:"B"]

in dat script staat. Ik neem aan dat aan het begin van het script Filemaker een check oid doet en daardoor eventuele bestanden die subscripts bevatten al opent.

 

Die lay-out "A with B opened" bevat een willekeurig veld van een willekeurig record van een willekeurige tabel in bestand B (via de cartesische relatie [X]). Het enige doel van die lay-out met dat veld is B openen, maar blijkt overbodig in mijn voorbeeld.

 

Jouw "zwaardere geschut" gaat niet werken als dat in zijn geheel de inhoud van het PSoS-script is EN je dat laat aflopen als je op de client bewust alleen bestand A open hebt staan. Als je wilt dat dit werkt dan moet je in A de zaak minimaal tweaken:

 

Hoofdscript in A:

0a Go to Layout [“A with B opened” (A)]
0b Perform Script on Server [Wait for completion; "Replace DTS" from file:"A"]
0c Show Dialog ...

Alle andere stappen die nu in het hoofdscript staan zou je kunnen weglaten.

 

"Replace DTS" dat met PSoS wordt aangeroepen:

1a Go to Layout [“A with B opened” (A)]
2  Show All Records
3  Replace Field Contents [No dialog; A::dts; Get ( CurrentHostTimeStamp )]
4d Replace Field Contents [No dialog; B::dtsB; Get ( CurrentHostTimeStamp )]
5  Commit Records/Requests [skip data entry validation; No dialog; Force Commit]
6  Exit Script [Result: "$error=" & Get( LastError ) & ";$version=" & Quote ( Get ( ApplicationVersion ) ) & ";$file=" & Quote ( Get ( FileName ) )]

En dan werkt het wél. Zoals je hier ziet, kan je stap 1b gewoon weglaten, want dit doet FMServer zelf al zonder dat je deze instructie geeft en de stappen 4a, 4b en 4c zijn (in deze specifieke context) ook overbodig.

 

Het enige opvallende is dat in zowel het lokale script als in het PSoS script, de stap

Go to Layout [“A with B opened” (A)]

moet zijn opgenomen. In het eerste script om behalve A ook B te openen en in het tweede script maakt het gewoon deel uit van in de juiste context terecht te kunnen komen. De stap "Show All Records" zou kunnen worden vervangen door een (parametreerbare) zoekopdracht oid en is ook voor het instellen van een context.

 

Kortom het "Replace DTS" script is identiek zoals jij het in 1 van je vorige posts al hebt staan en ik heb in het hoofdscript alleen de stap

Go to Layout [“A with B opened” (A)]

toegevoegd om "B" op de client te openen en dan werkt het. Ik vind het toch wel een logische werkwijze...

[hans erik]

Menno

 

Ik snap het nog steeds niet.

 

Ik heb het script gewijzigd:

 

Go to Layout [“A with B opened” (A)]
Show All Records
Replace Field Contents [No dialog; A::dts; Get ( CurrentHostTimeStamp )]
#
#nu switcht het script naar layout 'B vanuit A':
#- de layout bevindt zich in bestand A
#- de layout toont de records van B, via de bestandsverwijzing
#
Go to Layout [“B vanuit A” (B)]
Show All Records
#en dan proberen we de records in B bij te werken, vanuit de layout in A dus.
#
Replace Field Contents [No dialog; B::dtsB; Get ( CurrentHostTimeStamp )]
Commit Records/Requests [skip data entry validation; No dialog; Force Commit]
#
Exit Script [Result: "$error=" & Get( LastError ) &  ";$version=" & Quote ( Get ( ApplicationVersion ) ) &  ";$file=" & Quote ( Get ( FileName ) )]
#

 

Als ik dit script via de opdracht Perform Script on Server direct vanuit een knop aanroep, doet ie het NIET, althans de eerste replace wordt WEL uitgevoerd, de tweede NIET.

Koppel ik een scriptje aan de knop dat op zijn beurt precies ditzelfde script laat lopen met PSoS (dus een scriptje er tussen hangen) dan werkt het WEL.

Ik vermoed dat dat toch iets met de registratie van die ServerSide Scripts te maken heeft.

 

Lijkt me toch een duidelijke bug.

[menno]

Wat jij blijkbaar probeert is, in het script dat je op de server laat uitvoeren, de benodigde bestanden te laten openen en dat gaat alleen als je die bestanden op de client waarvandaan dat script wordt aangeroepen al open hebt staan.

 

Ik heb het voorbeeld bestand nu zo aangepast, dat het meer werkt zoals jij dat zou willen en exact zoals ik heb beschreven in mijn vorige post:

 

Onder de knop in layout A zit het lokale script dat alles "bestuurt":

• De benodigde bestanden worden geopend door eerst naar een layout te gaan waar velden staan uit alle benodigde bestanden
• Het script dat PSoS moet worden uitgevoerd wordt in dit script gestart en wachten op uitvoering
• daarna iets doen met het script-resultaat

Het PSoS-script voert nu op de server de volgende zaken uit:

• context zekerstellen
• vervangopdracht(en) uitvoeren
• resultaat vastleggen en als scriptresult teruggeven

Ik kan het geen bug vinden, sorry

A_en_B_Aangepast.zip

[hans erik]

Menno

 

Ik heb alles nog eens op een rijtje gezet, en stap voor stap de verschillende opties getest. Het heeft niet zoveel zin om alle stappen nog eens te herhalen, dus even een kort commentaar en mijn conclusies.

 

Wat jij blijkbaar probeert is, in het script dat je op de server laat uitvoeren, de benodigde bestanden te laten openen en dat gaat alleen als je die bestanden op de client waarvandaan dat script wordt aangeroepen al open hebt staan.

Die staan al open, maar dat maakt volgens mij niet uit en dat is juist het probleem. FileMaker opent binnen PSoS alleen het bestand waarin het script zich bevindt.

 

Volgens mij werkt het zo:

 

1. Als je een PSoS uitvoert, opent FileMaker Server een nieuwe, virtuele sessie op de server. Dat zie je ook in het activiteitenlog van de adminconsole aan het nummer. Vandaar dat je ook je context moet definiëren want die bestaat op dat moment nog niet.

 

2. Het bestand dat het script uitvoert (= waarin het script zich bevindt) wordt geopend, en neemt dan de login over van de client sessie.

 

NB. Als je een script in een ander bestand laat runnen via PSoS, geef je dat natuurlijk aan via de filereferentie die je eerder hebt ingesteld in Manage External Data Sources, zo werkt FileMaker nou eenmaal. Alles werkt via die filereferenties.

 

3. Is het script klaar, dan wordt de virtuele sessie afgesloten, het bestand wordt gesloten en alle variabelen en globale veldwaarden worden opgedoekt. Weg! Dit betekent, dat een volgend script weer bij af begint. Ook wel logisch, want a. FMS weet niet dat er daarna nog een script komt (het is een runtime omgeving, niet een gecompileerde omgeving!) en b. anders zou de server binnen de kortste keren vastlopen met allemaal geopende sessies en bijbehorende bestanden, layouts en variabelen. Om maar niet te spreken van record locking conflicten.

 

4. Hoe kun je velden in een extern bestand gebruiken? Normaliter doet FileMaker Client dat automatisch,bijvoorbeeld als in een layout een gerelateerd veld voorkomt uit een Table Occurrence in een ander bestand, wordt dat externe bestand geopend. Maar met PSoS werkt het net iets anders. Open je een layout via een PSoS script, dan werkt dit mechanisme alleen op tabellen die zich fysiek in hetzelfde bestand bevinden, een eventuele externe filereferentie wordt NIET door FMS geëvalueerd. Dit is mijns inziens een hele grote tekortkoming.

 

 

En ziedaar het probleem. De heren bij FMI zijn vergeten de ondersteuning voor external data sources in layouts in te bouwen voor virtuele sessies. Ik heb er nog geen tijd voor gehad, maar ik ben benieuwd of het in WebDirect WEL werkt, want daar maak je ook van een Virtuele Sessie gebruik.

 

Je kunt dus via PSoS een script in een ander bestand runnen en dan wordt dat bestand braaf geopend (en ook weer gesloten). Maar je kunt in een script dat met PSoS wordt aangeroepen alleen gerelateerde velden gebruiken die zich fysiek in hetzelfde bestand bevinden als het script.

Edited January 16, 2015 by Guest

[menno]

Je kunt dus via PSoS een script in een ander bestand runnen en dan wordt dat bestand braaf geopend (en ook weer gesloten). Maar je kunt in een script dat met PSoS wordt aangeroepen alleen gerelateerde velden gebruiken die zich fysiek in hetzelfde bestand bevinden als het script.

Kan je daar een voorbeeldbestand van posten? Want dit werkt volgens mij en vat dan denk ik gewoon niet wat er bij jou niet werkt. Je hebt toch mijn voorbeeld bestand omgebouwd? Post dat even, dan laad ik die even naar mijn server en kan ik zelf zien wat er dan niet gebeurt.

[hans erik]

Hierbij.

 

Ik heb het voorbeeld even opnieuw opgezet, en iets gewijzigd. Het zijn 2 bestanden: Userfile en Datafile. Beide te openen met Admin / admin.In UserFile is een bestandsreferentie naar Datafile opgenomen, andersom niet.

 

PSoS test.zip

 

Als je de bestanden installeert en je opent Userfile, moet je eerst Admin/admin invoeren, Datafile opent dan automatisch op de achtergrond.

Je komt in de layout User terecht, met 3 records in de lokale tabel en een paar velden en knoppen.

Alles werkt vanuit deze layout, wat ook je context is. De tabellen 'localdata(userfile)' en 'remotedata(datafile)' zijn gekoppeld op ID met de tabel 'user(userfile)'.

 

Er zijn 7 knoppen in de footer:

- reset maakt de velden in de actieve tabel weer leeg.

- 11 en 21 voeren script 11 en 21 uit, resp. lokaal en op de server.

- 12 en 22 voeren script 12 en 22 uit, idem

- 13 en 23 voeren script 13 en 23 uit, idem.

 

De kleuren corresponderen met elkaar. De testprocedure is telkens: klik eerst op reset en daarna op de button naar keuze.

 

Script 11, 21, 12 en 22 dienen ter illustratie:

- in 11 en 21 wordt het witte veld gevuld met een lokale waarde. Gaat probleemloos, ook PSoS.

- in 12 en 22 wordt het lichtblauwe veld gevuld met een combinatievan een string en een gerelateerde waarde, waarbij de gerelateerde tabel zich in dezelfde fysieke file bevindt. No problem, ook PSoS. Als de relatie niet geldig is, wordt de status niet ingevuld, maar wel de string.

 

- in 13 wordt het roze veld (status_remotefile) in user gevuld met de gerelateerde waarde uit remotedata. Dit script loopt op de client: no problem.

- in 23 zou het roze veld in user gevuld moeten worden met de gerelateerde waarde uit remotedata, maar dit werkt NIET.

 

In script 13 en 23 heb ik daarna een Go to Related Record toegevoegd om de remote file expliciet te openen, maar kennelijk gebeurt dat niet, want het resultaat is negatief. En de PSoS resulteert steevast in een Authentication error in de console. Ik heb geen Error Capture gedaan of scriptresults opgevraagd, maar de errorcode zal ongetwijfeld een authentication error zijn oid. Aan de layout zie je of het script goed uitgevoerd wordt of niet.

NB als je 13 uitvoert, wordt status_remotefile netjes gevuld. Voer je meteen daarna 23 uit (PSoS) dan worden de waarden verwijderd. De remote file is dus niet open, want de relatie werkt niet.

 

Er wordt dus geen script in de remote file uitgevoerd, alles speelt zich af in de default context. De context is ook niet het probleem.

 

NB Go to Related Record zou wel goed moeten werken, nergens wordt in de documentatie bij mijn weten gerept over gekoppelde bestanden die niet zouden werken. Mijn conclusie is dat FMS gewoon de externe referenties negeert. Ik snap dat dat logisch is bij ODBC koppelingen en ESS gekoppelde tabellen, want die worden niet op dezelfde server gehost (!). Maar voor een oplossing als deze zou het gewoon moeten werken.

 

HE

[menno]

- in 13 wordt het roze veld (status_remotefile) in user gevuld met de gerelateerde waarde uit remotedata. Dit script loopt op de client: no problem.

- in 23 zou het roze veld in user gevuld moeten worden met de gerelateerde waarde uit remotedata, maar dit werkt NIET.

 

In script 13 en 23 heb ik daarna een Go to Related Record toegevoegd om de remote file expliciet te openen, maar kennelijk gebeurt dat niet, want het resultaat is negatief. En de PSoS resulteert steevast in een Authentication error in de console. Ik heb geen Error Capture gedaan of scriptresults opgevraagd, maar de errorcode zal ongetwijfeld een authentication error zijn oid. Aan de layout zie je of het script goed uitgevoerd wordt of niet.

NB als je 13 uitvoert, wordt status_remotefile netjes gevuld. Voer je meteen daarna 23 uit (PSoS) dan worden de waarden verwijderd. De remote file is dus niet open, want de relatie werkt niet.

HE er is denk ik iets anders bij jou aan de hand ............... bij mij doen jouw files het gewoon. Welke versies van FMS/FMPA en OS gebruik jij?

Ik test zelf op MacOS 10.10.1 en windows 8.1 professional met FMPA13v4 op FMS13v5 op Windows 2012 server en overal wordt met 23 het veld status_remotefile gevuld met waarden. Ik heb niks gewijzigd aan de scriptjes (behalve een close-file in de scripts waar een nieuw venster wordt gemaakt )

[hans erik]

Menno,

 

Je hebt helemaal gelijk.

De server was nog 13v1. Heb een update geïnstalleerd (nu: 13v4, doe later de upgrade naar 13v5 nog) en nu draait het wel naar behoren.

 

Dank, probleem opgelost!

 

NB ik had wel de releasenotes doorgenomen, maar daarin geen woord over Perform Script on Server. Ik zou van FMI op dit punt toch wel een iets professionelere opstelling op prijs stellen. Niet een vage term 'bugfixes' maar gewoon een complete lijst en misschein zelfs met een verwijzing naar een issuelijst.

[menno]

Mooi dat je probleem is opgelost. FMI heeft bij update naar 13v2 wel gezegd dat serverside scripting is aangepast:http://help.filemaker.com/app/answers/detail/a_id/13183/~/software-update%3A-filemaker-server-13.0v2-release-notes. Ik zat zelf op die update wachten vanwege dat xml/xsl import niet werkte