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)[0].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); } }
好了，至此，稳定性的问题解决了，周末愉快！