I’m trying to understand the use of LoaData. For a Server App, this is not set but for a WASM App this is set for CRUD generated by RBS.
Trying to understand the difference & why needed for WASM Apps but not Server App.
For a Dropdown in a WASM App, the LoadData event is triggered when filtering to filter data but there is nothing for Server and yet it does filter. So why is LoadData needed?
I tried LoadData in a Dropdown control in a Server App but I’m getting an error as follows when trying to add records in the Add page
A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext. For more information on how to avoid threading issues with DbContext, see DbContext Lifetime, Configuration, and Initialization - EF Core | Microsoft Learn
What’s the impact of using LoadData in a Datagrid control in a Server App?
Appreciate some insight to understand the LoadData
In server apps you have direct database access and you can simply use DbContext and IQueryable unlike in WASM where the only option is to call a service (in our case OData) to perform the data access.
I understand the difference between a Server App & a WASM App in that sense but what I don’t understand is why for say a Dropdown the WASM App uses LoadData event where as the Server sets the data OnInitializedAsync. Is there a difference in the Dropdown list & the Datagrid such that for WASM LoadData has to be used to set the data whereas in Server it can be done OnInitializedAsync
It’s just two different binding methods used in different scenarios (server and WASM) because of the limitations described in my previous reply. If you have in-memory data only you can use OnInitializedAsync in WASM as well.
Would there be an issue moving the code that is currently generated in the WASM App under LoadData to OnInitializedAsync and remove the LoadData & Count from the Dropdown?