First, "Thank you" to those ppl who have taken time to help answer my previous questions regarding data and updating.. I am much greatful for always being able to find answers and help on the UT :-)

.. and now on to the problem.. :-)

From what i gather, there are basically two ways to deal with tableupdate when it fails - either reissuing Tableupdate with Force, to overwrite any changes, or Tablerevert, to get the updated data... Now the problem is, when you run into this in the middle of, let's say processing on many tables, reverting would leave you with a partially processed order for example,.. This may lead to incorrect inventory or incorrect total sales when calculating commission for a salesman.. forcing updates would also lead to some lost information so if this is the case, where do you go from here?? It seems that you get "screwed" either way :-/
Unless there is a way to retrieve the updated data and then retrying the modifications to the table and trying the update again? It seems that this is not quite possible or will take quite the bit of coding to accomplish..

---
Jonathan Chan


Big P.S. The previous problem I had was solved, however not in the best way possible. I'm dealing with some pretty tight time constraints so I opted for the simplest method possible (that I could implement quickly) in dealing with data - Table Locks.. Lock a table, change, update, unlock... I already see it effecting performance vs. buffering alone, but it is not tremendously slow, and it works perfectly, no messing up my data. It will not scale well but i have talked with my friend (studying in Waterloo, no less ;) and a fairly recent employee of MS) and we agree that moving to n-tier would be a very good solution for the company. Making such a move will require enough planning and design which should not be rushed. I hope to be able to make the move before the current solution becomes too slow..

pps.. An electrical/computer engineer shouldn't have to be dealing with all this?? Sounds more like a job for CompSci ;)