I've worked on both scenario - voluminous VFP data and SQL Server data, and IMO, the only advantage of VFP over SQL Server 2000 overall is the price. The latter is plain overkill for small to medium scale businesses. MSDE is not also advisable because it has limits - 5 users and 2GB for database. VFP data gave us too much of headaches when it comes to maintaining them.

>Hi Beth,
>
>Not sure if I followed everything you are saying - but I would guess the 20 hour job has timed out.
>
>With respect to the bigger issue - on whether VFP does "data better" - please note the following.
>
>A well-tuned sql server install - using stored procs, will always out-perform VFP-DBF's - PERIOD. And, it goes without saying that SQL Server can scale far beyond DBF's. And of course, SQL Server is far more secure. And..it is far more robust to the extent it has native tx logging. From a disaster recovery standpoint, DBF's cannot be credibly be mentioned in the same breath as sql server, oracle, etc.
>
>Arguments are often put forth that T-sql is not as flexible as VFP. In one respect, this is "sort of true". From a flexibility - and perhaps it is better stated as efficiency - T-sql does not have as many built-in functions as Fox. But at a core level, T-SQL has everything you need. And yes, in T-SQL, you can create temp tables and scroll through and manipulate data in a row be row fashion (can you say scan...endscan???).
>
>The typical naysayers around here have either never used SQL Server to a serious degree OR, they mis-used the tool. This much is true based on their comments. In the remote view scenario - which is a pretty bad way to integrate with SQL Server, people will say that SQL Server is not has good as Fox becuase it takes a while to fetch 100K rows of data. The fact of the matter is this - bringing 100K rows to the client is pretty freaking inefficient. This is one of the big problems with client-side reporting.
>This is not to say that client-side reports is per-se bad. Of course small/intermediate jobs can be rendered to the server. That said, it does not follow that a "one-size fits all option" should be employed for all reports.

>Sending requests to a reporting server, to have reports generated on a server is the best - most scaleable way to do this work. Again, the naysayers here continually operate from a Fox-Only premise. i.e, they cannot think outside the Fox-Box - and as a result - when a solution does not comport with that world-view - in their mind - it is presumptively a bad way to do things. Ask yourself this question = 'How is that the other 99.9999% of the world that does not use Fox - manage to get these sort of tasks done???"