Kevin,

I will add some comments in-line


>1) When I referenced SPs earlier, I was referring to them in the area of retrieving rules that were stored in tables. Yes, the validation layer is critical and doesn't need to be tied to the specific back-end.
>
>2) Yes, VFP is well-suited for handling data - but remember that .NET isn't just about C#. .NET includes ADO.NET, which has data-handling capabilities as well. It may not be a full-blown DBMS and may not have a full implementation of SQL, but contains sufficient functionality for manipulating data.
>
>When coming from another tool (like VFP), yes, ADO.NET may initially seem a challenge - but those with experience in it know how to utilize it, and this experience can be leveraged. Some on this forum (and many other forums) have applied the "elbow grease" and have learned how to accomplish data manipulation tasks in ADO.NET.
>
>Additionally, the publications of authors like Bob Beauchemin and Dino Esposito cover many different situations where ADO.NET comes through. Jay can utilize the knowledge of those who have "been there and done that". If I were starting .NET today as opposed to 3 years ago, I'd have the benefit of much more public knowledge. (And actually, I'm now realizing that there was more out there a few years ago than I realized). One can do more in ADO.NET than what is commonly recognized by non-.NET developers.


What ever happened to the "Best tool for the job"? In reading your point, I read "Well yes, VFP is better for this task, but we can settle for ADO.NET, although not as capable, it fits my argument of pushing .NET <g>

Disclaimer, I am just commenting on your post, not trying to make any comment on the tool.


>3) If Jay's organization has previously written COM components in VFP and wishes to re-use those components to shorten a development cycle, that's one thing. But setting out to write COM components is another. New investment of VFP code in a .NET project, is, IMO, not an advised use of time and money. (Some would call it a waste of time and money, and I don't disagree!)
>


Of course, and always commenting on your post and not the "tools", some other people might also consider moving everything to .NET using ADO a waste of time and money, for it is not, as I undestand from your post, with phrases like "comes thru" or "One can do more in ADO.NET than what is commonly recognized by non-.NET developers." as powerfull or capable as VFP for handling data, then, why rewriting to a "lesser" tool? Maybe is cheaper to keep VFP and add the required functionality by other means.


>You have to introduce additional code just to deal with the interface. True, you may be building something similar in concept, but the tool chosen should be consistent. When starting out, it's best to keep languages/tools/debugger/version control consistent and write everything to the target development tool. Mixed environments can sometimes be messy and can sometimes require additional efforts to manage, compared to sticking with one tool. I'm doing contract work on a development project going from a large Fox app to .NET with over half a dozen C# programmers, and could definitely see the additional challenges of mixing environments.
>
>4) As others have stated, sticking with one tool (in this case, .NET) allows all developers to take advantage of all the capabilities of the tool. For instance, .NET offers interfaces, a very powerful capability that can, in some instances, reduce the need for reflection.
>
>Kevin


I think it is worth mentioning that you can not stick with "one tool" (furthermore, used in a very open way, as .NET is more like a "tool set" than a "tool") if using .NET, at least you will need a second "tool" as your database backend, nothing wrong with this, I am just using it as an example that you are using "one tool" broadely to your convinience.

Another question would be, for those switching away from foxpro, if keeping everything in one tool is better, and the switch to .NET is to take advantage of "X feature" of .NET, wouldn't it be wise to see if there is a way of implementing that "X feature" directly from foxpro? Yes, maybe is not as capable as the "X feature", but then, if we going to settle for ADO.NET ... <g>

Anyways, I think I understand what you were trying to say, I just think it did not come thru very well, but that is just my opinion.