SQLCHILD (2/10/2011)
Dear Lowell Sir,Actually, i have a .net application through which lacs of data would be inserted by the users.
but as usual, users keep on making mistakes. so i want that at the back end of the application,when the users enter the data, then the data is entered into a temporary table, and after the user presses the last save button, then the whole data is committed to the main original table.
also, the users delete the data by mistake, which would be very dangerous.
so i want that if a user deletes the data by mistake, then it is deleted from only the temporary table and not from the original table. that is why i need the users to alter, delete and insert in the temporary table, and when the final button is pressed then the data is committed to the original table.
there is nothing that you mentioned that needs a temporary table so far.....
It sounds like you have two issues...not enough validation in your .net application to filter/remove the end user mistakes...and posting those changes to the server too early in the work path.
I cannot help with the additional validation...that's business rules unique to your application..it's simply a If MyValidationRoutine() then msgbox(errors) in your app.
as for the second part, it sounds like you have most of everything in place: so you have a Datatable in .Net typed dataset that is loaded via MyAdapter.LoadDatatable. so the end user already has a "local" copy of the data.
you have "two" levels of save: one that posts to the server before it should...change that so it does not call UpdateDataTable. make sure the UpdateDataTable is called only at the "second" save you mentioned...when all the data is validated and the "final" button is clicked instead.
what value, at all, would there be to put bad data into a temporary table, and then post bad data to the permanent table? none that i can think of. your core issue is you KNOW end users are putting in bad data...concentrate coding efforts on preventing THAT; the temp table does not fix that issue...it just makes it more complex...shuffling the erroneous data to more than one spot.
as for deleting data...you can do the following: instead of REALLY deleting, you can add a column "isDeleted" to your data...then you can make the .net application select values WHERE isDeleted = 0 , and have the .net UPDATE that field to mark the row as deleted, instead of really deleting it...that makes it very easy to add an inteface to "undelete" records that should not be deleted/need to be recovered.
Lowell