Jim,

>But I do think that you are most biased when you claim it to be "the best". It certainly has that potential, but it also has a very long way to go yet to get there.<

OK, fair enough. Maybe I shouldn't have quite used those terms, you're right about .NET still being in it's infancy. But, some of us like to be early-adopters. It's not for everyone, I'll agree.

I do need to comment on one thing you said:

>a few things have come up in that forum that convinces me that .NET is not yet "ready for prime time". The most significant was the requirement to refer to table field by number.<

You must've missed my posts on typed DataSets. Using this methodology, one can refer to both the tables and the table columns by names, not numbers ... and they show up in Intellisense as well. I wouldn't use anything *but* typed DataSets (and there's really no extra work involved in implementing them).

~~Bonnie


>Bonnie, I'd like to comment on a small part of your reply (below)...
>SNIP>
>>I have no argument there ... VFP is a great development tool, and inexpensive (when compared to things like SQL Server). But it can't be all-things-to-all-people, but I think there's a good niche for VFP apps. ASP.NET and ADO.NET are *vast* improvements over classic ASP and ADO. And they can be utilized from within a VFP app. Why would anyone want to design a web application with these old classic technologies anymore? I'm *not* talking about converting old apps (although that's not a bad idea in the long run). But, if you, as a developer, are designing and writing a new application, wouldn't you want to go with the best? Don't you think that a VFP desktop app, with maybe VFP middle-tier components,coupled with an ASP.NET web interface is probably better than the kludge we have to do know to web-enable a VFP app?
>
>As VFP is currently constituted, VFP comes pretty darn close to being "all things to all people". The old "right tool for the job" cliche is nothing more than a sales slogan by MS to make people think that they need several different tools to get a job done.
>The fact is that any 'development language' is, by its very definition, applicable across a number of business problems. Sure there are instances where VFP cannot be applied successfully, but these should be in the MINORITY.
>On the .NET side, I have been reading the .NET forum here for a while now. While ASP.NET and ADO.NET may be miles ahead of their predecessors, a few things have come up in that forum that convinces me that .NET is not yet "ready for prime time". The most significant was the requirement to refer to table field by number. That's back to the dark ages, whether old ADO did it that way or not!!! I simply wouldn't "take advantage" of any facility that forces me back to the old days. Maybe one can "make a wrapper" to solve this problem, but then the "advantage" seems to disappear with the added work. Another had to do with "sealed" classes impeding progress. There were a couple more that I could look for if needed.
>
>I, as a developer, always want to "go with the best" but I only want to do so once I have significant depth of (real) knowledge about the languages and the development environment(s). I see no hope of achieving anything close to that while the product itself is still embryonic, still under very significant development.
>
>It's great that a number of folk have "embraced" .NET because they will clear the way for all of us who follow. But I do think that you are most biased when you claim it to be "the best". It certainly has that potential, but it also has a very long way to go yet to get there.
>
>cheers
>
>SNIP