DBImport V3.7版本发布及软件稳定性（自动退出问题）解决过程分享

DBImport V3.7介绍：

1：先上图，再介绍亮点功能：

主要的升级功能为：

1：增加（Truncate Table）清表再插入功能：

清掉再插，可以保证两个库的数据一致，自己很喜欢这个功能。

2：信息栏增加红色部分：

黑色的信息太多，有时候错误信息被淹陌，分拆出来单独红色块标识错误信息，清晰一些。

3：增加保存所有的配置及配置还原：

之前只保存数据库链接的配置，为了第4点，包起了所有的配置，包括表名等。

4：增加自启动参数，用于定时功能的开机启动：

自启动参数为 - true 或 - 1，下一版本会处理成服务，支持重启电脑后继续服务。

5：解决软件稳定性（自动退出）问题。

下载地址：点击下载

下面重点介绍解决问题的过程：

记得我发布ASP.NET Aries框架的时候，有个演示地址：http://aries.cyqdata.com 。

由于总有个人别删除用户或数据或修改登陆密码，为了防止此种情况：

我把DBImport放到服务器，同时开启了定时功能，以为可以一劳永逸了。

结果软件运行运行着，就自动退出了，然后又得手工执行一次。

所以目前在执行的方案，锁定了文件的只读属性，来避免用户修改数据。

今天刚好想起来，于是就想到要解决它了，于是就有了以下的内容：

解决的过程：

1：先确认情况：

单独运行软件，开启定时功能，然后出去溜达一圈，回头再看结果：

多次确认后，而且问题不单纯：

A：卡住没反应。

B：抛异常定义到Application.Run（单独运行时表现直接退出软件）。

2：通过IntelliTrace查看异常：

开启了”IntelliTrace事件和调用信息“：

F5运行，抛：“尝试读取或写入受保护的内存。这通常指示其他内存已损坏”。

我以为找到问题，结果是掉坑里。

1：当一个方法返回数组T[] GetList()时，抛这个异常。

2：当Dictionary添加一个数组Add(key,T[])时，抛这个异常。

3：当方法的参数为：public MDataTable Select(params object[] selectColumns) 这种数组时，抛这个异常。

好吧，这数组是哪里得罪了微软，要被它这么欺负。

改了半天代码，把T[]数组的代码全改成List<T>，一般又一步，走向正常运行。

后来没折了，毕竟有些公开的方法有params参数不好改，只好把选项改成“仅IntelliTrace事件”。

运行，等出Bug后，点一下全部中断：

然后就可以看到执行的事件了：

结合着自己记录的错误信息：

回头审了一下代码，终于发现一个Bug：

                if (isGoOn)
                {
                    using (SqlBulkCopy sbc = new SqlBulkCopy(con, (keepID ? SqlBulkCopyOptions.KeepIdentity : SqlBulkCopyOptions.Default) | SqlBulkCopyOptions.FireTriggers, sqlTran))
                    {
                        sbc.BatchSize = 100000;
                        sbc.DestinationTableName = SqlFormat.Keyword(mdt.TableName, DalType.MsSql);
                        sbc.BulkCopyTimeout = AppConfig.DB.CommandTimeout;
                        foreach (MCellStruct column in mdt.Columns)
                        {
                            sbc.ColumnMappings.Add(column.ColumnName, column.ColumnName);
                        }
                        sbc.WriteToServer(mdt);
                    }
                }
                if (_dalHelper == null)
                {
                    con.Close();
                    con = null;
                }
                else if (isCreateDal)
                {
                    _dalHelper.EndTransaction();
                    _dalHelper.Dispose();
                }

这段代码，在异常的时候，链接关闭不了，重点它还是开了事务的，没想到都老江湖了，百密还是有一输。

于是运行久了，连接池耗尽，加上事务卡死双重打击，界面就进入长时间卡死不动了。

找到问题修正就好了，关闭链接的放到Try的finally去：

finally
            {
                if (_dalHelper == null)
                {
                    con.Close();
                    con = null;
                }
                else if (isCreateDal)
                {
                    _dalHelper.EndTransaction();
                    _dalHelper.Dispose();
                }
}

第2个问题：自动退出的问题，有过经验。

毕竟当年创业写微博粉丝精灵的时候，就遇到过了：

对于Winform软件，不要在线程里操作UI，不要相信：StartForm.CheckForIllegalCrossThreadCalls = false;

于是，把所有的代码都改成主线程委托调用的方式，类似以下代码：

private delegate void SetTextHandle(string id, string value);

        private void ThreadSetText(string id, string value)
        {
            this.Controls.Find(id, true)[].Text = value;
        }
        private void SetText(string id, string value)
        {
            if (this.InvokeRequired)
            {
                this.Invoke(new SetTextHandle(ThreadSetText), new object[] { id, value });
            }
            else
            {
                ThreadSetText(id, value);
            }
        }

好了，至此，稳定性的问题解决了，周末愉快！