多用户操作时的临时表问题(20分)

SQL数据库，如果有五个客户端，每个客户端同时使用，在销售商品时，先将客户要的物品一样一样录入表中，录入后立即显示内容，并且可以在发现错误后删除掉，等确认无误，顾客付款后再写入正式的数据表中。象这样一种方法我现在是用临时表做的，用的是以#开头的局部临时表，在软件CREAT事件中创建临时表，不设删除表的代码（我认为软件退出时就自动删除掉了）经实践是各个客户端都能自己收自己的商品，互不相干的，不知道有哪位高手也用过类似的方法，遇到什么特殊的问题没，有没有要注意的地方？

你的做法是对的，有什么问题吗？#table相互不干扰的，也不用专门去drop，但是从操作规范来说还是罗索一点drop掉吧。因为#table认连接，不同的连接虽然相互不干扰，但是怕同一个连接 在不同的功能里面用到同名的#table。<br><br>另外有一个建议，除了每个客户端开辟一个临时表之外，最好设置一个共享的后台表，把每个客户端的内容都复制一遍进去，这样便于校对库存，比如说，库存10个，有2个客户端都申请了9个，如果用#table，这种情况是无法分辨出是否合法的，只有等到在真正存盘的时候，才知道，那时再处理太慢了；所以最好有一个总的表，第一申请9个，后来的，看到库存只剩下1个，就不会产生负库存了。<br>至于这个总表的维护动作，也是一件很麻烦的事情，自己想办法解决吧，记得想全面一点，因为可能死机导致卡死单。

先感谢jenhon前辈，您考虑得很全面，对我很有启发。再听听其他高手的指点。对了，我在想的另一个方面是否要注意：就是写入局部临时表中的内容，金额肯定是要求和的（sum(单项累计）from 临时表），那么写入与求和之间是否能确保一致，也就是写入了一定就求和，求和不成功写入也删除掉，对临时表操作是否好用事务，还是用try包括起来，但我想在一二秒钟内连续发生的事情，不会刚刚写入好，就不好求和，不会这么巧吧？

不一定就这样做,坏处是网络流量增加,数据库服务器负担增加,我的做法是用<br>cached dataset ,stringgrid 或 一个record array ,或链表保存,显示用stringgrid 就可以了,自己format 显示<br>只在最后insert 到 库,而且可以使用transaction .<br>每增加一个记录,自动计算一次sum ,都是小case <br>而且这种处理一般都是master/detail的关系的,用个transaction 比较好保证完整性,当然也见过有用单条记录的,那么其格式肯定不符合范式,比如<br>sheet_id ,create_date ,saler_id ,qty_total,amount_total,为主表<br>sheet_id,line_no,product_id,product_qty,org_price,real_price,discount,为从表<br>的话,主表完全要冗余,好处是做脱机上传方便,但不符合范式<br><br>可以将主从表分别用<br>record,和 record array (假设填写最多1000记录,也只占用几十KB 的内存),

多人接受答案了。