Hi, i have a weird case and not sure what is causing it. the code below runs DeleteMulti with no problem but skips SaveMulti for some reason.

var trans = new Transaction(IsolationLevel.ReadCommitted, "UpdateGradesForStudent");
int classId = Convert.ToInt32(this.Page.Request["classId"]);
int studentId = Convert.ToInt32(this.Page.Request["studentId"]);
GradeBookCollection toDelete = this.CollectEntitiesToDelete(classId, studentId: studentId);
GradeBookCollection toAdd = this.CollectEntitiesToAdd(classId, studentId: studentId);

trans.Add(toDelete);
trans.Add(toAdd);
toDelete.DeleteMulti();
toAdd.SaveMulti();
trans.Commit();

I call this in a try catch statement and it runs with no exception but even though there are like 20 entities in toAdd collection, none is saved in. All items in toDelete are deleted but nothing will be added.

If i remove the transaction it works just fine. Deletes are done first, then the inserts are persisted.

Am i missing something here? thanks

What do the methods CollectEntitiesToDelete/CollectEntitiesToAdd ? Is there any difference if you put those calls some lines above? :

int classId = Convert.ToInt32(this.Page.Request["classId"]);
int studentId = Convert.ToInt32(this.Page.Request["studentId"]);
GradeBookCollection toDelete = this.CollectEntitiesToDelete(classId, studentId: studentId);
GradeBookCollection toAdd = this.CollectEntitiesToAdd(classId, studentId: studentId);

var trans = new Transaction(IsolationLevel.ReadCommitted, "UpdateGradesForStudent");
trans.Add(toDelete);
trans.Add(toAdd);
toDelete.DeleteMulti();
toAdd.SaveMulti();
trans.Commit();

Is there any relation between the entities you are deleting and the ones you are saving? It may be that you delete the entities and then you add them again. Try with IsolationLevel.Serializable.

And finally, you also could use a UnitOfWork here, which just add the operations and then when you commit it, it will wrap all operations in a transaction.

CollectEntitiesToDelete goes through a series of form items and creates an entity collection. CollectEntitiesToAdd goes through the same form and creates another entity collection and yes the entities that are deleted and the ones that are created may be the same entities.

trans definition is outside the try catch block which i havent shown here so defining it right before the delete and save methods isnt really an option.

i ll try .Serializable and see if this makes a difference.

thanks -shane

daelmo wrote:

What do the methods CollectEntitiesToDelete/CollectEntitiesToAdd ? Is there any difference if you put those calls some lines above? :

int classId = Convert.ToInt32(this.Page.Request["classId"]);
int studentId = Convert.ToInt32(this.Page.Request["studentId"]);
GradeBookCollection toDelete = this.CollectEntitiesToDelete(classId, studentId: studentId);
GradeBookCollection toAdd = this.CollectEntitiesToAdd(classId, studentId: studentId);

var trans = new Transaction(IsolationLevel.ReadCommitted, "UpdateGradesForStudent");
trans.Add(toDelete);
trans.Add(toAdd);
toDelete.DeleteMulti();
toAdd.SaveMulti();
trans.Commit();

Is there any relation between the entities you are deleting and the ones you are saving? It may be that you delete the entities and then you add them again. Try with IsolationLevel.Serializable.

And finally, you also could use a UnitOfWork here, which just add the operations and then when you commit it, it will wrap all operations in a transaction.

the entities that are deleted and the ones that are created may be the same entities.

I'm not sure I understand this line correctly. Are the entities inside the ToAdd collection new entities, or previously fetched from the database?

Coz if they are New entities, then they can't be the same as the deleted entities, even if they hold the same data, we can't say they are the same entities. (At least an Identity PK would be different).

If they are previously fetched entities, then the SaveMulti() would produce UPDATE commands rathern than insert commands, and these should have no effect if the entity was previously deleted.

There is no identity pk for this entity, it has a combined pk. Same or new, what does the transaction change here?

I do get it out of the picture and it works, put it back in and savemulti is getting ignored. thanks

Walaa wrote:

the entities that are deleted and the ones that are created may be the same entities.

I'm not sure I understand this line correctly. Are the entities inside the ToAdd collection new entities, or previously fetched from the database?

Coz if they are New entities, then they can't be the same as the deleted entities, even if they hold the same data, we can't say they are the same entities. (At least an Identity PK would be different).

If they are previously fetched entities, then the SaveMulti() would produce UPDATE commands rathern than insert commands, and these should have no effect if the entity was previously deleted.

Please check the generated SQL queries in the case of the Transaction. I guess he UPDATE statements are executed against phantom rows, which get deleted when the transaction commits.

Probably cause SaveMulti does not create any sql query. I can see the delete statements DeleteMulti creates but SaveMulti will do nothing at all even thought there seems to be many entities in the collection.

Just for the sake of testing could you please let CollectEntitiesToAdd() return a list of new entities, ready to be inserted. And see if they got inserted or not.

it works.

Walaa wrote:

Just for the sake of testing could you please let CollectEntitiesToAdd() return a list of new entities, ready to be inserted. And see if they got inserted or not.

I'm afaraid I have to ask you for a repro solution so we can trace this out. It would be great of you can provide a solution based on Northwind.

Since it works this way, doesnt really matter but i ll try to create a simple page. thank you

Walaa wrote:

I'm afaraid I have to ask you for a repro solution so we can trace this out. It would be great of you can provide a solution based on Northwind.

We will close this for now, but feel free to reopen it if you have a repro case.