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.