Ga naar inhoud
  • 0

Perform Script on Server in een ander bestand


hans erik

Vraag

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

Link naar reactie

Aanbevolen berichten

  • 0

Het probleem leek opgelost met de upgrade, maar is het helaas niet: als ik de 'PSoS met externe referenties' lokaal in mijn eigen netwerk draai werkt het allemaal OK, maar over een WAN verbinding niet. Het script wordt wel uitgevoerd, maar op de een of andere wijze pikt FMS de externe koppeling niet op en opent de virtuele sessie dus NIET ALTIJD het gekoppelde bestand. Kan een timing probleem zijn, maar dat mag FMI uitzoeken.

 

Wel buitengewoon vervelend, mijn advies wat betreft PSoS is derhalve:

 

** alleen gebruiken wanneer relaties verwijzen naar basetables die zich fysiek in het eigen bestand bevinden!! **

 

[edit]

 

ik heb denk ik een oorzaak over het hoofd gezien: de client logt aan als [guest] aan het user-bestand en voert dan zijn naam en wachtwoord in om toegang te krijgen tot het databestand.

NB Dat is gedaan om het onderhoud van het userbestand te beperken. Je kunt dan zonder pardon het userbestand vervangen door een nieuwe versie, omdat er geen gebruikers-gebonden gegevens in zitten. Het databestand wordt dus ALTIJD geopend, omdat zonder dat bestand de hele applicatie niet werkt.

 

Maar voor PSoS geeft dat een probleem, omdat de PSoS alleen de credentials van het bestand overneemt dat het script uitvoert. En dat is: [guest] wat in het databestand geblokkeerd is. Dat verklaart de foutmelding. FMS opent het bestand niet omdat het dat niet mag, als guest.

De oplossing is om voorafgaand aan de PSoS opdracht (in het userbestand dus) een re-login scriptstap uit te voeren die de gebruiker inlogt als een account die ook in het databestand bestaat, met hetzelfde wachtwoord. Nadeel is dat alle wijzgingen die door het script worden uitgevoerd op conto van die account komen.

 

Pfff.

Link naar reactie
  • 0

hallo HansErik,

 

zie dat je het probleem inmiddels gevonden hebt, je moet inderdaad helemaal doordenken vanaf de positie van een nieuwe user, nieuwe globals, en dat geldt voor elk script opnieuw.

Dus groeperen via een PSoS masterscript die de subscripts in batch uitvoert.

 

En idd Creator & Modifier is dan "server" wat in veel omstandigheden ongewenst of misschien wel juridisch onjuist is.

Ik vang dat nu op door de userID als param mee te sturen naar PSoS en daar extra velden toe te voegen of AutoCreate uit te zetten op plekken waar dit noodzakelijk is.

Link naar reactie
  • 0

Ik dacht inderdaad niet ver genoeg terug: ik dacht dat je met de de 'Full Privileges' optie zo'n script wel kan draaien, maar als [guest access] geblokkeerd is kom je helemaal niet aan het script toe. Wel jammer dat FileMaker bij het submitten van zo'n PSoS niet de hele login situatie meeneemt, maar alleen naar het bestand kijkt dat het script afvuurt.

Volgende keer de foutcodes serieuzer nemen :-(

Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...