I'm not familiar with SharePoint, can you explain?

We really need to have each client's data files in separate files. This is a given for most accounting apps that are "client" based. For example, Quickbooks is an integrated accounting app that is client based so each client's data is stored in ONE file. Not sure what they are using for a data repository, but each QB file is self-contained.

Our accounting apps are very much the same way, especially our primary revenue driver. Even though there are multiple files used for each client, we have options in our application to handle the file maintenance side of things... copying files, renaming, backing up, etc.

What I did is change the extension on our DBFS to identify what the file is used for. This allows them all to have the same prefix, which is used to tie them all together. Yes, this takes a lot of work on our end, but it works very well.

We don't really need to sync up data, because our app and the end-user keeps track of the data file. They can have more than one copy (one on their local server and one on their laptop), but it's really up to them to determine which one is more current. Of course, we have ways in our app to help them make this determination, but it's never been an issue for them or us.

The important thing is that we really need to provide the same functionality that VFP allows us to provide. If we have to drop features, such as the ability to print to a variety of file formats (using XFRX), our users would not be happy.

>Access is being directed to a database for use with SharePoint. I would not consider it a serious tool. Is there a reason you must have separate datafiles and store them locally? How to you sync up data? How do you back up data? How do you make sure data gets successfully moved from one computer to another and not overwrite what's there or that two people don't use the same data? Is there a reason you can't use a centralized database?
>
>>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.