Replies

thanks for that advice, I know it's very good advice. But regarding VFP, we VFP people feel compelled to defend it. VFP is absolutely excellent for building interfaces with users for relational database work. It's fantastic at doing complex algorithms, it's got lots of commands for processing data. It also processes data very quickly. With my class library that takes full advantage of code encapsulation OOP style I feel very confident that I can outperform 95% of the VB programmers if the goal is to merely build a system that will function on a desktop or on a small network. So, I wouldn't describe VFP as low-end myself. But as someone else pointed out to me, it simply doesn't do well with very large amounts of data at back-end or across internet.

But that's very good advice you gave me. It would be easy for me to switch to VB. But C# seems to have a good future.

I've already decided though what I'll do. I'll continue trying to market software I wrote that is primarilly for small businesses that don't have huge data at back-end and don't care about VFP's problems. If that doesn't work out, then in a few months I'll go back to construction management which is what I did prior to 10 years ago.

The VS .NET stuff is so productive, just buy it and two or three of the MSPress books, and you'll be up and running in a month. It is now supereasy to do remote objects. The IDE creates proxy objects for you from the WSDL interface description, and all the .NET languages garbage collect, so you just instantiate interface objects and call the methods. And all the multithreading and thread-cacheing stuff is also transparent now. So what used to be a giant pain is five pages of code.

I've never done database-centric systems, but AFAIK VFP is still client/server, and .NET is inherently 3-tier and Web UI. If database apps are your thang, you gotta do it.