Hello all

Maybe you can construct the key in the web-page prior to submitting. You may need to use some Javascript.

You could use an intermediary page which uses an "onload()" or a "META Refresh" to set the Global and submit the Form.

Will be editing values in the Parent, or is it just the Global which will be edited? How is the key field being set in the Child, is the relationship based on a Calculation?

All the best.

Garry

On web Global field is not private like in Multi-user! All visiting users will share it!

Yikes!

I never knew that.

I was planning to use a global to capure the current user then use this in a relationship to calculate if the user has access to the record. Guess I need a work around, no chance that I can use a token in a relationship?

I am having some luck using Tokens and inlines...

I set the global via a -Edit and pass the rest of the data via Tokens.

<form action="FMPro" method="post">

<input type="hidden" name="-DB" value="Test.fp5">

<input type="hidden" NAME="-lay" value="Web">

<input type="hidden" name="-Format" value="TestRes.html">

<input type="hidden" name="-RecID" value="1">

<input type="text" size=12 name="ID_global" value="">

<input type="text" size=12 name="-Token.1" value="">

<input type="submit" name="-Edit" value="Create Related Record?">

</form>

Then on the results page using an inline, I perform a second -edit using the data from the Tokens.

<INPUT TYPE="HIDDEN" NAME ="-Token" VALUE ="[FMP-CurrentToken: 1]">

[FMP-InlineAction: -db=Test.fp5, -lay=web, -RecID="1", Rel::Text.0={CurrentToken:1}, -Edit]

But I am getting a [/FMP-InlineAction] returned if I include it in my results page...

Anatoli said:

On web Global field is not private like in Multi-user! All visiting users will share it!

Yes. I generally try to use tokens instead of globals. I don't want ot have to reengineer this DB to build this simple web interface. I think the method above should work (but I can't be certain). An inline in a results page would be processed before a request from another user, no?

Maybe in older single threaded WebCompanion.

I am not sure in newer multithreaded WebCompanion.

Then second request may in theory get mixed-up in longer execution of first request.

It can go like:

Request A -- Edit FM and create value A in Global field

Request B -- Edit FM and create value B in Global field

Request A -- get result from Global field into Inline -- not expected A, but B

Request B -- get result from Global field into Inline -- expected B

For FM it will be execution in series, but because of new multithreading nature of WebCompanion it will be wrong result because of parallel processing.

Rigorous testing (oh man, what a pain) of all solutions seems to me to be important for the developer.

In this instance rigorous testing (oh man, what a pain) of multiple, near-simultaneous requests which cause chnges to the global for each client seems a good idea. Unless this is a closed solution with no chance of multiple requests, of course.

In this case, the number of users is very small and the tolerance of errors is reasonably high. I'll take my chances and monitor the situation...