Kevin,

>So why does the VFP team now work closely together with the .NET team try to incorporate VFP data features into .NET ? (Words from Ken Levy)

>You don't think the VFP team had some discussion with other groups about implementing new (and long overdue) SQL features in VFP9 to get closer to SQL-92?

Maybe, if so they propably talked to the SQL Server team. However, the SQL-92 standard is well published and since the internals a very different, you have to wonder up to what extend. Neither you or me can say for sure.

>Do you believe it's possible they also worked with others when implementing collections and the ability to easily consume web services in VFP8?

Sure. As YAG said in his blogg both products can learn a lot about eachother. You ever wondered what? It is a given fact that the VFP team is working with the VFP team because its VFP data centric functions. You read the links again carefully and you'll see what I mean. The VS.NET team has already admitted that 'if its about doing data, talk to the VFP team'.

By saying that there is no significant advantage in doing VFP over .NET when it comes to data, you're playing the ignorant guy, because that is not what reality is. VFP is far more flexible when it comes to processing data: You're not depended on a backend for processing data locally and don't have to iterate through collections when doing local data munging.

>I have two .NET apps in production that were previously VFP apps. One is an accounting-based solution with several hundred users and over two-dozen reports, the other a job-costing/invoicing system for a construction company. Neither are 'basic'.

Sorry but, I'm not impressed. Accounting systems mostly are fairly straightforward and can use data as it comes from the backend. When you're doing difficult high volume calculation and transformations with downloaded data you'll be screaming for more data processing power. I appriciate you're doing fairly straighformward stuff you can do in any language beeing able to connect to a SQL server, but other might require a bit more advanced data processing here.

The fact is, kevin, that you can't do advanced local data processing in .NET without writing large functions and classes which take a lot of time to construct, test and debug, and aren't flexible enough. No SQL support, No REPLACE, No LOCATE, no SEEK on local data. If you debunk the usefullness of those functions, fine, go ahead, but don't try to apply this thoughts to all VFP programmers.

>It's like a religion to you...if it's .NET and it works, then it could only be because the requirements are basic.

It is not a religion. As I spoke to many people who do both VFP and .NET this is a demonstratable fact. Again the prove is there. No local data processing with the power and easy of VFP. Again you can't dispute that. If you doubt my words, well talk to MVPs like Rick Strahl and ask him for the things he misses in .NET? He already complained about the fact that for every little local data storage you'll have to use a backend or write a propetairy solution, while it was so simple in VFP, to just create a cursor and put it in there, and afterwards doing a simple SQL to join it in you other local data.

>Conversely, it's become a shibboleth that only VFP 'does data best'. THAT is erroneous thinking. Another case where faith is a dangerous thing.

Ohhh there are other languages arround that do data prett well. Only .NET is not one that comes close.

>If you're perfectly content with VFP and have no interest in learning another tool right now, fine, that's completely your choice. But you sitting back and making judgements about a tool you haven't heavily used, or applications you know nothing about, is highly suspicious as to motive. As to the latter, I find it insulting.

I find it insulting to support a guy here on the UT that acts like a complete jerk and 2. that you ignore the facts about the characteristics of a tool and by the lack of knowledge to draw any conclusions, blame the other guy for insulting.

I've spoken to numerous people doing .NET. I know pretty much all about how ADO.NET works and I do advanced data processing in VFP with constructs and functions that have no counterpart in ADO.NET and the only way that is left is iterating through collection in ADO.NET. You can't blame me not looking at .NET. I've gathered enough information to draw my conclusion.

>I won't deny that .NET has a pretty steep learning curve. I won't deny there are aspects of it that have frustrated me. But the same thing can be said for VFP. Through the learning curve, I've come to realize the true and full role of the back-end database.

You are making a fundemental mistake here. A mistake that is made by so many developers not able to judge the value of local data processing.

A database server it solely purpose is beeing a database server, not an application server ( a rsik that only gets bigger now yukon supports manages code). So for every data munging routine found in VFP, you're going to poison the SQL server with long winded inflexible SPs to get what you want at a much worse performance a VFP application would do with the data local. You're dragging the performance of the SQL server down very fast when the number of users grow.

Second, let say that the database in question is used for more than one application (enterprise), then you'll find stored procs for each and every application in one database, making a mess of the whole database and creates a mess in administrating security.

Third, I've seen cases where the database structure was adjusted to beein able to query the data into the right structure rather than it was structured in a normalized form, with a huge maintenance (triggers) cost, logical corruption risc, and tables that are an order of magnitude larger than the sum of the size of tables if the information is normalized.

As a result many companies do forbid you to even make SPs on the SQL server. O.K. Where are you now? Again as I pointed out in an earlier post this is exactly why local dataprocessing in middle tiers or at the front end (tradition C/S) is so important. No matter how you put it, .NET is not up to the task (yet!)

>The fact remains I have .NET apps in production that users feel run as fast as the previous VFP system, and unless you're holding back some information, you don't.

Fine for you, however to project this on more complex VFP applications is beyond me. I simply can't do that as most of my application do gather information form a dozen of tables and process a result out of it. And the processing goes far beyond in what is possible within a few SQL statements. Have you ever tried to produce a yearly overview of complex (x-weekly) iterating rosters schemes with partimers, sickness, hollidays, leave hours, pregancy leaves, maturnaty leave, overwork, complex governmental and company rules, special leaves, rounding issues, using or resthours of certain categories in this year or passing them to next year in of 1200 employees with intermediate roster changes or inclomplete years, in lets say 5 or 6 seconds ?

Well try to this in an environment where you don't have a local database engine. Go ahead.
As I said I've spoken to people who tried to convert their VFP application to .NET, and they failed in their attempt, because it simply was too much work, as some VFP valuable commands just don't translate into something simple in .NET.

>Better yet, a suggestion would be to venture away from the safe confines of this forum, make your way to different .NET forums and newsgroups and post your views on ADO.NET and other aspects of the tool that you've commented on. I'd be very curious to watch the reactions.

Why do I want to do that. That would raise the same reaction as going to a VB forum and tell then their OO implementation stinks and VB is dead. In the land of blinds, one-eye is king. Their cannot see or are aware of the power of VFP. I'm aware of ADO.NETs implementation: a serious lack of local data processing.

Walter,