讨论：关于SQL数据库的事务处理。
单位开发一个数据处理量较大的项目，使用VB.NET2003+SQL2000。
现在正在设计当中，到时大概会有100台左右的电脑同时使用一个数据库。
由于肯定要用到事务处理，想跟高手们讨论一下：
在存储过程中使用BEGIN TRAN...ROLLBACK TRAN...COMMIT TRAN这样的事务处理好，
还是在代码中使用BeginTransaction...Rollback...Commit这样的事务处理好？
请高手分析一下，各自的优缺点。谢谢！
[解决办法]
效率上的差距不太清楚。想来差距应该不大
光从程序上来说。写存储过程很明显是个痛苦的过程，因为调试等等很困难，阅读起来也不够清晰。代码里的transaction明显就很清楚明白，从开发者的角度来说，我觉得放弃存储过程是可以的
[解决办法]
俺是放在程序中的，因为执行过程中可能执行多个存储过程!
[解决办法]
我们的项目一般都是放在代码里处理的.
如果是考虑效率的话,这个你应该找本SQL的书看看.
[解决办法]
感觉code里事务锁比较独占或排它, 事务内操作不当很容易time out.
如果代码复用度不高,尽量放SP里.
[解决办法]
个人觉得：
使用BEGIN TRAN...ROLLBACK TRAN...COMMIT TRAN这样的事务处理好
[解决办法]
要说效率，还是觉得在存储过程中会高一些
[解决办法]
所谓事务是指一组逻辑操作单元，它使数据从一种状态变换到另一种状态。
包括四个特性:
1、原子性 就是事务应作为一个工作单元,事务处理完成，所有的工作要么都在数据库中保存下来，要么完全回滚，全部不保留
2、一致性 事务完成或者撤销后，都应该处于一致的状态
3、隔离性 多个事务同时进行，它们之间应该互不干扰.应该防止一个事务处理其他事务也要修改的数据时，
不合理的存取和不完整的读取数据
4、持久性 事务提交以后，所做的工作就被永久的保存下来
[解决办法]
这个要根据你的系统来配合使用，不是说用哪个不用哪个；
速度上来说，存储过程中会高一些
[解决办法]
数据库的东西还是数据库来处理好了。
[解决办法]
基本还是在代码中处理，部分比较特殊的处理是使用存储过程的
[解决办法]
个人觉得，如果要是偏向于数据的操作的话，使用存储过程可能效率会好一些，但是如果要是其中掺杂有大量的业务逻辑的话，建议还是不要放到存储过程中，使用代码可能会更清晰一些，可能有人会说，放到存储过程中，还保证了业务逻辑的隐秘性，但是如果想想如果其中出现问题，调试数据库的存储过程可是一个噩梦，所以说，如果是偏简单或偏数据操作性强的流程，使用数据库存储过程可能会好一些，反之，可以考虑在代码中实现，差别应该不是很明显。
[解决办法]
6楼说得对，记得看过一本书，在存储过程中的代码是编译好的，比每次写再编译要好一点，但在代码安全性方面，存储过程又没有程序代码安全，方便性上说也是存储过程要有优势，有时改变算法不用更新客户端
[解决办法]
当然在存储过程好。
[解决办法]
当然在存储过程好啦
[解决办法]
这个肯定是能用存储过程就用存储过程，除非有些逻辑必须要和程序交互
[解决办法]
