Why is a TDataSource needed when setting up master/detail relationships, say with a TFDQuery or TSQLQuery?
Why is a TDataSource needed when setting up master/detail relationships, say with a TFDQuery or TSQLQuery?
Why can't the detail dataset link directly to the source dataset?
edit: The reason I'm asking is that DisableControls ruins the master/detail relationship, a rather serious side effect in my view.
Why can't the detail dataset link directly to the source dataset?
edit: The reason I'm asking is that DisableControls ruins the master/detail relationship, a rather serious side effect in my view.
Yes, you need the TDataSource for master/detail, unless of course you directly define it in an SQL query.
ReplyDeleteThomas Mueller Well why? I mean, sure the TDataSet might lack some methods for this, but why haven't they been introduced? Why is living with the completely broken TDataSource design preferable?
ReplyDeleteBecause it makes the whole master detail relationship a lot more DAL agnostic.
ReplyDeleteIt's always a wise idea to use separate TDataSource instances for master detail relations and UI binding.
Jeroen Wiert Pluimers Does it? After all a TDataSource must have a property DataSet: TDataSet, so you can't abstract away the TDataSet.
ReplyDeleteInstead it completely muddles the UI and non-UI separation of datasets.
Jeroen Wiert Pluimers which unfortunately doesn't solve the problem of DisableControls disabling the relation, because that method will disable all data sources. I always wondered, why DisableControls is a method of TDataset rather than TDataSource.
ReplyDeleteThe reason I haven't discovered this serious flaw earlier is because I'm trying out FireDAC, and FireDAC requires that you use the TDataSource master/detail way if you want to have cached updates.
ReplyDeleteThomas Mueller Yes, that is also something I've always found puzzling since the first day I learned about TDataSet and TDataSource.
ReplyDeleteJeroen Wiert Pluimers Btw I don't share a TDataSource, instead I share code. That code may be called with datasets linked to UI or not, hence it calls DisableControls. Which works fine unless you use "managed" master/detail.
ReplyDeleteAsbjørn Heid ah, now I see what you mean.
ReplyDeleteFrom what I recollect is that the whole notification mechanism on which TDataSource rests was very beneficial for implementing the master-detail relationships.
Does DisableControls always break? i.e. with any DAL?
Jeroen Wiert Pluimers Based on the documentation[1] I'd say so yes.
ReplyDeleteIt does mention a work-around, I'm going to test this, however it just seems like such a huge flaw, I'm surprised they haven't figured out a better way.
[1]: http://docwiki.embarcadero.com/Libraries/Seattle/en/Data.DB.TDataSet.DisableControls
Asbjørn Heid You should use separate datasets for UI and logic
ReplyDeleteOliver Münzberg As I said, that's what I'm doing. What I'm sharing is code operating on those datasets (the user should see the exact same results as what the program will do when the user accepts the action).
ReplyDeleteIn Jason Whartons IBObjects there's /always/ a DataSet property to use if you do not want to add the extra TDataSource component. Even in the "TDataSet" compatible flavour. The design is sound imho, "links" between two TDataSets does not need a TDataSource. The compatibility for TDataSource is only there so we can connect "standard" UI (DBAware) controls to the components.
ReplyDeleteDany Marmur Interesting. At least that's a step in the right direction...
ReplyDeleteFWIW, I tested the work-around mentioned, using BlockReadSize, and that seems to work.
ReplyDeleteI also did a search through the Delphi RTL/VCL sources, and it seems the block Next() behavior is never overridden by anything. The default block Next() implementation is identical to the standard Next() behavior.