It won't be so much of a pain in the rear to keep the data in Session variables if you create a DataSet to hold all the data and then use Data Adapters to send it all to the DB at the right time. In fact, you'll only need one session variable: a reference to the DataSet. The DataSet's collection of Data Table objects can have one member for each of the actual database tables your data will be stored in. A separate Data Adapter (not to be persisted between pages) will handle each individual Data Table
If you're using Visual Studio, do the following for each of the tables that your application will need to update: Drag the appropriate type of data adapter from the toolbox onto a Web Form and run through the "Configure Data Adapter" wizard. Then, right click on the adapter and select "generate dataset". This will create a DataSet and also put the Data Tables in it. The combination of the wizard and the generate dataset steps will generate a raft of code. Even if you can't use the code as is in your app you can cut-and-pase this code into your own code module(s)
If your app only needs to insert rows into the DB, then you can just use the generated SQL statements for INSERTS but the wizard will generate SELECTs, UPDATEs, DELETEs - the whole nine. When you issue the Update command for each data adapter, it will issue the correct queries, according to "row state" values that are held in the Data Table objects. Just be sure that your adapters have Command objects that execute the types of SQL statements that your row states indicate. (For example, assume a Data Table only has rows that are in "added" state. Its DataAdapter won't need DELETE or UPDATE when executing its "update" method. It will be perfectly happy to execute the necessary INSERTs without the other commands.
It's not magic, there isn't even any pixie dust involved. This approach merely saves you a lot of tedious coding. Not only do you get the SQL statements, you don't have to code up a whole potful of assign statements to store stuff in session variables and then pull it all back out and feed command parameters when it's time to commit to the database. Study the wizard-generated code carefully to make sure you understand what it's doing and selectively copy it into the right places within your app. Make it a learning process
Your DataSet can contain primary and foreign keys, relations, validations, etc. - all of which may be useful in ensuring that the data is valid before you send it to the DB. If there are constraints in your database (e.g. Foreign Keys), they may impact the order in which your application has to issue the various commands. It's important to keep in mind that the DataSet is totally disconnected from the DB; that's why you can keep in it session state without affecting the DB itself
One other thing to consider: Datasets can be "typed" (meaning that they are impemented in XML) and there's a way to store the XML in View State. Given that you'll need to pass the data from one page to the next, I couldn't say, off hand, whether that wouldbe a good approach or not. But, you might want to look into it. The tradeoff, of course, is that you wouldn't need the storage overhead of keeping all the data in session state but your page loads and round trips will have more volume to deal with
Good Luc
