Devart Forums

Scenario: 100K customer (master rows) with an average of 10 contact (detail) rows each... totaling about 1M detail rows.

Without CachedUpdates I set LocalMasterDetail to false, and each time I scroll on the master dataset UniDAC fetches the 10 or so detail rows from the database. I can insert, modify and delete rows and all is done immediately (on Delete or Post).

With CachedUpdates I have to set LocalMasterDetail to true. If I understand correctly, this means UniDAC will fetch 1M detail rows and filter them out locally. In the above scenario this is really not feasible.

I can understand the reasoning behind how it is... UniDAC needs to have all the detail updates cached, and these could be detail rows of more than one master row. But this is just something you cannot do with a big database in a network environment. Too much network traffic and too much time and memory to load all that data in the client application that will probably not need most of it.

My question is... is this how CachedUpdates with a master detail actually works? If so... has anyone suggested to fix and enhance this on UserVoice? I've looked through the suggestions but have not found it.

As to how to fix it... well it is necessary to develop an hybrid solution (like FireDAC seems to do). Fetching should be done on master scroll, on an as needed basis (as when LocalMasterDetail is set to false). But any updates to detail rows need to survive the master scroll and be cached up to the Apply or Cancel updates call. I know that handling the cache this way is complex, but I really see no other way to manage CachedUpdates on a master-detail setup with big RL databases.

TIA for any feedback

If your db allows it then you might be better off with a Transaction that can be rolled back on Cancel.

Thank you for the suggestion. We will definitely consider the possibility of implementing the described behavior. You can leave your suggestions at our UserVoice page (http://devart.uservoice.com/forums/1046 ... 939-unidac), and if there are many votes for your suggestion, we will implement it.

@FredS: Keeping pending transaction while waiting for user input is IMHO asking for trouble... something I never do in my database applications. I gather all the input from the user and only when everything is known, start a transaction ad write everything I have to (or at least try). The only workaround I see in this case is to avoid cached updates... or to limit the updates to one master row and its detail rows.

@MaximG: so you do confirm that is how UniDAC handles cached updates with a master-detail setup? I will post a suggestion on UserVoice then.

As we mentioned above, in order to implement the behavior you need, it is more appropriate to use the transaction. After all, it is the use of transactions that serves to commit one or several changes in the database, or rollback of all these changes if necessary.
The main purpose of the CachedUpdates mode is to reduce the total number of queries and, accordingly, the load on the database server.
In our components, this mode when implementing the Master-Detail relationship can only be used with LocalMasterDetail = True. Yes, in this case all the data in the table will be loaded and processed locally. If you want us to consider the possibility of changing this behavior - leave your voice at our UserVoice service