I'm trying to create a form in asp.net with several fields and a couple of tables that users can add rows to or edit/delete existing rows. There will be one insert button for the whole form that will attempt to insert all the data into the database. Asp.net has a gridview control which is useful for displaying and manipulating data from a database. I've been working on creating my own class for storing data in a temp table in memory (not in the database) and customizing the commands on the gridview to manipulate the temp data but it's been a nightmare.
Now I'm wondering about using temp tables in the database to store the temporary data before the user clicks insert and all the data is permanently stored in the correct place. This would be much more convenient for what I'm doing in asp.net. Is this possible? If so, what is the best method? Is it bad practice?
I had a similar problem with a number of tables accessed via ASP.NET.
My problem seems similar to yours in that I needed a temporary storage area where a number of pages could update tables in a transaction.
I created a separate "PropertyBag" database that contains duplicate tables with one additional column per table.
For a greatly simlified example let's say we have an Employee table in the main DB consisting of EmpID, FName, and LName. In the PropertyBag there would be an Employee table with PBID, EmpID, FName, and LName. The ASP page writes to the PropertyBag and when done, the final page executes a stored proc that copies from the PB to the main database tables and cleans up. All of the ASP pages comprising multiple input screens kept track of the PBID for that entry.
My app was actually quite complex and there were reasons for creating a separate database instance for the PB but you get the idea.
Hope this helps.
P.S. As I said, this is a greatly simplified example, the real app had fields such as UpdateDate and logic to clean up the PB should the user cancel in the middle so as to not leave old unused records in the PB tables.