对于ADO处理要非常的谨慎，我们的大多数beta版产品的质量都同Microsoft已发布的产品的质量是一样的，只有对数据准确性要求极高并且用户可以忍受等待的情况下，使用这种并发冲突的处理方法。

1. 放任不管方式：

与其说这是一种处理并发冲突的方式，不如说，它是一种没有对并发冲突做任何处理的方式。但是在许多过去的系统里，由于没有考虑到多用户、网络应用等情况，这种"处理方式"还真存在于不少系统中。

举例来说，A、B两人从数据库中获取了同一个笔记本的信息，例如：IBM ThinkPad T61吧。然后：A把牌子改成了：Lenovo ThinkPad，B把型号改成了T61 8890A24。然后，他们开始提交了。此时，如果A先提交，然后B提交，那么，最后的结果是：IBM ThinkPad T61 8890A24ADO处理；反之，则变成Lenovo ThinkPad T61。

总之一句话，谁最后提交谁老大。想像一下，如果A修改了1000个属性的值，B修改了1个属性的值，那么，对于先提交的A来说，这将是一个多么惨痛的打击:-) 虽然这种放任不管的方式似乎不太负责任，但是，其处理性能却是相对较高的。

2. 开放式并发处理

开放式并发处理，老外叫做Optimistic Concurrency——乐观的并发。这种并发处理方式要求我们对并发抱有一种乐观的态度：百分之九十九点九九不会发生并发冲突，万一发生了，系统也能捕获到冲突，或者根据策略自动处理，或者，就提醒一下用户，让用户来决定是不是要继续提交。

仍然用上面的例子来说这事儿：A、B两个人同时获取了笔记本的信息：IBM ThinkPad T61。然后……（此处跟上例做一样的修改，直到提交）此时，如果A先提交，那么，B提交的时候，系统会发现，哎哟，不好，有并发冲突了，就会抛个异常给B，让B知道，发生并发冲突了ADO处理，然后，B就可以根据实际情况，选择相应的处理策略（比如，继续提交进行覆盖或者取消提交等等）；相反，如果B先提交，那么，A提交时，就会得到相应的提醒。 #t#

这样的并发处理方式，可以说在可靠性与性能上取得平衡，适合于对数据可靠性要求不是特别严格，需要较高的性能，并且不会大量发生并发的场合。

3. 保守式并发ADO处理

这是最为严谨的一种并发冲突的处理方式。它把并发转化为了串行操作。 例如，A从数据库中获取了笔记本信息：IBM ThinkPad T61，B也要对其进行修改，但此时由于A已经从数据库中将数据取出，因此，B被置于等待状态。直到A把数据修改完提交了，ADO处理数据库数据更新为Lenovo ThinkPad T61了，此时，数据库才把数据给B，那么B就可以在Lenovo ThinkPad T61的基础上，把它修改为Lenovo ThinkPad T61 8890A24。而在B提交前，其它一切针对此记录的操作都得排除等着B。

这样子当然非常理想，由于不存在并发，自然也就消除了并发冲突的问题。但是，ADO处理这种锁也存在着较为隐蔽的风险：如果A修改了数据，一直不提交，或者A因为故障，没有办法提交，那么，其它所有的相关的操作，都将被阻碍住。因此，只有对数据准确性要求极高并且用户可以忍受等待的情况下，使用这种并发冲突的处理方法。