Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SQL Server temdb with large dbfs
Message
From
14/05/1997 10:48:40
 
General information
Forum:
Visual FoxPro
Category:
Client/server
Miscellaneous
Thread ID:
00032074
Message ID:
00032169
Views:
33
Scot,
Yep, Gigabytes.

And soon to be larger.
That's why I migrated it to SQL Server :-)

I understand that the tempdb is used for all queries and is not dynamic (too bad) - and Yes, I will need the capability of storing my entire largest table in the tempdb (unfortunately) - here's why:
The users will be running queries to their heart's content. I can not control or limit these - at least I haven't figured out a user friendly way to do this ("Joe" wants all history from the past 3 years. Doesn't really know what he's looking for - If I limit the query, I would have to read his mind and although I HAVE been getting better at that...<g>


I just wish tempDB was dynamic - If the user ran a HUGE query, swap the information - slow down the query - at this point they deserve it.





>> I have a 3.5G database containing a table that is 1.5G that will grow quite
>> large. I wish to run some queries off of it in VFP 5 and just return the
>> results.
>
>> When I try to use a remote view that I created, I get an ODBC error that
>> says my temdb is full (I increased it to 7 MG). If I am not filtering in
>> my remote view, I think I would need to have a tempdb of the equivalent
>> size of the largest table in my database. Is this a correct assumption?
>
>Did you mean Gig (as in the 1.5G table) above, or was that a
>mis-type? If you meant Gig, it is quite possible that you are filling
>up TempDB. All queries and temporary tables usually run
>through it. The SQL server default of 2MB is much too small for a
>TempDB in most applications. For example, mine are set to 52MB, but,
>then again, I'm not dealing with any gig sized tables, so.....
>
>It may be storing some query results there untill ODBC can kick 'em
>back to your app (in this case, VFP). Sincwe the server can spit rows
>into TempDB faster than ODBC can send them to your front end.....
>
>Are you trying to query ALL of the records in that large table? If
>so, perhaps you should consider either a) refining your query to
>something smaller or b) making some meta-data tables that hold query
>results or aggregates (I assume you don't want just a printout of
>those millions of records (s)).
>
>HTH,
>Scot.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform