ASSERT - Trying to update row outside a transaction. (15599)

Posted by justinfowler on 04-May-2010 09:06

I have a very very simple form with a probindingsource attached to a datagrid. pbs handle is a query on a temp-table ("for each ttBlah"). the pbs has 'AutoUpdate' = true.

The user updates the cells. The changes are saved to the temp-table just fine. User clicks save. I then loop through a buffer of the temp-table (for each bttBlah...) and check the data. If the data is bad an error is presented and the user can make the necessary changes. At this point I modify a cell and once I leave the cell I get the following error and change is reverted:

--------------------

ASSERT - Trying to update row outside a transaction. (15599)

The Progress.Data.BindingSource supports a row-based transaction model. The user has inadvertently began editing a row outside a transaction. You cannot rely upon these changes to be assigned to the ABL DataSource.

--------------------

While typing this I had been trying different solutions to make this go away. If I run the query-prepare and query-open commands on the query attached to the pbs the error goes away.

Thought I would still share the solution/workaround since a search on the topic produced no relevant results.

Thanks,

Justin

All Replies

Posted by maura on 04-May-2010 12:42

You shouldn't be reopening your query to get around this issue. I wrote a sample appl following your steps and do not see the problem.

If you send along your code, I can take a look at it and see what the problem is.

Maura Regan

Posted by justinfowler on 06-May-2010 14:11

Hi Maura,

Sorry for the delay.

Find attached the code to reproduce the issue. No database necessary. Run runMe.p.

Steps to reproduce:

1) Edit 'Field 2'

2) Press Tab

3) Press Button, gives my data error and aborts the save routine.

4) Edit 'Field 3'

5) Press Tab - ASSERT Error.

Let me know what you find.

Justin

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/2768.runMe.p.zip:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/0763.test1Form.cls.zip:550:0]

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/3073.test1Form.resx.zip:550:0]

Posted by maura on 07-May-2010 14:05

Hi Justin,

I'm able to reproduce your issue. I've determined that it's a DataGridView issue. I don't see the issue when I replace your datagridview with an Infragistics ultragrid.

Also, I've created a reproducible case outside of the ABL, with just a .NET solution which I will send along to Microsoft as a bug.

The problem has to do with the control's use of the BindingSource's BeginEdit() and EndEdit() calls. When you click on the button, the control calls the bs:EndEdit().

Then when you click back into the field, it doesn't call BeginEdit() (which the ultraGrid does do). When you make the change, and then tab out, the SetColValue() is called,

but throws the exception because you're not in a row transaction.

Unfortunately, I was not able to come up with a workaround, other than changing the bs:Position property, which is not what you want.

Maura

Posted by maura on 24-May-2010 09:56

Justin,

I just heard back from Microsoft and they have a workaround for this issue. The workaround is to set the DataGridView's CausesValidation to False. I tried it and it works nicely.

Maura

Microsoft’s response in a nutshell:
The BeginEdit method is called when row currency changes. So as you navigate between rows, we will see BeginEdit being called. Likewise, EndEdit is called automatically before the current row is exited.
When you click outside the DataGridView control to another control, this is causing the DatagridView to validate, hence call EndEdit()
Then, if you set focus back to the same row in the DataGridView, the current row has not changed. In other words, row currency is still the same and therefore BeginEdit is not called.
“One way you could resolve this issue would be to set the DataGridView's CausesValidation property to False. This would prevent EndEdit from being called when you click out of the control. So when you click back onto the same row you left, you are still technically within the same edit (or transaction), and any other edits to the same row would succeed without the assertion taking place. “

This thread is closed