Hello

I've set up a FM14 database, hosted on FMS 13 Win, The database controlls commits to be possible only when certain field conditions are met and a submitting button is selected. Everything was working fine as expected via Webdirect until I notice that by refreshing the browser you get a not desired or Uncontrolled "commit". is there a way to avoid these?,  Somewhere in the web I read that Refreshing the browser has the exact behavior that the "Exit Application Script"  does on FMP client, which works fine under FMP client but I can't reproduce the same behavior under WD. I also read that a transactional method is fully compatible with WD, but does not seems to be in this case, unless I'm mistaken.

Anyone can help me with this,

Thanks...

Edited September 13, 201510 yr by fyanesv
Wrong word, meant to say Uncontrolled not controlled, Sorry.

I also read that a transactional method is fully compatible with WD, but does not seems to be in this case, unless I'm mistaken.

The fact that a refresh commits does not invalidate the transactional method...

Does the onRecordCommit fire when you refresh the browser?

Does the onRecordCommit fire when you refresh the browser?

I inserted a dialog and a Set Variable "Global" as first step at the Commit Script but It seems that it does not fires the onRecordCommit, this is what it does

1.- Immediately Commits the Record ( Viewed with simultaneous FMP Client Session)

2.- Fires "OnFirstWindowOpen".

3.- Goes to 1st Record.

Don't know what else to do.

Don't refresh the browser

Seriously though, since the client application is the browser and you don't have full control over all its functions, there is some user training involved to tell people what is ok and what is not.  You give up some control to the browser and you can't control it.

If this is something that is mission critical, you may need to either adjust your approach or come up with a defensive way to trap for that issue.

I would probably go 2 of 3 ways ( incorporating 2 approaches to cover it all ).

• Find an approach that makes the commit not so dangerous to the workflow. I can't help much with that one without seeing the database, and charging you as a consultant.
• Use a hidden field that gets set to indicate that everything has been set/completed correctly on that record. Then run a schedule script to look for records that are not completed properly, and complete them as necessary.
• As Wim suggested, spend some more time training the users. If they are refreshing the browser, talk to them about what they are trying to accomplish by refreshing. They are clearly expecting something to happen when they refresh.

fyanesv,

Take a look at the article that Todd Geist posted recently. Briefly explains the issue and a possible work around. 

https://www.geistinteractive.com/2015/09/14/webdirect-script-triggers-that-dont-trigger/

Thanks very much Josh, and sorry I did not comment before, just came out of a nasty virus! and lost too much valuable time. I did email Todd asking for his thoughts and he posted the article. I guess there is not much I can do for now, I'll try understand the use of transactions and see if it helps. Once again many thanks to you and Wim, really appreciate both your time.