>I am saying it might be... As I have no idea what load must be handled, I was taking the long way around via the planned usage of HW. VFP and the OLEDB provider will work best if the thread actually querying is running on the same box - otherwise you always have LAN latency bogging you down. As SQL Express is only limited in
>4 gig size of database (should be easy for you to guesdtimate the problem factor)
>1 gig of RAM used (as SQL server is not using the OS system cache, this hurt factor depends on number of users and complexity of queries)
>1 cpu used (IF here the same licensing schema is used as in windows, buy a quad core Intel in november...)
>
>you should be able to decide on more than "feel", because you can test and/or estimate. There are only a few query complexity/data size/user number/HW architecture combinatons I can think of where the OLEDB provider is clearly the better technological choice from a free cost and scalability perspective.
>
>YOur situation (complex read queries) might be one of them - for instance if many OLEDB queries are running on dbf-file-data cached in many gigabytes of RAM running on multiple CPU's. Asking about your HW is a roundabout way to get an estimate for my mental picture...

We have a 3.2 GHZ dual core double CPU with 2 GIG of RAM. This is a brand new server. It has been installed on Friday. This machine is extremely fast.

We will have about 200000 hits a day for the first 3 to 4 months and up to one million when we will reach the first year. We expect to add a new server in a three month interval for a certain period. I wasn't planning to move to SQL Server yet. But, I may be forced to move asap because of the situation we are facing now.