>If the number of users is low, then why not use native DBFs for local storage?

As we speak... I am contemplating how to raise & feed an army (of support engineers) to keep the natives (DBFs) alive (from corruption). All kinds of ammunition (utilities) has been deployed, in the hope of overcoming the enemy. but we still can't seem to overcome the fear.
just joking :) (We have frequent power cuts some times, and these are my thoughts from such an episode)

The number of users is low for each deployment. Small database just seems to be easier to deploy.. although such a thought might be misplaced, that is why I am wanting to discuss it, and seek the guidance of our collegues.

We have already converted an application to SQL Server 2005 using SPT/ODBC, with excellent results. My question remains, kindly give your suggestions.

Thanks.


>>I wanted to use "SQL Server CE 3.5" and "Microsoft Sync Services" to provide a distributed solution, where each client would have their own local database (No. of such users is not very high).
>>Brochure says "SQL Server CE 3.5" Supports ADO.NET, LINQ to SQL, LINQ to Entities and the ADO.NET Entity Framework. Does that mean VFP/ADO cannot use it?
>>
>>Problem: SQL CE allows only OleDB Connection, which I guess means Cursor Adaptor with ADO has to be used, Which is very slow compared to SPT/ODBC combination. I tested by downloading a huge table with following results:-
>>

>>SPT/ODBC: 38.5 Seconds
>>CursorAdaptor/ADO/OleDB: 120.0 Seconds
>>

>>Even Downloading a few fields only using CA by specifing SelectCmd with UseCursorSchema=.F. resulted in poor comparative performance.
>>
>>Any suggestions ? IF SQL CE solution is not possible with VFP then can such a distributed solution be built using Firebird ?