John,

No offence, ok?

Answer: Everywhere. The underlying premises don't hold. Correction: the underlying premises hold extremely well in specific cases, but fails sufficient general cases to make your one-dimensional message an unsuitable heuristic. In other words, you're overpumping this. Sorry <s>.

Here's why:

Nothing you've posted on this issue shows any sign of an underlying framework for technical analysis for this technical question. Selecting and applying data access tactics is an engineering decision, and the software engineer in me would appreciate it if you were to approach this more on an engineering basis rather than a single-dimensioned list-of-benefits basis.

Do you understand what I mean here? Here is an example of a similar sort of argument which, at its root, is anectdote masquarading as engineering:

"Airbags! Huge trunk! Low-flash luxury! Volvo! I can't understand why you people don't all drive Volvos. Everybody generally acknowledges that Volvos are a desireable way to go! Safety! Resale value! Volkswagens have the same utility as mopeds. Those who drive Volvos love 'em!"

Now I'm exagerating here, obviously teasing you, but unduely? I don't think so.

Please don't misunderstand! The "list of benefits" take definitely has its place, but *after* assessing what's required, what's generally possible, and eliminating what's impractical for a wide variety of angles. In other words, once "what really matters" is known.

To recommend a particular data access tactic without knowing "what really matters" in specific cases, as you are constantly doing, projects the tactic as the optimum solution to universal and general cases. Technically i don't buy that, John. You're pushing a heuristic that's too broad. It's not there; or at least I don't see it. Show me.

Moreover your technical (sic) advice on SPs is not supported by my 15 years of observing many projects and teams in a wide variety of crazy and amazing situations and places.

I'll concede this: The solution space of VFP and SQL back-end apps where 100% SP solutions are undeniably 100% correct is 15%. Absolute max. One in six, if that. For the rest, you're balancing forces and the desireability of SPs depend significantly more on non-functional requirements.

I never hear you asking people about those. You assume them, and so pump the tactic. No open-ended question seems to beg clarification before the selling of the Volvo solution begins.

I propose this: A good technical analysis in our domain involves elements that are from 3 broad categories: Software, Hardware, and Meatware, and all of it sits in the context of the functional and non-functional requirements of why we're developing this particular database application.

Now let's make a grid with that, and let's talk about each relevant cell, and what the forces indicating one tactic over another?

For example, for no application in particular, we might agree that in this case: "Using SPs probably imply a dedicated piece of nearly full-time meatware for developing and sustaining this database". This is either not an issue, or the killer reason to eliminate SPs from the tactical options because that database is too now expensive to be sustainable, say.

So technically (and tactically) speaking, can we please be more deterministic, and less anectdotal.


**--** Steve






>Steve..
>
>Please show me where I have been technically wrong in the RV v. SPT/SP issue...
>
>
>
>>Hi John,
>>
>>Those are hysterical responses. I really don't know what to say other than technically, man, you have a lot to learn.
>>
>>**--** Steve
>>
>>