Question : Temporary Table in SQL Server 2008

I have an Access 2003 front-end and linked to an SQL Server 2008 back-end.  This is a multi-user project managment program for 4 to 5 users.  Each user will be accessing records for a particular work item for a particular project.  

The userform for each user in the Access front-end contains a Microsoft Office Spreadsheet Component.  I need to populate this spreadsheet with data for a particular work item from a master table in the SQL Server.  I would like to update back to the SQL Server approximately every 2 or 3 minutes so that the user's work will be saved on a regualr basis.  

Since the user will be uploading records for a particular item, and then updating these same group of records on a regular basis for as long as 1 -2  hours, I was thinking about storing the records in a separate table in the SQL Server, and then loading the records back into the master table when the user is done working on that particular work item.

Is this the correct approach?  Should I do this by making a new table in the SQL Server, then having the user update, delete & add records as required, and then deleting the table at the end of the session?  Or should I be thinking about using a SQL Server Temporary Table.   I don't want to read and write contantly to the SQL Server master table, as it will contain at least a million records, with at approximately 30 fields.

I'm not looking for any code, just the best way to handle this situation.

Thanks,
Greg

Answer : Temporary Table in SQL Server 2008

1. If pulling the rows to a temporary table and putting them back works for your situation, go with it. However, it may cause you more work and the related chance for bugs than with a more direct approach.

2. Regarding Views. Yes they are static. You can't pass them a parameter, so you would create one for each user. You can update the underlying table through simple views, as long as you are not doing aggregation or joining to too many other tables in the view. there cannot be any ambiguity. For something you can pass a parameter to, look into a user defined function which returns a table as a result set. You can use it in the from clause like a table and also pass it a parameter for it to filter on. However, you cannot update through it.

3. This would be my choice. Out of the box, this is the way Oracle works.  Readers don't block writers, writers don't block readers, no one see a new version of the data until the transaction is committed.  In SQL Server 2005, you have to flip a couple of switches to turn it on.

SQL Server 2005 Row Versioning-Based Transaction Isolation:
http://msdn.microsoft.com/en-us/library/ms345124%28SQL.90%29.aspx

Using Row Versioning-based Isolation Levels:
http://msdn.microsoft.com/en-us/library/ms179599.aspx

You have to go with what you understand and can implement successfully. But, it could be a learning experience to research and implement a newer method.

..dbi