Devart Forums

Hi,

i have some sudgestions for you, ODAC developers . But let's take them one by one.

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 . Why have only 1 Master and only Master-Detail based on 'AND' ? Well, more than one master in design time needs some forms to implement, but in run-time one could simply .AddMaster(, , ). And the WHERE clause... yes, i know it's created automatically... but i think it's not so hard to do something like MasterFields='name+NULL;-NULL' and DetailFields='name;address' which would translate into NAME=:NAME OR name IS NULL AND ADDRESS IS NOT NULL... or ? The

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 But generally... nothing that i wrote here, is not difficult . I already did it.

I also think this things will put you way on top of your competition... at least for a while

10x

Imadean,

Thank you for your suggestions. The ideas you present sound interesting and thought through. We appreciate the time you have taken not only to work through the usage scenarios, but to present them in a clear and coherent way. We did not have the functionality you proposed planned; however, we will discuss these suggestions and will consider adding them to future releases.

Thanks

Hi,

i just remembered one more thing... about AutoCommit. If i set autocommit on a session object, i would expect that any insert, update or delete action, run from anywhere (TSmartQuery, TOraQuery, TOraSession...) is followed automatically by a commit. If i set AutoCommit on a TDataset descendant i would expect that ONLY the insert, update delete statement(s) of the dataset are commited through an AUTONOMOUS_TRANSACTION. I think this is also really easy for you, and is of great help for developers, because they won't be required to write the same thing every time they need this.

I could understand if you would create a new property for compatibility reasons.

thanks in advance !

We'll consider possibility to implement this feature in either of the next ODAC builds.