BUG - No Question, for any Enter New (SOLVED)

ddumas

I have processes that do ENTER NEW xxxx. In my opinion, ALWAYS using process for entering new records is much better because you can add richer functionality to your app.

The rule operation just after the ENTER NEW is not getting executed, unless I add a "pause" by doing a Display Message "You have just entered a record, blah blah" between the ENTER NEW and the next rule that is not getting executed. This message has the effect of letting the ENTER NEW "complete"

After the ENTER NEW, with the display message inserted in between, the next operation executes properly. So, it looks like that there is a latency issue after the ENTER NEW is complete when the user clicks on the Create button. My workaround fixes the issue but is just a band-aid.
Dave

PointsWell

ddumas wrote
I have processes that do ENTER NEW xxxx. In my opinion, ALWAYS using process for entering new records is much better because you can add richer functionality to your app.

The rule operation just after the ENTER NEW is not getting executed, unless I add a "pause" by doing a Display Message "You have just entered a record, blah blah" between the ENTER NEW and the next rule that is not getting executed. This message has the effect of letting the ENTER NEW "complete"

After the ENTER NEW, with the display message inserted in between, the next operation executes properly. So, it looks like that there is a latency issue after the ENTER NEW is complete when the user clicks on the Create button. My workaround fixes the issue but is just a band-aid.
Dave

Can you share the code please? Or an anonymised version of the code.

aware_support

ENTER NEW is used in hundreds of apps and no one complained about this yet. You must be doing something wrong there

ddumas

It's not that Enter New is not working. I use Enter New allot. The issue occurs in a Process that uses Enter New. After the Enter New, as the next step in the process, I call a process that does an exec stored proc, which sets several computed attributes. Stored procs are great for setting these types of things. When I put a Display Message 'xxx' in the middle between the 2 steps, the stored proc gets executed.

So, to me it looks like there is a latency issue of using an Enter New within a process.

I hope I have explained this well enough.

Dave

aware_support

There is no latency after ENTER NEW (like I said, it is used in hundreds of apps and if there was any latency we would be inundated with bug reports). Something very specific to your app must be going on. Check the rule log - maybe it will give you a few clues.

ddumas

So, think of it this way:

The Enter New has to issue a database commit with an insert statement.
If between the time that the Create button is clicked in the Form, the stored procedure is called with the next command, and the record has not been committed to the database yet, then the stored proc will be reading stale values.
The Display Message 'xxx' forces the commit to occur before the stored proc gets called.

Does that make sense now?

Dave

aware_support

So this is specific to calling a stored procedure after ENTER NEW? Still strange - commit of the database should occur before the next action in the process is executed. But maybe something is not quite right there...

ddumas

Yes. I would check there to make sure that the commit has occurred before the next statement in the Process starts.

Rennur

The Enter New has to issue a database commit with an insert statement.

In my experience the Process does not commit the transaction into the database until the entire Process is finished or there is a DISPLAY QUESTION action within the Process Rule.

Have you tried using the COMMIT TRANSACTION action?

ddumas

HUGE Help! Thanks so much. The Commit Transaction worked perfectly, and gets rid of the pesky Display Message in between the Enter New and the exec stored procedure to force the commit.

I owe you a beer!

Thanks again,

Dave