Master / Detail Approach in web

Hi,
Im currently working in C# project with header / detail. Kindly help me on the right approach in handling the header / detail approach in web application.
The user will fill up the header web form and then the user will PRESS the attachment BUTTON, popup window will appear on the screen. (in this case I will save the header record into the database in order for me to create a KEY for the new record, ONLY A TEMPORARY KEY) After pressing the Save button on the attachment window. I will save the detail part. So now I have a header / detail record in my database with TEMP KEY. Once the user press the SUBMIT button of the page that's the time I will change the TEMP KEY with the STANDARD KEY based on our reference.
What I want is that until the users press the SUBMIT button the information entered in the scren will be saved in the temporary file and if everything is ok, once the user press the SUBMIT button that's the only time I will save it in the database.
Your ideas and comments will help me a lot.Dabuskol--
Regarding this...

Dabuskol wrote:

Im currently working in C# project with header / detail. Kindly help me on the right approach in handling the header / detail approach in web application.
The user will fill up the header web form and then the user will PRESS the attachment BUTTON, popup window will appear on the screen. (in this case I will save the header record into the database in order for me to create a KEY for the new record, ONLY A TEMPORARY KEY) After pressing the Save button on the attachment window. I will save the detail part. So now I have a header / detail record in my database with TEMP KEY. Once the user press the SUBMIT button of the page that's the time I will change the TEMP KEY with the STANDARD KEY based on our reference.
What I want is that until the users press the SUBMIT button the information entered in the scren will be saved in the temporary file and if everything is ok, once the user press the SUBMIT button that's the only time I will save it in the database.
Your ideas and comments will help me a lot.

...I will guess that the solution depends largely upon the amount of data that is being save and where that data is being saved.
(A) Are you saving the header-data in the database and the detail-data in the file system?
...or...
(B) Are you saving the header-data in the database and the detail-data in the database?
Please clarify that if you can.
Let's suppose the case is (B).
If so, then why not simply either user a flag column to denote a temporary row, along with a date created. That way, you will not have to swap out the keys. If the data never gets finalized, then you can write "delete temp data"
functionality into a SQL job or some other scheduled process.
Another way to do it is to use 2 tables-- one for the temp data and one for the permanent data. When the data is finalized, move it over to the permanent table.
Also, are you saying that when you change a key you are changing the primary key for a record?
Please clarify.
If that is the case, I would recommend against it. It can be done; but, it is usually unnecessarily complex, especially if the key gets propogated elsewhere. Use a flag column instead, which provides the same benefit without the hassle.
Another way to do it is to use a seed table that generates your keys and read them out as-needed. You would still have the problem of changing the primary key
Note that as I think about it, a lot of this reduces to the argument "for artificial keys" or "against artificial keys", which is a long topic but, with the need for replication and data migration these days, I daresay the proponents of artificial keys have won the argument. Anyway, I am generally a "pro artificial keys" guy and, as such, I say that, in general, it is a VERY bad idea to change primary keys in a table once the key has been generated. In short, primary keys should be ignored and they should never be relied upon other than to provide low-level data integrity. One should not expect them to be human readable, gap-less, or anything else other than unique.
That's it, off the top of my head. I am sure there are better ways to do this and I am sure you can find differing opinions.
HTH.