This works more or less the same in SQLServer so concurrency should not be an issue as far as the temporary table is concerned, from the docs:
> Temporary Tables You can also create temporary tables. Temporary tables are similar to permanent tables, except temporary tables are stored in tempdb and are deleted automatically when no longer in use. The two types of temporary tables, local and global, differ from each other in their names, their visibility, and their availability. Local temporary tables have a single number sign (#) as the first character of their names; they are visible only to the current connection for the user; and they are deleted when the user disconnects from instances of Microsoft(r) SQL Server(tm) 2000. Global temporary tables have two number signs (##) as the first characters of their names; they are visible to any user after they are created; and they are deleted when all users referencing the table disconnect from SQL Server. For example, if you create a table named employees, the table can be used by any person who has the security permissions in the database to use it, until the table is deleted. If you create a local temporary table named #employees, you are the only person who can work with the table, and it is deleted when you disconnect. If you create a global temporary table named ##employees, any user in the database can work with this table. If no other user works with this table after you create it, the table is deleted when you disconnect. If another user works with the table after you create it, SQL Server deletes it when both of you disconnect. < Niels -----Original Message----- From: Koka [mailto:[EMAIL PROTECTED] Sent: maandag 8 augustus 2005 17:09 To: [email protected] Subject: Re: Executing a Stored Procedure returning rows from a Temporary table > multiple clients may call this Stored Procedure and we would have to somehow separate the outputs for the various clients Hmm, never used SQL server, but in oracle TEMPORARY table carries session-specific or transaction-specific data. If situation is different for the SQL server you'll have just to rollback after running select (i.e. procedure: delete rows, fill in required rows; select rows, rollback). So not much to do there, And also, IMHO, extra trip to database will be ever noticable compared to time you need to fill in rows and retrieve them Good luck Koka
