1、客户端定时查询的业务场景，可考虑放到服务器一次性查询出结果后通知给到各个客户度即可。比如每个客户端都有超时显示的语句，消息查看的语句等。
2、在实际开发中，假如碰到跟操作系统和IE版本不兼容的情况下，可以多考虑进行套壳兼容的模式。自己封装实现后提供使用。
3、很多系统涉及到的SQL语句写在代码里面，导致每次增加字段或修改语句，需要同时修改对应的业务服务程序，影响较大，开发和维护成本也大。
4、具体SQL语句复杂的情况下，可能是表设计的不合理导致的，可以根据业务场景进一步优化表结构的一些设置逻辑。从而优化对应的语句。
5、建议使用分页查询逻辑，以及对应的控件来实现。用户无感知的切换到下一页进行显示和处理。
6、其他内容：
（1）多个业务功能点，混合在一起，使用同个SQL语句进行书写，导致查询字段多，关联表多。
（2）相同业务功能点，不同医院在查询语句上也会略有区别，导致不断增加字段，维护起来也诸多不便。
建议进行2类改造：
（1）针对原因（1），每个SQL语句确认是否有多个业务功能点使用，存在这种情况，需进行拆分，对每个业务功能点，重新梳理查询条件，展现字段，写多个SQL语句。
（2）针对原因（2），对查询类需求需进行以下改造：
（a）需寻找C++下类似JAVA中MYBATIS的数据层框架，将语句放到配置文件中进行书写。这样代码不用改变，针对每家医院，同个业务功能点可以配置不同的SQL语句，减少维护的难度。
（b）除了相同功能点配置不同SQL语句，还需做到查询结果的标题能动态从配置中获取，这样才能做到可查询结果可配置。
（3）分页改造：
（1）后台开发统一的分页方法，通常框架中会针对查询至少提供2个接口queryByPage(分页查询)以及query(一般查询，不分页)，当然根据不同的入参和出参，会有多个这样的查询方法。
（2）前台提供独立的分页控件，或者是表格控件带分页功能，同时同后台服务确定好分页涉及的接口参数，如总条数，每页记录数等，方便后台分页方法的出参的确定。