Hiya Josh --

Always nice to see your too infrequent posts. :-)

Security: True, but I skipped over them....I guess I'm used to using pass-through security.
Transactions: That was what I was alluding to in my post without getting into fine detail.

But good points all, Josh.

>All good points, John. I would add a couple of items. You have a lot more options regarding security in SQL Server. With VFP you really need 3rd party encryption tools to keep users from viewing some data but not all the data. VFP will often outperform SQL Server on a LAN, but SQL Server is almost always faster on a WAN. SQL Server 7.0 has some very nice replication tools which can be very useful.
>
>SQL Server also has true transaction processing. Even though VFP has transactions there's no guarantee that a transaction won't be only partially committed if the workstation crashes while the changes are being written.
>
>Of course, you have to balance all this against the added costs to buy and administer SQL Server. 7.0 is a lot easier, but it's still much more work than administering a VFP database.
>
>>Hi Denis ---
>>
>>There are a variety of reasons one may with to consider this. Security is an issue, but one mitigated a bit through server security. Access to the data from diverse sources, ie, n-tier is another reason. VFP keeps up real well with SQL Server regardless of the number of users IMHO, *but* SQL Server, being a server database, handles large numbers of simultaneous transactions better. Plus, SQL Server has more configutation options as a database to fine-tune operations. Finally, SQL Server databases are much, much more physically secure than DBF files. They rarely corrupt.
>>
>>>
>>>Could you tell me when it is the right time to consider upgrading an application from VFP to SQL/SERVER?
>>>
>>>Is it only based on security, the number of users, the performance ???