Joel

You are a breadth of fresh air if for no reason other than you face the same situation that I do. I have a software product that is in it's 24th year and is very much vertical. We have updated this product every year and added new features and reports. There are literally over a hundred reports in our application when you consider all the permutations.

Our users are no different than yours... they don't care what it's written in, they only care if it works, how fast it does what it's supposed to do, and how easy it is to use.

With only 3-4 programmers, we can't take months, years, whatever to learn a technology like .NET just so we can say that we are using the latest and greatest. Not without first knowing that it will allow us to do some things that we can't do right now in VFP. I haven't heard anyone say that yet.

Sitting on your laurels may be the best advice as of right now.

>John,
>
>Therein lies the problem. There is no other VFP, nor is there currently an easy migration path to something else. You can imagine why that might be upsetting. What you can do is exactly what you are doing: start examining the various technologies out there and determine the best path based on your needs.
>
>Personally, I'm taking a wait-and-see approach. VFP is still a viable platform for us and will continue to be for some time. As a vertical market provider, our clients are clamoring for new features, not a new platform. We have a 25 year investment in our code base, and we can't afford to take two or more years off to rewrite it in something else. There's going to have to be some kind of migration path. I'm interested to see how close Etecnologia can get to their goal of 100% compatibility with Fox. We also have the option of putting a shiny new WPF/Silverlight/Whatever (if not GDIPlusX) front end on our Fox app, so it looks the part. Fortunately, we have time to see how things go, so no rush.
>
>>Joel
>>
>>Thanks for the reply. What I'm hearing is that the one thing that we've come to not even have to think about - data manipulation - now requires a lot more attention than it does in vfp. We don't use dbc or views because our apps don't require it. We don't use data environments because we find that we can manage it easier by coding it instead of letting vfp manage it. Almost everything we've considered requires significant changes in just the data manipulation area.
>>
>>Is there not something that provides the flexibility of vfp by letting you do it YOUR way?
>>
>>
>>>Hi John,
>>>
>>>It sounds like VFP is the perfect candidate for your app {g}. If you're really looking to make a move, as big as it is, .NET is probably going to be the most familiar environment to you. Once you get into Java and/or Linux, it really is a different world, and it can take a while to get your bearings. Also, more resources are available from Microsoft and the community for transitioning to and integrating with .NET. The Strataframe and Mere Mortals frameworks may deliver a more Fox-like way of doing things. Etecnologia is hard at work on the VFP compiler for .NET, so if you can hold out, you may just get the best of both worlds.
>>>
>>>If you really want multi-platform, take a look at Python and the Dabo framework. Of course, there's also Java, which is big like .NET, but there are so many tools available for it, you might find something you like.
>>>
>>>Regarding the database, SQL Server has "XCopy Deployment" (http://msdn.microsoft.com/en-us/library/ms165716.aspx), but I don't know how easy it is to use. VistaDB may be more up your alley (http://www.vistadb.net/).
>>>
>>>>We are in the process of looking at alternatives for our Visual Foxpro development platform. I've read a number of posts where developers are considering .NET, but I've also read a number of posts that say that .NET takes too long to develop business applications and we should use something else. Our needs are quite different than many developers. We develop for a very niche clientele. Here is a little background and then perhaps someone could chime in and express their opinion about .NET or something else.
>>>>
>>>>The bulk of our revenues comes from commercial applications that we distribute nationally. Our primary application is constantly being updated and we issue annual updates with sometimes some very substantial modifications. Consequently, the development platform needs to be flexible and easy to use. Our data files change almost every year and sometimes even more often than that.
>>>>
>>>>We do not use dbc's because our application is "multi-client". In other words, a user will use it to maintain multiple client files and our data files need to be easily transported from computer to computer.
>>>>
>>>>While there might be many people using our application at any given time, they would seldom be accessing the same data file at any given time. Generally, the data files will contain any where from a hundred to a couple of thousand records. The data is maintained in 8-10 data files (dbfs).
>>>>
>>>>One of the most important requirements is the need for a very flexible report writer and the ability to use SQL Select statements to summarize data for printing.
>>>>
>>>>While I am sure that .NET would meet our needs, I temper this with the time it would take to become productive with such an overwhelming complex system. At the same time, I've looked at Access 2007 and it looks relatively easy and similar to VFP but I'm worried about speed. I'm sure you've heard that Access will slow down when more than 10-15 concurrent users accessing the same data file.
>>>>
>>>>If you've got an opinion, I'd love to hear it. BTW, I know that we've got a long time before VFP becomes totally defunct, but we're trying to allow enough time to master a new development environment as well as convert our existing applications. We are estimating that our primary application might take as long as two years to convert completely to a new language, so you can see why we are actively looking for something to start learning. Incidentally, we are not formally trained programmers. Like so many VFP developers, everything we've learned, we've learned on our own.