>>Stephen,
>>
>>I'm a hard core data user. And I fully am aware of the full advantages of a data integrated language. The close integration of data is something unmatched in VFP compared to a .NET solution.

>>I you'd look into my application you'll see a lot of SQL done on offloaded SQL server recordsets. IOW, I get the set downloaded first and do further testing, calculation of the offloaded data. Whether this is SQL, REPLACE, DELETE, LOCATE or anything else, VFP does not care. Now .NET will undoubtly get there, but in this respect it currently is seriously inferiour. Up to now, i'll most likely have to do extra server roundtrips.

>I read the above that your doing local updates of the data.
>How are you pulling the data into VFP, via views or SPT?

Does that matter? I do both, depending on the circumstances.

>I really don't see the difference between data usage in an ADO.NET or in VFP. I find the datarow much like you do. I make the change or add as needed. Why do you see it that ADO.NET cares how your making the change, or that it is an issue?

It is about post processing the data. Doing SEEKS(), SQL or all kind of dml on the retrieved data. For some applications, it only takes a small amount of data retrieving from the server to do massive analysis. I've got such package for statistical analysis for eye-deceases developed for the WHO. three very simple tables, but the statistical analysis is very impressive. Certainly with the datamunging to mung it into a form that we can present the statistic in crystal Reports in scientifical tables and graphs. For this purpose, translation of strings and inserts of NULL values (or else the graph and crosstabs would have missing gaps in it) and not to forget heavy SQL post processing on the data. It just makes so much sense to do this on the client rather than on a server that I don't believe this package could have been developped in this budget by doing it any other way.

>Can you define seriously inferior with actual facts? I find it difficult to follow along without actual reference to specific attributes between the two environments.

Inferiour: How about doing a post SQL on your ADO.NET. Again, you might think it is not neccesary, but I've got heaps of examples where it just makes sense from a performance and resource pov view to do it locally. It seems that this really is the central point of dicsussion. For one example see my post in the What if thread posted to kevin. I could give other examples, if you like.

>>Also one of his remarks: "I don't want to compile, I just want to make this work from the command window".

>I have been burned by leftover references in the command window before so stating that this is a benefit is a hit or miss environment. YMMV.

yep, indeed. I value the command window. I value it so much that all my applications do include a command window for troubleshooting purposes.

>Compiling a class to validate that your statement works is always helpful. Just winging ideas on a line by line basis is very elementary based isn't it?

Again, in an application it is for troubleshooting purposes, for development it is very valuable for maintaining meta data and related issues: USE .... BROWSE FOR

>Where do you stand on these twelve questions?
>http://www.joelonsoftware.com/articles/fog0000000043.html

I'll get back to you when I've read that

>>It only strengthens my opinion that the guys who are having a ".NET data handling inferiourity complex" either deliberately denying this, or indeed have no clue or whatsoever about how things can be done much more efficiently with using VFP strengths. Lots of those folks were not using the foxs data handling to its full extend anyways.

>Looks like a data handling complex to me. You must be a legend in your own mind stating that you alone are the most high and superior. I don't come off as saying my way is the best. I am just asking for references to your statements.

Nope, talk to steven black...


>Are you talking about string manipulation?

Nope,

>I know that you have to be talking about the memo field. So good that it needed to be a separate file that is vulnerable to corruption.

Different issue, did not encounter that for a long time

>Now let's talk about sharing data between VFP and any other system without doing all the work in VFP. Splendid compatibility now isn't it?

What is the problem?

Walter,