LLBLGen 2.0.7.424 / ASP.net 2 / Adapter

Hi

I have a LLBLGen datasource bound to a data grid. The code is the following:

    protected void qualificationDataSource_PerformSelect(object sender, PerformSelectEventArgs2 e) {

        qualificationDataSource.EntityCollection = Employee.EmployeeQualification; 

    }

    protected void qualificationDataSource_PerformWork(object sender, PerformWorkEventArgs2 e) {

         // loop through entities to update
        foreach(UnitOfWorkElement2 element in e.Uow.GetEntityElementsToUpdate()) {
            
            // find entity to update in collection
            EmployeeQualificationEntity item = (EmployeeQualificationEntity)element.Entity;
            List<int> list = Employee.EmployeeQualification.FindMatches(EmployeeQualificationFields.Id == item.Id);

            // exchange entity with new version
            int index = list[0];
            Employee.EmployeeQualification[index] = item;

        }

    }


    public EmployeeEntity Employee {
        get { return (EmployeeEntity)((IParentDialogPage)Page).Entity; }
    }

(the example does not support add or delete items. I just wanna focus on update.)

This code works fine when using the standard MS datagrid. In my case I use the Infragistics one. The main difference is that with the Infragistics grid I can edit several rows on client side and send all changes to the client in one go. I would expect that the UnitOfWork object contains just all the updated objects. In reality PerformWork is called as much times as I changed rows. So when I change 3 rows PerformWork is called 3 times! The first time the UOW object contains 1 item, the second time 2 and when PerformWork is called for the last time it contains 3 items. Isn't that funny? Additionally, in the last call of PerformWork the above standing code throws an error because one of the entity contained in UOW is not in the collection anymore (Employee.EmployeeQualification).

How can I resolve that? Can somebody confirm that behaviour?

Additional hints: - I asked a similar question some days ago and somebody wrote that PerformSelect resets the datasource. Because my collection is referenced (Employee.EmployeeQualification) it would be set to null too. Walaa then wrote that the datasource.collection is not reset and always contains values. I can confirm that as my code works with the MS grid. - ViewState is enabled in all controls.

I would expect that the UnitOfWork object contains just all the updated objects. In reality PerformWork is called as much times as I changed rows. So when I change 3 rows PerformWork is called 3 times! The first time the UOW object contains 1 item, the second time 2 and when PerformWork is called for the last time it contains 3 items. Isn't that funny?

The UOW of work holds the changed and un-commited entities, and since you don't commit/save the changes to the database, they are maintained in the UOW, and can be seen in subsequent calls to the Perform_Work.

If you process the changed entities one at a time and you don't want to keep them in the UOW for subsequent calls, you may remove the processed entity from the UOW after processing it in the Perform_Work handler.

Additional hints: - I asked a similar question some days ago and somebody wrote that PerformSelect resets the datasource. Because my collection is referenced (Employee.EmployeeQualification) it would be set to null too. Walaa then wrote that the datasource.collection is not reset and always contains values. I can confirm that as my code works with the MS grid. - ViewState is enabled in all controls.

Just for reference, the thread mentioned here is: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10072

The MS grid always posts back after a single row change, so multiple row changes are multiple postbacks on the MS grid. the datasource control can handle multi-row changes, tested with devexpress asp.net grid which sends multiple row changes in 1 postback.

Thanks for your answers!

The UOW of work holds the changed and un-commited entities, and since you don't commit/save the changes to the database, they are maintained in the UOW, and can be seen in subsequent calls to the Perform_Work.

Ok, this is something I have to test over the weekend. What I'm gonna do is to remove the PerformSelect (I will do it in PageLoad if IsPostBack=false). And in PerformWork I will not execute any operations until saving the page to the db. I'm not sure but as far as I remember that may not work because the datasource is reset if PerformSelect is not there. I will see..

The MS grid always posts back after a single row change, so multiple row changes are multiple postbacks on the MS grid.

Yes, dealing with the MS grid is not a problem. But to handle multiple postbacks is not the same as handling multiple executions of PerformWork in one postback!

tested with devexpress asp.net grid which sends multiple row changes in 1 postback.

That's interesting! Is PerformWork fired several times when updating more than one row? I do not say that there is something wrong with the LLBLGen datasource. It's most likely my code or possibly something strange in the infragistics grid..

It's a bit complex to explain why it is a problem that PerformWork is fired several times. Somehow I can't copy objects from the UOW to my collection because something (a ghost??) changes the collection after PerformWork is fired for the first time. I will elaborate this a bit more at a later date. I don't have time right now.

Ok, this is something I have to test over the weekend.

I will elaborate this a bit more at a later date. I don't have time right now.

Will be waiting for your feedback.