i have some sudgestions for you, ODAC developers
1. The first one would regard "multiple" Master-Detail. Consider a Master-Detail relation between two datasets. What happens is that the Details query is changed so as to reflect through prior stated parameters the active record of the master. Imagine the same relation with an EXISTS clause in the detail. I think i said it all already. One would be able (through a design time property - lets say "MasterDetailMode") to specify that the detail should the records from the detail base query that match not only the active record, but the whole dataset, based on the same MasterFields, DetailFields design time properties. Of course, the generated query should "copy" in the select of the EXISTS clause, all the parameters of the master query. It would be even nicer if this could be implemented for non-database descendants of TDataset
2. Imagine a Master-Detail as you know it. MasterFields='key;value', DetailsFields='key;value'. Unfortunately, the master dataset does not have the value field, as it is a one row dataset. Of course there are ways to trick this, but what if you had a design time VirtualParams property where you can say that field 'value' is a virtual parameter and get it's value on an event ? I think it would be nice and handy...
3. The third sudgestion regards an improvement in the use of parameterized queries. All component developers at the moment require programmers to first declare the parameters and then assign them values prior to calling Open or Refresh. This is not so bad, but consider that at some moment in time, you have a dataset on which you would like to declare 2 clases of parameters. One is dynamic and the other one is static.
Let me give you an example: You have a table of employees. the table contains ID, name, telephone, adress and lets say TYPE (CEO, Accountants and Normal). You want to create a form where you will search for an employee, but you will never search through different types of employees. This would turn into a query like: SELECT ... FROM ... WHERE TYPE=:TYPE AND "dynamic". The dynamic part of the query can be NAME=:NAME, or it can be TELEPHONE=:TELEPHONE AND ADDRESS=:ADDRESS.
This can be done by the majority of the components on the market only by reprogramming the query changing mecanism every time. Just imagine a property called for example DynamicParameters which specifies (like MasterFields and DetailFields, a list of field names which would be used to recreate the query) and furtermore, imagine and event that would be called to retrieve parameter values on refresh or open...
You have Macros, but for a user (in this case a programmer), it's all about the workflow
4. How do descendants of TDataset work. Well, you have some data, you put it into a buffer making it available to controlls that use it. Sometimes, you get to the point in which you hae all the data loaded into the memory. But the necesity of having the same data in another window comes up ? why read the data again, when you could have a design time property which points to another TDataset component which already has it and you can simply access it ? And, if this dataset is freed then the seccond can keep it's data
5. This one is a two-in-one thing
Ok. As a final word, I am NOT criticising anything here. I am simply sudgesting some improvements. If they can or cannot, will or will not be implemented that's up to you guys. I posted this because i am employed as an application developer, so improving components should not be my job
I also think this things will put you way on top of your competition... at least for a while
10x