Keith:

I've been devoting a lot of time to .NET/C# and the learning curve is steep, but its pretty steep for new VFP developers learning VFP for the first time too. Difficulty in learning a new language needs to be separated into 2 parts:

1. Its difficult because it is new (as are many things) or
2: Its inheritantly difficult due to poor design and implementation.

I found .NET initially difficult because of #1. After a few months, its as easy to do database apps in C# as it is in VFP.Being able to modify and view data in SQL Server using VS.NET is not really any more work then in VFP. The syntax of ADO.NET is different then VFP, but the functionality is virtually identical.

That MS Roadmap mentioned at the start of this thread is important in that there was no mention of VFP at all. Data access is soley being based on SQL Server as the data store and the current .NET languages as the client. Don't hold your breath for VFP becoming a .NET anything...

Harold





>PLEASE GOD NO!
>
>John,
>
>VFP is a wonderful tool for quickly prototyping an application and getting it into production. As a matter of fact, it is one of the few "RAD" languages left. It certainly is the most robust database language of those few RAD languages.
>
>I don't know if you have tried developing an application with .NET yet, but I can tell you from experience that .NET is extremely complex. Something that might take an experienced VFP developer a couple of weeks to write can take months in .NET. I find myself yearning for the simplicity of VFP when working with disconnected datasets in .NET.
>
>And then there is the cost of a VFP application compared to .NET. For .NET you need a separate database and a web server. Then you need someone to manage that web server $$$!
>
>If you are concerned with security, working with SQL Server databases is nearly transparent in VFP. With a few well written classes, you can crank out code and not think twice about where the data is stored.
>
>There are enough reasons to keep VFP out of .NET to fill a book. I'm sure you will get many more responses in this thread.
>
>>Over the past week or so I've been going over an article on the Microsoft Visual Studio.NET set entitled "Microsoft Developer Tools Roadmap 2002–2004". The article can be found at the followinf URL:
>>
>>http://msdn.microsoft.com/vstudio/productinfo/roadmap.asp
>>
>>First off, let me say that it isn't my intent to start a nasty flame fest, but to pose the question whether updating VFP to a .NET language within the next year to 18 months might be a good idea and to promote a discussion of the pros and cons of doing this. What really grabbed me about this article, was the mention of SQL Server "Yukon". With this release of SQL Server, it will become a host for the .NET CLR and that developers in the four Microsoft .NET languages (C#, J#, VB.NET and C++.NET) will be able to write SQL Server stored procedures as native code rather than T-SQL. The ability to write native VFP code to access SQL Server sounds very appealing to me--in fact it sounds like a natural, particularly in those situations where a true database server is a requirement. How this will exactly work is unclear as Yukon is still a long way from release. The article doesn't mention whether MSDE will also become a CLR host, but it's probably a good assumption that it will.
>>
>>I think there are some other advantages as well:
>>
>>1. It will bring more VFP developers into the client-server arena and, long-term, increase the number of SQL Server DBAs.
>>
>>2. Make it easier to move away from the .DBF format and its dependence on file system or programmer driven security, potentially high network bandwidth usage and potentially high handle counts (this last mentioned issue can become a resource issue in multi-user Terminal Services applications).
>>
>>3. The power and control of VFP make it analagous to C++ as a database access language. Over time it could become the tool of choice for working with SQL Server and in terms of database access it would be the "sharpest of the sharps".
>>
>>4. We might see books from publishers other than Hentzenwerke. :)
>>
>>I hope I've provided some ideas for thought and discussion.
>>
>>Best wishes and great year for all.
>>
>>John