【发布时间】:2009-11-17 17:02:34
【问题描述】:
我在一个 vb6 应用程序中遇到了以下代码的奇怪场景:
Private database As dao.Database
Set database = openDaoDatabase([some valid database location], False)
createDBField database, "Table", "FirstRow", dao.dbInteger, 0, "0"
Public Sub createDBField(targetDB As dao.Database, strTable As String, strField As String, dbType As dao.DataTypeEnum, Size As Integer, strDefValue As String)
Dim td As dao.TableDef
Dim fld As dao.field
Set td = targetDB.TableDefs(strTable)
Set fld = td.CreateField(strField, dbType, 0)
If dbType = dao.DataTypeEnum.dbText Or dbType = dao.DataTypeEnum.dbMemo Then fld.AllowZeroLength = True
If strDefValue <> "" Then fld.DefaultValue = strDefValue
td.Fields.Append fld
Set td = Nothing
Set fld = Nothing
End Sub
当我逐步完成时,一切正常,新字段已添加到数据库中。但是,当我简单地运行应用程序时,数据库由于“不一致”而损坏。我添加了一些错误处理,现在得到错误:“无法识别的数据库格式:[路径]”。 搜索了微软的数据库,找到了解决办法:http://support.microsoft.com/kb/238401。我正在使用 Microsoft.Jet.OLEDB.4.0 提供程序,安装了 SP6 并引用了 Microsoft DAO 3.6 对象库,但它仍然无法正常工作!
有什么想法吗?
更新: td.Fields.Append fld 是罪魁祸首。删除所有静默错误处理后,我发现了一个错误:“运行时错误 3343 无法识别的数据库格式”。出于某种原因,我可以跳过它。
【问题讨论】:
-
“On Error Resume Next”是有毒的。把它拿出来,你会发现真正失败的地方。老实说,在 VBA 中使用它“没有充分的理由”。
-
很少有充分的理由 - 并且需要立即禁用 - 但是在这种情况下,是的,绝对是!
-
@Binary Worrier - 我意识到 On Resume Next 很危险,并已将其删除。谢天谢地,我没有写这个函数。 On Error Resume Next 在这个程序中无处不在,它给我带来的不仅仅是我的头疼。
-
什么值被传递到导致问题的子程序中?更具体地说是 strField、dbType、Size 和 strDefValue。我在 Access 中使用多年的逻辑有点类似,没有任何此类问题。
-
您究竟是如何使用 Microsoft.Jet.OLEDB.4.0 提供程序的?