彻底抛弃MFC, 全面应用Qt 已经不少时间了。除了自己看书按步就班做了十几个验证性的应用，还正式做了3个比较大的行业应用，总体感觉很好。Native C++ 下， Qt 基本是我用过的最简便的界面库了。遇到了一些问题，大都解决的很顺利，回头想想，还是有几个问题很有意思，尤其是数据库应用。这里把我的经历分享一下。

1、线程内注册与连接数据库的竞争问题

        文档上对多线程下数据库应用的注意事项写的很简明，一个线程创建的 QSqlDatabase 对象和 查出来的 QSqlQuery 对象只能给本线程用（注意，是对象，不是数据库连接本身，连接本身用名字可以多线程使用），其他情况是“不支持的”。在一个需要有几个线程并发访问不同数据库的应用中，我首先试图在各个线程的起始分别以不同的名称调用  addDatabase / database 、open，但是程序偶然会崩溃，跟踪后发现，虽然Qt 声称很多方法是“线程安全”的，但是几个方法串起来，就出问题了。Qt会动态的加载数据库的plugin, 加载 plug in 的部分，涉及到对本地库文件的管理，这一部分，出现了竞争。于是，很自然的想到在初始连接部分设置 Mutex 保护，从 addDatabase / database到 open 的部分，要保证其原子性，问题再也没有出现。

2、数据库连接意外断裂后，恢复连接的问题

      在MFC 中，一旦中途TCP连接断裂，直接重新 Open 就可以了。在Qt 里，这一招不好使了。即便 调用了 close ，再次open 也是不行的。处理方法：

      在检测到问题出现后，关闭连接，并 removeDatabase；   而后，不要立刻 addDatabase, 反而是要回到该连接所在的事件循环。没有详细跟源码，很可能在 removeDatabase 后的事件循环中，Qt 内部做了一些释放操作。   怎么办呢， 可以设置一个恢复定时器，比如 1分钟，重新 addDatabase，就可以啦。如果心急的话，直接显式调用processEvent() 方法强制循环。

      在多线程下，注意1中的问题，需要 Mutex保护。

3、数据库插件的依赖性问题

      在 Windows 下，有时我们的机器上按了好几个 Qt 版本，PATH里索性神马也不设置，依赖开发环境的继承环境适应不同的版本。这有两个问题。一是发布程序的时候，数据库驱动依赖的dll 也要与可执行文件在同一路径下发布。比如 mysql 的 dll, PostgreSQL 的依赖等。二是在集成开发环境中，这些依赖也要位于执行档文件夹下。否则，会造成虽然可以枚举到可用驱动，但是死活连接不上。调试一下就知道，原来是在路径中找不到依赖项，导致dll加载失败哦！

     Qt的数据库操作自成一派，相对于复杂的 ADO \ODBC\DAO\OLEDB 等传统 C++ 访问数据库的方法，还是很先进的，充分体现了 OO 的理念。对数据库的封装，想法是很有意思的。设计者把进程内的数据库连接作为一种资源，每个连接有一个唯一的名字，可以通过全局的 addDatabase, removeDatabase, cloneDatabase 来增删，想用的时候，直接用全局的 database 来获取。这样的好处，是大大节省了开发者的负担。以前为了传递一个数据库连接的变量，必须在很多方法入库处添加指向这个变量的指针或者引用，有时候不得不在对象的属性中加入静态的变量，来记录这个连接。现在，什么时候想用，给个名字就可以了，不需要传递。当然，文档说的是比较简化的，至少有两点要注意，

     1）这些增删方法号称是线程安全的，但是，在实际应用中，还是要注意用 Mutex 保护全局创建流程，或者，重载这些函数，创建自己的安全版本。

     2）一个线程创建的数据库对象（如 addDatabase 的返回值）只能在同一线程使用，但是，addDatabase 注册的连接（名字是开发者定）可以跨线程使用，唯一需要注意的是，在调用全局方法的时候，要有原子保护。