I’ve not been able to reproduce this problem. With/without the connect event being mapped to write back data into 2 other fields on the form (text input fields I’ve used here), whether the connect action is after the set field action under the button or on the drop down ‘data has changed’ event, whether the connect action is using the value of the dropdown that is set from the set field or not, all works perfectly OK.
I wonder if you may be seeing problems due to a slow/intermittent connection to your database from perfectforms? Perhaps all the ‘connections’ you have are causing your SQL to get confused/overloaded. One way to perhaps see if this is the case is …going back to your first post and the initial behaviour, add in some ‘show message’ actions between all your existing events so that between each ‘action’ in the behaviour you have a ‘pause/stop’. (do this initially for all the steps even if they are not ‘connect’ actions, and I would recommend you ‘save as new form’ so you then have one form with this ‘break points’ and the original as it was before), run the form in ‘debug’ mode so you can see all the actions as they run, and see if all the actions complete correctly then.
Depending on what your connection actions do, you may also be able to see from SQL itself that the actions completed correctly.
Referring to the Connection agent log files as well where you will see the time when the action was parsed by the connection agent and x- ref to the time the action ran in SQL may also help to see if there is an unexpected delay in the request being accepted in SQL.
If you run this with the ‘show message’ breaks in to confirm all works as it should but also note the time stamps and then repeat on your original form where there are none of these breaks to see if there are any significant differences that point to some connectivity issue between perfectforms and your database