SP's are a better way to go. However, that is a secondary issue to SPT being better than RV's.

As I have said numerous times, the issue is not whether you shoud use RV's or SPT. The issue is whether you should use SPT in conjunction with SP's.

As for a single data access tactic, actually, I use 2: ODBC and OLE-DB. As far as I know, those are the only two generally accepted remote data strategies we have in VFP. I don't use the RV wrapper to SPT for the same reason I don't update data through the ADO recordset object; it is technically flawed and inferior to better approaches out there. In the case of RV's, the better approach is SPT. A further improvment to SPT would be the use of SP's. With respect to the ADO recordset, the better approach is the ADO Command Object. Again, with the command object, you can render client-side updates or invoke a stored procedure. The latter is the better approach from a performance and security standpoint.

Why don't you take apart the arguments from a technical perspective instead of using ad hominum tactics. To date, you still have avoided the substnative technical arguments.




>So in summary: In the past 24 months you have delivered 6 C/S apps using a single data access tactic. Good for you. Applause.
>
>How this translates into your tiresomely repeated message that this data access tactic is universally to be recommended remains a puzzle to me. You lost me. No terms of reference, no acknowledgement of nuance within the solution space. It's a technical truth: SPs rule supreme, everywhere.
>
>I'm just dim, I guess. I just don't see it.
>
>
>**--** Steve
>
>
>
>>Go to the bottom, I replied below. I did it for your benefit because I know how "aggravating" that is for you to have to page down to find the response.
>>
>>I too can poke fun. Yes, I am often a dick. At least I can admit it.
>>
>>But you know what Steve, you can be one too!
>>
>>Obviously, this is in response to the person you lashed out at for replying at the bottom of a post.
>>
>>< bg >
>>
>>
>>>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
>>>>>
>>>>>
>>
>>
>>
>>
>>Steve..
>>
>>Just to cut through the BS here... your bascially stating an OPINION that I have not made out a good technical argument. That is fine as you are entitled to your opinion. FWIW, I have enumerated countless times why RV's don't pass muster from a technical standpoint. You throw out 15 years of experience. I'll throw out 6 C/S application delivered in the last 24 months.
>>
>>From a technical standpoint, I have outlined issues on performance, security, maintenance, error/exception handling, stored procedure support, etc. Instead of whining and complaining, why don't you take those issues on? Bascially, your only response is that I am wrong becuase you think I am wrong. I don't see a lot of technical merit in that.
>>
>>Maybe I am just a bit blue-collar on this issue and with application development as a whole. I have read your post below a few times, and quite frankly to me, it is one of the most incoherent things I have ever read.
>>
>>In my not so humble opinion, you can take your heuristic this and heuristic that and your functional this and non-functional that and stick it.
>>
>>As for anecdotal experience and opinions, as I said, in the last 24 months, I have delivered 6 C/S apps (all VFP, all SQL Server, and no RV's) These apps range in size to medium, to big. I have yet to run into the problems people constantly complain about with RV's. If you don't like the way I go about solving problems, fine, that is your opinion and you are entitled to it...
>>
>>As for offense, you are the one lobbing the ethical accusations my way without merit. You still need to be a man, take your medicine, and apologize for that faux pas...