Long story short is that a user inputs a lot of data in an ASP.NET/C# pop-up window. That data needs to be added to a table, but can't be input into the table until the last process of the interface is reached (because that's what creates the table's primary key, and until we have the primary key, we can't add anything to the table). In short, we need a place to store the load of data the user input in the pop-up window until the end of the interface is reached.
The easiest solution that my newbie mind could think of is to create a temporary table to store this information, and then at the end of the process, when we have our primary key, just copy over the data from the temporary table to the real table, then clear out the temporary table.
Otherwise, we have to worry about storing the data in like an array or DataTable variable, passing that from pop-up to parent window, and then preserving that across postbacks until the end of the interface is reached. Part of the problem is that the user can open up the pop-up window multiple times to input multiple sets of data. For each set entered, the pop-up would have to determine if there's already a DataTable being stored in the parent window, and if so, append the data to the already-existing DataTable, or if there isn't already a DataTable, create a new one. One measly temporary table would solve this in like one line by simply adding a row for each set of data entered.
However, if I'm not mistaken, it is generally considered bad practice in programming to use temporary variables when there are other alternatives. Of course I would like to keep my database as clean as possible, but simply keeping this data in a temporary table would solve all of my problems without cluttering up the ASP.NET/C# code with all of this preserving the data locally across postbacks, blah blah blah.
However, if I'm not mistaken, it is generally considered bad practice in programming to use temporary variables when there are other alternatives.
If I'm not mistaken, you are mistaken. There's nothing wrong with temporary variables, at all. I'd argue that tightly scoped "temporary" variables comprise the bulk of most well factored code. The idea is generally to only spool up a variable when you need it, and then ditch the thing as quickly as possible when it has outlived its usefulness.
I'd go pootle's route as well. Session is all about giving you a place to store stuff that you don't want to persist to disk just yet, but you want to have it available throughout the user's "session" (meaning preserved across multiple postbacks).
In SQL 2008, it is possible to have a stored procedure with a table valued parameter. I also read something about streaming the input to this table from a .NET front end. Not sure if this would be applicable in your case. This article may do the trick. Table-Valued Parameters in SQL Server 2008 (ADO.NET)
Well, my noodle has officially been cooked. If I'm reading that right, it looks like structured data types are put on the wire after each yield statement fired by the IEnumerable passed as the parameter value... Is that seriously what's going on? That's kind of nuts.