Hi Rox...
>
now hold on here a minute... VB has to get the data first too??? And with VB, your only option is to do everything the ADO way. Yeah sure I agree ADO's strength is being language neutral, but ADO seems pokey. FWIW I *really* like Erik's example on this thread of transporting via xml and updating via ADO! Way cool out-of-the-box thought there! Sounds like that example is taking advantage of the best of multiple technologies in my humble opinion.
>
Does VB or VFP for that matter "have" to get the data? Or more specifically, does either have to munge the data? I would say that in all cases, some data has to be retrieved. The question becomes what does the munging. In reality, ADO is a non-issue. Yes, VB does not have "native" data handling abilities like VFP. Is that a bad thing? I would contend it is not a bad thing - so long as you know what you are doing. I contend that you can do a great deal of "data munging" in stored procedures.
What is the advantage?
From a performance standpoint, there may or may not be one. That is a matter of skill and how artful a developer you are. The key to my issue is what a VFP cursor implies. It implies that you must use VFP - for that is the only place a VFP cursor can exist.
Again, I ask the question: "Does one use VFP because of some intrinsic feature of VFP that cannot be found anywhere else or because it is the only language one knows?"
FWIW, I don't care what the answer to the question is. It does bother me when folks tout a supposed advantage that VFP has - when no such advantage exists. String handling, data munging, etc. Somehow, the rest of the world seems to be able to do it. Why is that?
IS ADO pokey? I guess if you try to consume 10K records. But then again, in these type of apps, when does one have to do that? Think long enough, and anybody can come up with a scheme to make any system break. Try to open a DBF over a WAN and watch VFP crawl.
As for Erik's work in ADO/XML - I think that is all good stuff. Then again, I don't see where VFP is an indespensible part of the equation.
>
So now I have scenario question for you John - if no such conditions exists on C/S project that specify which development languages you can or can not use. And the requirements call for a backend data store that is NOT VFP, and you need to carry result sets of say 20-50 records to the client for viewing/editing. And on an edit, let's say there is tons of complicated validations and lots of related lookup actions that need done before data is written back to the data store. And the requirements further state that failed validations mean lots of end user prompting, idiot messages, and hand holding. And the whole reason your on the job is that validation handling in existing system is so freaking slow the client doesnt want to invest any more time in adding functionality to that app, they want to start over and speed is their big hangup. Would you strictly lean towards ADO in a situation like this and not consider taking advantage of VFP's cursor handling strength?
<
No offense, but I am going to break this up.
1. No conditions exist on the development language.
2. VFP is Not the Data Store.
3. Data Requirements
3.1 20-50 records to be returned to client for viewing/editing.
3.2 tons of complicated validations and lookup actions to be done.
4. UI Requirements
4.1 Failed validations require lots of user prompts, etc.
Why am I here...??
The existing system is so freaking slow the client does not want to invest any more time in adding functionality in that app, they want to start over and speed is their big hang-up.
What would I do:
1. Strictly lean toward ADO?
2. Use VFP and take advantage of VFP Cursor handling strength?
Gee, where do I begin? First, let me start with the conclusion. If I were faced with this problem and I could use any dev language and I had SQL Server to work with or Oracle, it would be n-tier in nature and in all liklihood, I would use VB. For one reason, if I leave this client with this app, I am compelled to put him in the best situation of being able to find other folks that can add functions or maintain the app. It is not as though VFP developer's are dropping out of the sky. Second, because I would do this in an n-tier fashion and given the requirements, VFP cursor don't serve a demonstrable advantage...
Clearly, you have tried to set up the problem to be one that would "appear" to favor VFP. You see Rox, that is the big illusion out there - that VFP is the only tool out there that can handle this sort of work. Nothing of course could be further from the truth.
OK, lets take it step by step starting with the data requirements:
1. If I have to return 50 records max, ADO can handle that via a disconnected recordset standing on its head.
2. If there are tons of validations to be done via lookups, those lookups can be populated very easily. If there are other interactive validations that need to be done, that can be done via business objects or with stored procedure calls. It is debateable as to where the right place for that work is.
With respect to the UI prompting, that is not a difficult issue to address at all. If I am calling biz object methods which may or may not be calling stored procs or if I call stored procs directly, I can prompt the user using any language. Not a big deal.
Now, what about updating all 50 records. I would start a transaction on the ADO connection object, spin through the recordset, update command object parameters, execute the proc, and check to see what happened. If it failed, I can bail on the transaction and inform the user about what was wrong with the offending record. You can make it as elaborate as you want. It is just a matter of understanding the lay of the land.
Obviously, if VFP is all I knew, I guess I would be forced to use VFP. Of course, this example was very easy. What about parent/child relationships? Glad to say DataClas COM has all of these issues addressed.
Last word... Often, if folks find ADO slow, it is usually a result of those people using ADO incorrectly. I have had a lot of success with ADO. I have worked with it now for almost 3 years. It has taken a while to get the hang of things. That was the idea of the whitepaper - to flatten the learning curve for people.
< JVP >
