At 12:32 PM 2/22/2012 +0100, Allen wrote: >Its only dead if you have competition telling people its dead. Its still the >fastest language for development and best for data, as long as you don't >need security. >Al
I agree with Al's statement. But I'd like to modify the last part. VFP does not provide data security "out of the box" (such as encrypting the database files on-disk). But you can add security options as you'd need them. And don't forget you can easily mix VFP in with SQL back ends (such as MySQL, PostgreSQL and even <gasp> MS SQL Server). As an interesting data point, in the past I had created a VFP app that was Web-enabled. I used West-Wind WebConnection for that. The client also had other servers providing .ASP, .Net and some other web-based apps. They got hacked and every server EXCEPT my server was affected. It was eye-opening experience. So VFP out-of-the-box security isn't much. But you can definitely add it. And sometimes being "non-standard" will give your system an added layer of insulation. Just a thought. Now, as to specifically what to do to jump into VFP? Do a search on the VFP Hacker's guide (sorry I don't have the link handy). Also, you can subscribe to this list (as you have I think). But be careful. In VFP there are often many ways to accomplish the same goal. So sometimes you'll need to do a little extra testing and fiddling to find the best approach for your app. For example, "Views" were a big thing for a lot of people in VFP (later turned into CursorAdapters). It let you define a SQL statement and you could access it's data as if it were a standard VFP table. But there were problems with them in some cases (buffering issues, "locking" issues, etc). I decided to avoid views and write my own data class where I had more control. So, in my case I've never hit a lot of the problems others talk about - no locking problem, no data corruptions, etc. But it took longer to write up the data app and when I create a new table in the system it takes more effort than just generating a SQL statement view. One thing I'd strongly advise is to brush up on your Object Oriented concepts. Not a specific language if you can help it. But the general concepts of OO programming. You'll find most things in VFP can take advantage of that thinking. E.g. one of the first things you do is create a class library and subclass all the VFP base classes. Then you branch off from there for your other specific classes. If you've not done OO programming before it'll be a little to learn. But it'll give big payoffs in the end. And one last tip of OO programming - don't go too deep. That is don't create like 7 levels of subclasses - you'll quickly forget what's going on up the class hierarchy. There are a ton of other recommendations that can't be covered in an email. The Hacker's Guide should be a good start IMO. But even then, don't forget that there are many ways to do things in VFP. And, unfortunately, there aren't a lot of books out there. But this list can provide a lot of ...um... opinions as well. Don't get put off if some of the responses seem "testy" or "irritated". Microsoft has decided to not continue to develop VFP and that is incredibly frustrating. In my experience it really is the best environment to develop business applications - or applications that work with data analysis/reporting. I can understand why MS is dropping it - the more apps that got deployed by VFP the fewer SQL Server licenses they could sell. Probably 80% or more of business systems are easily handled by the VFP language and the VFP RDBMS. And since a VFP database carries no licensing fees, that's bad news to MS. So they took the direction of trying to pull all developers to .Net and making .Net integration to SQL Server so high that most, uh, "lazy" developers would just go along for the ride. And thus forcing the resulting clients and companies to purchase SQL Server licenses. Again, not really a surprise, MS is in business to make money after all. But it sure is frustrating for those of us that know the power of VFP. This is the most I've written in a long while. I've found myself pulled away from the list on other stuff. So I'll add this parting thought. If you do decide that VFP isn't for you, I'd advise you go the open source route. Python, Perl, whatever (note that the host of this list has created a framework for Python called Dabo - and I think that framework was written using some of the powerful/useful concepts of VFP in mind - so if you go Python, check it out). I've toyed with the idea of going to .Net, but I realize if I do that I put my customers at risk. The risk of forcing more expenditures when MS decides to change things. The risk of being locked into MS OS's and designs. That doesn't sit well with me ethically. Not to mention I don't like MS's "designs" in a lot of cases anyway. Best of luck to you. -Charlie >-----Original Message----- >From: Man-wai Chang > >Sent: Wednesday, February 22, 2012 12:20 PM >To: [email protected] >Subject: Re: beginner's question > >Foxpro is a dead-end. All are left are legacy applications that would >likely be re-written using another tool in the future. >To be honest, jump in to a newer tool. Nonetheless, it's still best >RAD tool for English applications. > > > I have some experience with MySql and Postgres databases on Linux. > > What do you recommend to read if I want to jump in to the FoxPro > > business? Preferrably some online text I have thought of. > >-- >.~. Might, Courage, Vision. SINCERITY! >/ v \ 64-bit Ubuntu 9.10 (Linux kernel 2.6.39.3) >/( _ )\ http://sites.google.com/site/changmw >^ ^ May the Force and farces be with you! > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
