(16楼提供了参考结论)ADO之Excel自连接会导致性能下降吗?

coby001

liu-aguang 发表于 2014-12-17 18:16
这里讨论的是"自连接"方式与非自连接方式之比较.当然要用同一引擎.

因为你在结论里有
3.无论用Jet或ACE引擎其结论一致.

又没看到你的程序里用了Jet，所以才感到奇怪~

coby001

LDY  在 那个帖子里说：ADO连接自身时有个严重的BUG，多次运行查询语句是会造成内存无法释放，并且会内存占用迭加。

也许，ACE引擎已经修复此bug~
要用Jet 来对比一下，才清楚~

liu-aguang

coby001 发表于 2014-12-17 20:55
LDY  在 那个帖子里说：ADO连接自身时有个严重的BUG，多次运行查询语句是会造成内存无法释放，并且会内存占 ...

jet测试过了.我想有这种可能后来的两种引擎都修正了这种"BUG".或者赵版所说是由于win版本的原因.
我查证过,从xp时代开始到win7,jet 32b驱动程序虽然名字始终一样,但版本却从4.0升级到了6.0.而善解人意的MS允许在不同win 和office 版本的ADO语句使用同样连接字串.早知如此,MS就不该在连接字串中带版本号,使后来人以为使用jet更落后.事实上,jet与ace在速度上经过不完全测试,是差不多的.

百度不到去谷歌

.OLEDB.12.0已经不存在这个问题了吧 以前的8.0才有这问题你在本机上测试 装了新的office我想bug都修复了
如果在只装了2003的机器上测试jet我想bug应该是一定存在的 所以应该是office版本的问题

liu-aguang

百度不到去谷歌 发表于 2014-12-18 08:26
.OLEDB.12.0已经不存在这个问题了吧 以前的8.0才有这问题你在本机上测试 装了新的office我想bug都修复了
如 ...

jet好像是系统自带的.

liu-aguang

最终结论:
1.本帖所讨论的ADO of Excel "自连接",内存迭加问题是用jet(或odbc)连接所引起的.并只存在于XP系统环境下(或以前版本).ace连接方式自诞生以来没有该问题.
2.win7以后无论什么连接方式都不存在该问题.原因在于win7升级了obdc驱动.
3.目前仍在使用xp系统的用户的解决方式可选择以下的方式之一:
   ....按版主提供的方法;
   ....如果使用的是2003Excel,可安装AccessDatabaseEngine.exe组件后,改用ace连接方式.(2007以上不用安装)
   ....如果仍要使用jet连接,增加内存也是一个不错的选择.(事实上,如果内存容量大,其执行效率与不自连接方式完全一样)

xd3210

liu-aguang 发表于 2014-12-19 10:40
最终结论:
1.本帖所讨论的ADO of Excel "自连接",内存迭加问题是用jet(或odbc)连接所引起的.并只存在于XP系 ...

佩服各位老大的科研精神！

coby001

liu-aguang 发表于 2014-12-19 10:40
最终结论:
1.本帖所讨论的ADO of Excel "自连接",内存迭加问题是用jet(或odbc)连接所引起的.并只存在于XP系 ...

Sub ace_test()
    Const xlsPath$ = "D:\My Documents\SQLite_Ado.xls" ' 这个改为你自己的xls文件路径
    Const sSQL$ = "Select * From [Sheet2$]" ' [Sheet1$]

    '前期绑定
    Dim cnn As New ADODB.Connection, rs As New ADODB.Recordset
    'Set cnn = CreateObject("adodb.connection")  '后期绑定
    cnn.Open "provider=Microsoft.ace.OLEDB.12.0;" & _
             "Extended Properties=""excel 8.0;hdr=yes"";" & _
             "Data Source=" & xlsPath

    rs.Open sSQL, cnn

End Sub


到微软下载 AccessDatabaseEngine.exe
http://www.microsoft.com/zh-cn/download/confirmation.aspx?id=13255

安装后
在 Xp sp3 + Excel2003 + ADO2.8  环境下，测试通过。-

liu-aguang

coby001 发表于 2014-12-19 12:28
Sub ace_test()
    Const xlsPath$ = "D:\My Documents\SQLite_Ado.xls" ' 这个改为你自己的xls文件路径 ...

在XP系统里:
如果的确存在查询上百的或更多的工作表,或者用该代码在不退出电子表格的情况,进行不限定次数的查询.修改连接字符串为ACE方式连接,是一个好的选择.
如果不是上面的情况,事实上可以不用修改任何代码.只要内存足够大(比如:2G,:::现在看是小容量了,当时标配一般是512M).在XP系统中,jet连接的效率要比ACE好.
己以为:造成迭加的根本原因不在ADO,而是EXCEL.
当以可读写方式打开Excel时,如果操作电子表格数据,那么Excel会自动开辟(或索取)一个内存块,用来存放你可能修改的数据,它必须在你关闭excel后回答是否保存修改才会释放该内存块.所以在自连接中,即使是读取同一工作表,每读取一次都会扩展那一块内存,从而导致迭加.
同样的道理,如果用非自连接方式去查询一个已经打开的数据源工作簿,情况会与自连接完全相同,也会存在内存迭加的问题.
版主的解决办法,实际上就是让工作簿以只读方式打开工作簿,这样来避免EXCEL自动开辟内存块.

当然也可以认为是ADO的jet引擎的问题:它考虑欠周到.因为初期的ADO是为系统数据库而开发的.对EXCEL这种非规范数据源没有仔细推敲.所以后来得以纠正.

至于第一次操作以可读写方式打开的EXCEL,而开辟的内存块,无论那种方式,也无论过去还是现在,在EXCEL退出之前都不会释放,这是由EXCEL特征所决定的.

561815084

弱弱的请教个问题，比如一个工作簿，多次操作access
每句代码结束前是否都需要加上以下代码来释放链接？或者结束工作簿的时候再结束链接？或者关闭工作簿后什么也不用管了，直接关闭工作簿？
   rst.Close
  conn.Close
   Set rst = Nothing
Set conn = Nothing