First off, 1.5 GB is not all that large. Second, it is not a dbf, it is a table. Third, not all queries touch tempdb. You are now going to have to learn how the SQL Server actually processes your query. I suggest you read up on the show statistics and show plan options in the SQL Server documentation. It tells you how SQL is handling the query which gives clues to how to refine it. I suspect right off the bat that your query has an "order by" clause. Every query that hits SQL with an order by, SQL is forced to feed the data to tempdb for the rows that qualify, then sort them in tempdb, then send the sorted result back to the client. Overall, this is a flawed approach. You want to avoid any contact with tempdb. Since all connections share it and it is small compared to the tables themselves, if you use this approach, it will never be large enough. If you have a 2 GB table, you might think 2 GB tempdb is enough (which is 1000 times larger than the default size, which should indicate that the design is flawed). Well, if 50 users are sending SQL statements that need to use tempdb, then you might need a 50 GB tempdb to handle these flawed queries. Now, it doesn't sound right that you need a 50GB tempdb to handle a 2GB table, does it? And that tempdb is 25,000 times larger than the Microsoft default value of 2MB. The flaw is the queries are in-efficient, not that tempdb is too small. And all that moving of data into and out of it is high disk overhead anyway. Its somewhat similar to rushmore. If you don't understand how it works, then you get poor results and have to have more hardware than you need. Again, avoid touching tempdb. Learn what actions cause it to be used, then work around and avoid those actions. "select .. order by..." is one of them. A better approach would be to issue the select statement (or create the remote view) with a "where" clause (parameterized view) to limit only the rows desired but with no order by clause. Then index the result in VFP. for example: CREATE SQL VIEW MyView REMOTE CONNECTION MyConnection AS SELECT * FROM account ; WHERE City = "San Diego" use MyView index on AccountNumber tag Account So, rather than discuss how big your tempdb is or how large the table is, tell us what the actual query/view is because THAT is what determines how it get processed. Jeff.