John...


>
Really? Ability to use multiple backends without the "cost" of acquiring or buying expertise in every backend, is itself flexible.
<

In theory yes. However, for the most part, this is a dream that has never been realized. This was the promise of RV's. John, you will need to explain to one of my current clients - one that I have helped them eradicate one of the "commercial frameworks" because of the use of RV's and the whole promise of having 1 set of client code for multiple backends. WIth DataClas, at least they have a delieverable. Yes, you will need to sit with them and tell them why they must be mistaken when the "inflexible" way works and the "flexible" way does not work....< bg >..

<<
Your own inability to engage Cache because you have fixed on SPs,
<<

Again, I don't care about Cache. It is not MY topic. And since it is not MY topic, I won't comment. You show me some serious work that is being done with the product, then I will give it some consideration. I went to slashdot to see if I could find anything relevant. No Dice. Sorry John. If it is not something in the mainstream like SQL, Oracle, DB2, and the the like, I really don't care to discuss.


>>>Multi-table updates are extremely difficult - if not impossible to manage.<<
>
>There is is again. Can you justify this assertion please. Oh, I'm assuming you have an accessible primary key for each table... if not, then you do indeed have a problem, but it's not a RV problem.
>

You snipped to much here. The context of this comment was in the area of RV's. If you use stored procedures, it is a snap. Yes, it is a RV issue.


>>>And, if you are in a shop that requires the use of stored procs, RV's won't do. This is an area that you are ignoring.<<
>
>This is like saying "my client only allows Mazdas as company cars so all other marques are lousy". It adds nothing. If you have to use SPs then you have to, but that is not a reason to criticise others which is the "topic" after all.
>

Again, RV's cannot make use of stored procedures. This is quickly becoming a useless discussion.


>>> From a performance perspective, SP's are faster.
>
>So you say. whether that has any "meaning" in the real world is not shown.

Rod and I have an app for a bank that is in the "real world" that would indicate otherwise...


>
>Is there no useful evidence at all to support your position? Surely a clever fellow like you did not choose SPs just because "everybody knows" they are faster and better? Whatever would the FDA say?
>

Yep, I guess not. I don't have a clue of what I am saying... Thanks for clearing that up John..

Henceforth, any replies from you on this topic will be deleted from the indox immediately...

< JVP >