>Please be so kind and share a little bit of your experience: Is VFP's data engine better than others? If not, can you recomend one (I mean Microsoft Jet, or, maybe, Interbase, or anything else) ?
From the standpoint of a local data manipulation engine, it's tough to beat VFP working with native DBF tables; it certainly beats the pants off Access/Jet and the other similar file-service oriented data manipulation schemes when used correctly. The key is
when used correctly - a poorly implemented native DBF based database written in VFP, where bad decisions have been made about creating indexes and the like, may be outperformed by a well-designed Access application. Given two systems built by equivalently-competent developers, I'd bet on the VFP app, though.
The situation changes where you don't want to rely on file-service level table manipulation; any time bandwidth is scarce and server processing capacity is high, use of a backend database product pays off well, with applications that are designed to make use of the backend processing the data for them. A backend database isn't going to be of great assistance if your application consists of a browse of a single table of 1,000,0000 records, because the data has to be moved from the server to the local station in its entirety to be able to browse the whole table at once. If, OTOH, you can pose queries to the backend selecting a small set of records from the total set to be moved to the front-end application, the backend will pay off handsomely, because only a small number of records have to move over the network connection; queries and relatively small recordsets move back and forth rather than entire files.
I've played with a number of backend products; I find SQL Server to fit my needs well. There are good arguments at time for other products; the ability to deploy the server on a non-Windows platform server is one example; given an HP Unix box or IBM mainframe as the server platform, SQL Server 7 simply isn't an option; DB2 or Oracle, which can run on these server platforms are clearly better choices. Specific features of backend products vary as well, and there are places where better choices than SQL Server exist.
From my POV, being Win32-centric, SQL Server is a tool of first choice; it has the obvious advantage of permitting prototyping using the MSDE, with direct portability of what I develop under the MSDE engine into the SQL Server platform. YMMV; like I said, there may be other factors that argue against the use of SQL Server 7 for a given environment.
