>If you aren;t having problems with data corruption, then you probably don;t need SQL Server.
>
> But if you had 300 clients accessing that many records, or those 30 users were accessing 200,000,000 records, then you might want it. In the first case, for performance reasons, in the second case, for data integrity reasons.
>

Given that data integrity, security and features like replication are not an issue, your analogy is generally correct. It's really a matter of what becomes the scarce resource in the database system as traffic increases, and the nature of the datasets required at the workstation.

SQL Server, used properly, and relying on server-based query resolution via passed T-SQL code in SQLExec() or better, through execution of SQL Server Stored Procedures, imposed minimal loading of network bandwidth, but imposes greater processor loading on the server than a simple file server; SQL Server consumes both processor and memory resources on the server not imposed by file server services. IOW, the SQL Server box's CPU(s) and memory will be utilized heavily, while the CPU and memory used by VFP on the workstation side will be responsible for less work. SQL Server will pass only the datafrom the results of its own processing - there's no (or less) need to transmit the index files or an entire data file to return the few records found as a result of completing the query on the server.

This offers potential performance advantages where the result sets are significantly smaller than the entire table or the indexes and some significant fraction of a file. If, OTOH, the result sets need to be a significant amount of the file (like if you wanted to BROWSE the whole file) especially if you need to then build indexes on a number of fields on the large result set returned to use SEEK() on the client side, the benefit of reduced bandwidth use drops dramatically - you end up moving substantially the same amount of data IAC, and in fact may end up moving less if VFP has enough memory available to it to cache the data set and indexes client-side. A file server could function adequately with less CPU power and less RAM than SQL Server could, because it's doing less work on behalf of the client.

IOW, the data behavior of the app will frequently determine which database implementation is better. If features such as integrity, security and replication are of prime importance, then a backend product is clearly essential. After that, the determination of what will be the scarce resource, and which database product will minimize its consumption based on the anticipated app behavior will indicate the best tool for the job.

> Nothing is cut and dried - if those 300 people each only open 1 record per day, no need for SQL Server, really. But 300 people pounding away all day with new data, reports, and queries - performance is a wierd thing. I compare native tables and SQL Server like Ethernet and Token Ring. With low numbers of users, the native tables perform far better. Likewise Ethernet. Load up with user counts in the hundreds with constant traffic, and SQ Server will most likely perform better. Like token ring. TR networks start out slow but don't get much slower when the traffic balloons. Ethernet starts out blazingly fast but quickly succumbs to excessive traffic. At some user count/load, the faster one suddenly isn't faster anymore.
>
> Randy
>
>
>>I'm demonstrating my ignorance here. But what the heck.
>>
>>Just a simple question.
>>
>>What requirements would justify a need for an sql server?
>>
>>Who needs it? / Who doesn't?
>>
>>I have a network of just 30 clients accessing vfp tables of 200,000 records max.