CRUD & Store & LinqDataSource

[cwolcott]

After I thought I understood how the interchange between the Store and its DataSource (which is a asp:LinqDataSource control) worked I was thrown for a loop today and can't find anything to explain what I need to do. I will try to simplify it to one of two issues that I am having. All of my code is on a closed network that I can not pull from. If in am not clear I can try to write an example tonight.

I have an asp:LinqDataSource with onUpdating="LDS_Updating" and onUpdated="LDS_Updated".
I have an ext:Store who's DataSourceID="theAboveLDS" with onBeforeRecordUpdated="Store_PreUpdate" and onAfterRecordUpdated="Store_PostUpdated" and AutoSave="true"
I have an ext:GridPanel who's StoreId="theAboveStore"
I have an ext:RowEditor via the GridPanels plugin.

The Grid shows the selected data from the database. There is an ID field that is the primary key and identified in the JsonReader and the IDProperty. The "name" field does have a unique constraint defined in the Database, but no where else. I then update one of the rows "name" field to match another name, thus violating the unique key constraint in the database. When the data is submitted via the RowEditor I can watch each of the 4 events fire in the correct order.

1) Store_PreUpdate - Nothing happening here ...
2) LDS_Updating - Nothing happening here ...
3) LDS_Updated - SqlException raise (Violation of UNIQUE KEY constraint). JUST what I wanted. I have then tried both e.HandledException = true and false.
4) Store_PostUpdated - Depending on what I have set above the exception is passed on (e.HandledException = false) or cleared out (e.HandledException = true).

My question is how does the name field I changed get set back to its original value since the operation failed? Should it have been automatic or did I need to do something?

Sorry about this basic question, but I just can find a documentation on it.

[Daniil]

Hi,

Please investigate the following thread.
The GridPanel/Store saving description

The details in the thread are still actual.

Hope this helps.

[cwolcott]

I will spend tonight reading through the thread and hopefully working a simple example.

One releated question. Should the old values parameter being sent in AfterRecordUpdatedEventArgs be empty? The old values parameter being sent to BeforeRecordUpdateEventArgs is populated correctly.

[Daniil]

I think it should not be empty, I will check.

[Daniil]

It's empty within BeforeRecordUpdate as well.

I found this in the thread I've referred.

OldValues (now always empty, in future will be contain old values)

As far as I can understand it's still not implemented.

I will check it asking my colleague and come back.

[Daniil]

Confirmed, it's not implemented and no plan to implement.

Generally, you should have old values on a server. I mean a data which you bind to a Store.

Agree, not so comfortable, but a solution.