Hi Alan,

>All I know is that I've had zero problems with data performance using .NET/SQL Server (i.e. ADO.NET) - and I have one application with over 17,000,000 archived transactions that is queried on a regular basis. That's all that really matters to me...
>
>Whatever ADO.NET is or isn't - it meets all the requirements I've thrown at it.

That's fine. If it meets your requirement, who am I to say otherwise. That is not my intention.

However, projecting your (and I don't mean you personally, but some peoples standpoints up here) experience without any thoughts on all VFPs applications is a big pitfall. I know for sure I'm in trouble with at least half of all my applications writing in the current version of .NET. Those packages contain medium to very complex datamunging that would require tons more coding and in all likelyhood less performance because some constructs are done within one VFP statement which requires significant coding in .NET (e.g. one complex SQL statement on local data)

And of course if you don't use a backend database but just a VFP database for your mom and pop application, then there might even be less compelling reasons to go to .NET.

And though in this discussing the emphasis is on performance, I don't think that is even the biggest concern. There are other concerns like resource consumption (Large resultsets) and more coding thus more bugs, testing and maitenance.

OTOH, arguments about the size of the runtime are not that important to me. High speed internet is available about everywhere and when I build my setup files, I won't go below 20 MB either (mainly because of Crystal Reports)

Don't take me wrong. I do think that .NET will be much better in this areas (As e.g. KenL has expresses a number of times VS.NET is working with the VFP team to incorporate new data centric functions) in upcomming versions, but currently IMO, it is too immature to be a better alternative than VFP.

Walter,