PerfectForms Forums » General

1. tmrhymer
   Member

   I've got a form that is locking up in a weird way. When I say locking up I mean the page becomes sort of greyed out and everything is disabled, none of the buttons on my page are function and I have to refresh the page to get back to the perfect forms dashboard. I have narrowed it down to a behavior that runs and this is basically the order of commands.

   • Button is Pressed
   • Copy Fields Command (3 fields)
   • Connect Command (uses a value from one of the fields in the copy fields command, and stores a returned value in a helper page)
   • Set Field Command (sets a dropdown's value to the value that was returned in the connect command)
     • When that dropdown changes field data:
     • Run Behavior Command (This runs a behavior of a button on my helper page)
       • When that helper page button is pressed:
       • Connect command (grabs the value of the dropdown that changed field data and runs a sql stored procedure and sets the value of some more fields in the form)
   • Run behavior command (this runs a behavior of a button on my helper page)
     • When that helper page button is pressed:
     • I have a series of "loops" that remove any records in 3 different tables
   • Connect command (populates records into the first table that was just cleared)
   • Connect command (populates records into the second table that was just cleared)
   • Connect command (populates records into the third table that was just cleared)
   • Show Page command ("back to last shown")

   The form is locking up when the connect commands run that are populating the three tables. I've verified this with debugging and also by removing those 3 connect commands. However, if I take the Set Field command (the 4th item listed above) and move it to happen after the three connect commands that populate the tables, everything works. I'm not sure why but that fixes it and I wanted to find out the exact cause. Sorry if this is confusing, i thought it would help to write out the behaviors and the order they happened. I can submit a ticket and attach the form, but it has a number of connect commands for our systems, so i dont know if that will help much either.

   Posted 2 years ago #

2. ijobling
   Member

   If moving the 'set field' command that is involving the stored procedure to the end of this list of actions clears this problem up it would seem to relate to that stored procedure and it could be that it is still trying to 'complete' its actions when the subsequent connect actions are running and so causing a conflict. Have a look how the script actions run in 'debug' mode as you may see some additional information there, and also with your connections, refer to the connection agent log file, there may be additional detail there as well.
   It could be that the stored procedure isn't running quickly enough or your SQL server is not responding promptly enough, and the other subsequent actions are also running and causing conflicts

   but over all of this, do you have ALL these actions running from one form event ? I wonder if you are able to rationalise these to be more efficient or even split them up so that all are not running at the same time. for example are you able to invoke the first 'connect' action from when the LAST of the three fields that are being copied into has 'changed data', then invoke the 'set field' action from the last field that is written/changed from the connect action.. ie spread the load out so one 'action' runs when the previous has completed and so if your stored procedure is taking a while to complete there are not other subsequent actions trying to run until it has

   Posted 2 years ago #

3. tmrhymer
   Member

   I dug a little deeper and I think I've found the issue. I created a blank new form and put a button and a dropdown on it. I left the dropdown with the 3 default items (item 1, 2, 3), but I added a connect command to the dropdown changes field data event. The connect command runs a simple action that doesnt need any parameters and returns 2 fields. I didnt map those fields to anything in this test. Then in my button, in the button is pressed event, I have a set field command that sets the dropdown value to 3. and then runs a connect command right after that. The connect command is set up exactly the same as the one i added to the dropdown's event. In that very simple example, the form locks up/becomes disabled. Now, if you move the connect command in the button is pressed event to happen before the set field command, then it works fine. It's like the button is pressed behavior isn't aware that another event just fired and isn't waiting for it to finish and then it disables the form. Is anyone else able to reproduce this behavior?

   Posted 2 years ago #

4. tmrhymer
   Member

   Well these are all things tied to a page I use for users to search for customers. When a customer is selected all of these things need to happen in the form. They aren't all happening in one form event, the nested list items are occurring more in an indirect way. For example, when the set field command changes that dropdown's value, the dropdown changes field data event is firing because of it. I have these things broken out like that because there other events that need to execute the same set of commands and i wanted them to be reusable.

   Posted 2 years ago #

5. ijobling
   Member

   What you are describing here is expected. Connection actions are 'asynchronous' and occur independently of the main program flow allowing the main program flow to continue processing. It is a commonly used method in programming. If in your case here you have connection actions that rely on earlier connection actions to be completed first you should look at invoking these subsequent events from a different event (ie a field that is possibly written to from the earlier connection), or even look at implementing all your datatabase work into one stored procedure

   Posted 2 years ago #

6. tmrhymer
   Member

   It's not really that they rely on one another in this instance. In the example I described above in my original post, all the connect commands pretty much run independent of one another. They are all grabbing different data to help prefill the form. Is there documentation of this expected behavior? I know this is probably not a common issue, but knowing which events/actions will run asynchronously would be helpful. Also, when you say connection actions are asynchronous, do you mean to say that if I have a behavior workflow that runs multiple connection actions one after the other, they will basically execute at the same time and not wait for the previous to finish? If so, my connection actions run fine in that way. I have alot of events where multiple connect actions occur one after the other. In the issue I am describing and the simple example i created on a blank form, it really seems more like a bug. Especially, if multiple connect actions that do not rely on one another for data should be allowed to run asynchronously. Were you able to reproduce the behavior in the simple example i described?

   Posted 2 years ago #

7. ijobling
   Member

   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

   Posted 2 years ago #

8. tmrhymer
   Member

   The connection agent log doesn't really show anything out of the ordinary. These logs are again from my simple form described above. It's hard to tell if what you describe in your last post is built the same way as mine. I'm going to submit a ticket with it attached, also I am using stored procedures.

   2010-04-12 11:47:18 - v1.15.03 - IP:x.x.x.x - /ExecuteSqlProcedure
   INFO: SQL query [jdbc:jtds:sqlserver://sqlserver:1433/PerfectFormData]: {call dbo.pf_GetBranches(?)}

   2010-04-12 11:47:18 - v1.15.03 - IP:x.x.x.x - /ExecuteSqlProcedure
   INFO: SQL query [jdbc:jtds:sqlserver://sqlserver:1433/PerfectFormData]: {call dbo.pf_GetBranches(?)}

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in or register to post.