>Why the heck is that? VFP has been doing it effectively for years. Even is VFP is the black sheep at MS did'nt anyone notice that VFP can play nicely with SQL Server.
>
>So again why does it seem to be so complicated to do it with .Net.

Ok, there are a couple of things that play into this. Number 1 usually is that Fox developers tend to look at things with/from other Fox developers. So everyone in the room will approach the problem with the same fox centric approach many times. Often times while that approach may work, it's not how the rest of the world does data access. Look at Java. Look at VB6. Look at anything else - heck even Paradox and Access use objects to access data.

This doesn't make VFP wrong, but it's a very different choice than other tools. If you approach any other tool with the Fox/xBase mindset you will not find a matching metaphor anywhere.

Or put another way - if xBase was really so unique and so much more productive it wouldn't have died. xBase was very popular in the early 90's still when Microsoft bought it. You can't blame Microsoft for this either because Borland killed Dbase way before Microsoft started neglecting VFP marketing.

Look I'm playing devil's advocate here - I have been involved large VFP applications some with huge amounts of data, others with huge transaction volumes and VFP works fine. I also have a couple of commercial products in VFP that work very well, one of which I've just upgraded. It works and gets the job done.

But the bottom line is if I had to start today building those apps from scratch - I don't think I would use VFP. It wouldn't take me any longer to build in .NET and there's nothing that the VFP app does that I can't do in .NET. THere are a few things that I could do in .NET that would be very difficult to impossible to do in VFP on the other hand (most of them having to do with background processing and multi-threading and user interface control support that VFP lacks).

>To me it looks like MS did'nt realize that developers were building data-centric apps all those years <g>

They know plenty well.

>That's what I mean by having to work with the tools provided. I don't expect MS to have a hot-line so I can specify the spec of the apps my customers ask for and then MS will give 'em to me. <g>
>
>Did'nt you at least expect a step forward and not backward in that department?

Depends on who you talk to <g>... For VB developers it's a huge step forward.

All I can say is that .NET developers (who don't come from a Fox background) have a totally different mindset about data. They are much more focused on using server based data manipulation.

Take a look at the exchange I had with John Ryan here a few days back, where we discuss this very issue. I will not argue with you that some things are easier in VFP, but not everything. I'll say it again - if you use business objects in your data logic most of the data stuff is hidden away for you. Yes at some point you still have to write SQL code, but often that SQL code is the same whether it comes from VFP or .NET. The difference is that VFP developers tend to think of data as a client side entity whereas SQL Server developers think of usig the server to perform all the processig (with stored procedures if necessary) to return only the necessary data to the front end.

You will get no argument from me that .NET data connectivity needs some improvements especially in Windows forms. But just like I never used remote views or Data Environments in VFP I also don't use a lot of the stuff that .NET provides natively relying on lower level mechanisms that are built into my business framework. So I have binding controls that do work like VFP controls (with control sources). At the end of the day between the Fox and .NET applications doesn't look drastically different.

I will share with you some of the meetings that we've (Kevin, Markus, Cathi and myself) had with various data teams in the past - they don't even get some of the concepts we are talking about in VFP. Because VFP does things so different than other tools it's a completely foreign concept to them - the same is likely true of the people who will use the product.

I come from the same fox background as you so this is hard for me to understand, but ask a VB programmer about a control source or even try to explain that concept and you'll get blank stares.

>I know that there are high hopes for VS .Net 2005 in the data-centric department. Let's hope they do it right this time.

There are improvements but not in the way you expect if you think it's going to be like FoxPro. The main improvements are in how the UI hooks up the data. The overall ADO layer doesn't change drastically except for certain high performance scenarios.