this can be most effictively done by using data centric solutions, not by static code languages like C# (you'll have to use a lot of reflection here)

Walter,

I want to respond to your points from both yesterday and today:

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.

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!)

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