在 SQL 服务器登录时创建临时表

Question

Is it possible to have SQL Server create a temp table inside a particular database upon a user connecting to the database in such a way that the connecting user is the only one with access to the contents in this table (or even better, the connecting user is the only one that can even see the table)?

I tried using a logon trigger (including using a 'with execute as caller' clause) but although this creates the temp table, the connecting user can never see it/select from it. All of this has to run inside SQL Server and require no user interaction at all...

Basically, this is the scenario I want to support:

• user connects
  • a temp table is created inside a particular DB inside SQL (by SQL, kicked off by establishing of the connection)
• some specific information is populated inside the table
• for the duration of the connection; the user has (Read) access to the contents in this table; the information in this table is used by a sub-system inside a particular database
• user disconnects
  • the temp table and all its contents is dropped by SQL

Thanks

Answer 1

First thoughts:

• modify your client code to create the table on connection? Then it can be done only when needed not all the time
• use a common, persisted table with a SessionID based on a GUID? This will provide some audit + troubleshooting information too
• use table value parameters to send data on demand rather than have any server-side caching

And what I'd probably do:

• create the table when it's populated when I need it. The user can connect to the database for a variety of reasons (I assume). So "connection" should be decoupled from "CREATE TABLE".

Answer 2

Using temp tables for this would not be the right approach if your data access is properly designed to open a connection-do an operation/query-close the connection. The moment you closed the connection, the temp table would be destroyed. It would be better to use a view or stored procedure to filter the information to which the user should have access. The structure of that view will depend greatly on how users connect to the database. Do users connect to the database using their own personal windows authentication account or do they connect indirectly through another account like many web servers do?

IMO, the better approach is the second bullet point of gbn's answer: a common persisted table with an indicator as to the session or user.