views:

504

answers:

4

Is it possible to have a 'persistent' temp table in MS-SQL? What I mean is that I currently have a background task which generates a global temp table, which is used by a variety of other tasks (which is why I made it global). Unfortunately if the table becomes unused, it gets deleted by SQL automatically - this is gracefully handled by my system, since it just queues it up to be rebuilt again, but ideally I would like it just to be built once a day. So, ideally I could just set something like set some timeout parameter, like "If nothing touches this for 1 hour, then delete".

I really don't want it in my existing DB because it will cause loads more headaches related to managing the DB (fragmentation, log growth, etc), since it's effectively rollup data, only useful for a 24 hour period, and takes up more than one gigabyte of HD space.

Worst case my plan is to create another DB on the same drive as tempdb, call it something like PseudoTempDB, and just handle the dropping myself.

Any insights would be greatly appreciated!

+2  A: 

I have to admit to doing a double-take on this question: "persistent" and "temp" don't usually go together! How about a little out-of-the-box thinking? Perhaps your background task could periodically run a trivial query to keep SQL from marking the table as unused. That way, you'd take pretty direct control over creation and tear down.

Mark Brittingham
Yeah, a bit of a dichotomy - I just want a larger window for my 'temp' data. :)You actually don't even need to run a query in the background, as long as you have a connection open that ran a query against it once, it will remain. As a hack, that's what I'm currently doing, but if the connection gets dropped for some reason, then it needs to rebuild everything, so it's not as clean a solution as my plan B.
Mark
Whatever works...good luck and thanks for the upvote.
Mark Brittingham
This would be a quite easy thing do to. If the temp table does not hold too many rows a select count(*) from foo would do it.
George
+3  A: 

I would go with your plan B, "create another DB on the same drive as tempdb, call it something like PseudoTempDB, and just handle the dropping myself."

codeulike
A: 

How about creating a permanent table? Say, MyTable. Once every 24 hours, refresh the data like this:

  1. Create a new table MyTableNew and populate it
  2. Within a transaction, drop MyTable, and use rename_object to rename MyTableNew to MyTable

This way, you're recreating the table every day.

If you're worried about log files, store the table in a different database and set it to Recovery Model: Simple.

Andomar
That's basically what I outlined above - the only difference is that you propose doing it in the same DB. I certainly could put it in the same DB, but since it's not useful longterm data I don't want it in backups for the DB (and don't want to start complicating things with exclusions).
Mark
+1  A: 

If you create a table as tempdb.dbo.TempTable, it won't get dropped until:

a - SQL Server is restarted

b - You explicitly drop it

If you would like to have it always available, you could create that table in model, so that it will get copied to tempdb during the restart (but it will also be created on any new database you create afterwards, so you would have to delete manually) or use a startup stored procedure to have it created. There would be no way of persisting the data through restarts though.

LeoPasta
Interesting, so if you create it using TempDB as the database instead of prepending the # or ##, then it becomes effectively perminent until reboot (when tempdb gets dumped anyway)? That's exactly what I'm after - I can handle recreating it if it doesn't exist.
Mark
Yep, that's how it works. I was glad to be of help
LeoPasta
@Mark, can you please confirm that whatever LeoPasta was saying is right or not?
peakit