Walter, to your knowledge, has anyone yet developed small matching data-driven applications in VFP and VB (or C#) to demonstrate a 'typical' means of accomplishing the same business requirement using both tools? I realize that there are 20 ways to skin a cat, but experienced programmers tend to use a tried and proven method of data handling over time so a common method of approach should be known in all three tools by now I think. Even a simple single data entry form for a backend would be a worthwhile test/demonstration.


>>I don't see the relevance to the question.
>
>>I'll assume from your avoiding the question that you haven't developed anything in it.
>
>>It is absolutely relevant. Here's why:
>
>> I refer to people who have experience with both.
>
>>If you have not developed anything in .NET, if you are not going through the learning curve, that puts you at a tremendous disadvantage to be able to process information regarding the topic. The longer you are locked into the Fox way of doing things, the longer it may take you to learn .NET.
>
>Huh, I don't buy that. I don't see how my experience in VFP will block learning .NET in any way.
>I'm not locked in the way FOX does things, I think that is entirely the wrong impression. I'm locked in the Relational world having different types of dataaccess, both set and record oriented. I'm locked in the way that data handling is an important matter in all layers of an application, not only on the server. So I search for a solution that can offer me that. Currently a .NET is inferiour solution. This might change with LINQ, but we will have to see.
>
>>For instance, a while back we had a discussion about datagrid performance in FoxPro vs .NET. You referred to information from a site on datagrid performance to prove that the .NET datagrid had performance issues. That site explicitly referred to paging, not realizing that paging is a technique for the Webforms datagrid (a totally different animal). That wasn't relevant to the discussion, as I had previously established a comparison between FoxPro grid vs Winforms datagrid.
>
>I admit that I did make a conclusion that was not relvant to the discussion up then.
>
>> You also previously misunderstood other aspects of ADO.NET
>
>Ehhh, I don't recall having a single misinterpretation on ADO.NET Can you back this up?
>
>>and forms inheritance. Now...everybody makes mistakes - but there seems to be a pattern of making conclusions from an untenable position.
>
>In case of the inheritance discussion, it was typical, that though I was partially right (you don't have visual inheritance for base controls), it was not told by one of the early .NET adopters, leaving a hypocritical impression that anything that was degrading .NET was not spoken about, but anything in favour of .NET was broadly advertised. I was all again the same old story. The benefits were highly emphasized, but not a word about disadvantages. This was strongly the point I was making in these threats, though heavily denied or dismissed by the .NET side.
>
>So you could accuse me of beeing wrong (though if you read the message carefully, I did imply I was not sure about and wanted confimation (asking for prove)), but not from a proven unreliable source like JVP.
>
>The above is fine and well, but that is not where I critisized .NET, it is purely the data access aspects, concentrated on ADO.NET. Purely because of the missing functionality that now might be filled with LINQ. I simply need this funtionality for my type of data driven applications. I'm not interessted in finding poor working workarround in writing LOTS of extra code because of the missing functionality of a local SQL or Xbase functionality. Writing your own classes simply does not cut it. It is near impossible for a mortal to write a class that mimics these types of functionality. Not to think about the tremendous time to develop and debug. It simply is a no-go.
>
>>Do you see what I'm getting at, Walter?
>
>Well, the same distractions from the issues and not willing to carefully read into anothers argument (as usual). It is not about little details. It is about a big conceptual missing link in .NET: Hanlding data efficiently. ADO.NET is simply an evolution from ADO, not beeing a database engine. Handling data on the client as just as important on the client as on the Server. I've explained in several threats why it is important to have data handling on the client, but all were dismissed with all too easy arguments.
>
>The enthousiastic early .NET adopters where very keen to tell us the beatifull things, but I and others had literally to pull information out of you in regards to disadvantages:
>- ADO.NET limitations in regards to local data processing
>- Poor performance in starting up applications.
>- Less RAD in certain areas
>- Cumbersome late binding issues with COM. (Try to write your application to automate MS word independed of the MS word version, and you'll see what I mean)
>- Scalability issues because ADO.NET datasets cannot be flushed to disk.
>
>There was a lot of distractions and dismissing and blunty beeing wrong in those discussion, and I won't say that I was a saint in this discussions either, but there strongly was a drive from the .NET adopters to motivate all VFP-ers to .NET 'because' you could re-write all your applications in .NET in roughly the same time as within VFP. And this is something you and JVP have told us several times, directly and indirectly. since there are no absolutes in software development this statment by itself is wrong by definition.
>
>Do you see a pattern ??
>
>>You cannot tell me that the LINQ project does not interest you. It has major advantages if they do this right. LINQ will become the next hot-item in .NET and at the same point it will prove the critisism we had for years. So, please spare me your tactics about arguments of blind 'zombie' experience in .NET. Many programmers are just bricklayers who do not have any clue about architectual designs. It would suit you better to admit that my critisism on data integration in .NET was a founded one, now that MS themselves has proven it.
>
>>Of course, LINQ interests me. Yes, it provides many benefits. And it also proves MS' committment to continually enhance .NET.
>
>>I never said that you could do EVERYTHING in ADO.NET that exists in VFP. All I've said is that in some instances, one can develop functional equivalents...sometimes with a few lines of code, and sometimes with more code that can be abstracted out as a separate class.
>
>Ah, the tone is quite different from what I've heard before, implying that every data driven application can be written in .NET within roughly the same timeframe.
>
>>What I am saying is that a number of solutions have been developed by myself and many many others, and we've moved on to different things. It's my opinion that some aspects of .NET (including ADO.NET) are understated in the Fox community, partly because there's not a simple 1-1 correlation. Raising one hands in the air and stating they're not going to start working with it until it satisfies all their needs is only denying yourself the learning curve you must go through when learning .NET.
>
>Well in stead of making claims you do, you'd better provide examples to back up your statement, because much of what I've seen as a different way of doing things, can just be classified as an inferiour way of solving a certian problem, because a better way simply does not exists. For example using interfaces in VB because there was no inheritance. So if you can provide me some different ways to handle data issue as opposed to the way you'd handle the problem in VFP, you might have a change in convincing me. .......
>
>I'm still a dedicated VFP/SQL developper with some experience in other languages and platforms. But remember, that the things you do have to do now to handle simple problems can be done far more efficiently when LINQ becomes available. With VS.NET 2007 (or 2008?), I'll not have to go through the odd buggy workarrounds you'll still have to do today. Meanwhile I'll have learned a lot more how things conceptually work in .NET, getting the bigger picture. Also lots of people will have posted problems and solutions in regards issues that are done in a certain way in VFP. So, yes, it does matter when you make the jump. My investment in learning will be much smaller than those of the early adopters because people already have solved certain problems for me and the .NET platform is more mature.
>
>Do you see what I'm getting at Kevin ?
>
>Walter,