使用 vb6 从 Excel 中提取忽略的列

发布于 2024-07-07 09:04:22 字数 2592 浏览 5 评论 0 原文

我正在尝试使用 vb6 从 excel (2003) 电子表格中提取值表,其结果需要存储在 (adodb) 记录集中。 该表如下所示:

    Name   Option.1  Option.2  Option.3  Option.4  Option.5  Option.6 
    -----------------------------------------------------------------
    Name1         2         3         4
    Name2         2         3         4
    Name3         2         3         4
    Name4         2         3         4
    Name5         2         3         4
    Name6         2         3         4
    Name7         2         3         4
    Name8         2         3         4
    Name9         2         3         4         5         6         7  

连接并执行查询“SELECT * FROM [Sheet1$]”或什至特定于列的“SELECT [Option#6] FROM [Sheet1$]” ”(参见脚注 1)并循环遍历结果,为 Name9Option.4 行提供了 Null 值--> Option.6 而不是正确的值 5、6 和 7。似乎与电子表格的连接正在使用“最佳猜测”来决定有效的表限制是什么,并且只需要一组考虑的行数。

为了连接到电子表格,我尝试了连接提供程序 Microsoft.Jet.OLEDB.4.0MSDASQL 并遇到了同样的问题。

以下是我使用的连接设置:

Set cn = New ADODB.Connection
With cn
    .Provider = "Microsoft.Jet.OLEDB.4.0"
    .ConnectionString = "Data Source=" & filePath & ";Extended Properties=Excel 8.0;"
    - - - - OR - - - - 
    .Provider = "MSDASQL"
    .ConnectionString = "Driver={Microsoft Excel Driver (*.xls)};" & _
                        "DBQ=" & filePath & ";MaxScanRows=0;"
    .CursorLocation = adUseClient
    .Open
End With  
Set rsSelects = New ADODB.Recordset
Set rsSelects = cn.Execute("SELECT [Option#5] FROM " & "[" & strTbl & "]")

仅当行数超过 8 行(不包括列名)时才会出现此问题,并且我为 MSDASQL 设置了 MaxScanRow=0连接,但这产生了相同的结果。

我包含的值得注意的项目参考有:

  • MS ActiveX 数据对象 2.8 库
  • MS ActiveX 数据对象 Recordset 2.8 库
  • MS Excel 11.0 对象库
  • MS 数据绑定集合 VB 6.0 (SP4)

任何有关此事的帮助将不胜感激!

(1) 由于某种原因,当列名中包含小数点时,它会被解释为 #。


感谢大家! 尝试从 KB155512Schema.ini a> onedaywhen 非常棒帖子向我指出了解决方案:

.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "Data Source=" & filePath & ";Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1"";"

我会鼓励任何有类似问题的人阅读这篇文章和评论,因为每个人的解决方案都略有不同。

I am trying to extract a table of values from an excel (2003) spreadsheet using vb6, the result of which needs to be stored in a (adodb) recordset. The table looks like this:

    Name   Option.1  Option.2  Option.3  Option.4  Option.5  Option.6 
    -----------------------------------------------------------------
    Name1         2         3         4
    Name2         2         3         4
    Name3         2         3         4
    Name4         2         3         4
    Name5         2         3         4
    Name6         2         3         4
    Name7         2         3         4
    Name8         2         3         4
    Name9         2         3         4         5         6         7  

Upon connecting and executing the query "SELECT * FROM [Sheet1$]" or even a column-specific, "SELECT [Option#6] FROM [Sheet1$]" (see footnote 1) and looping through the results, I am given Null values for the row Name9, Option.4 --> Option.6 rather than the correct values 5, 6, and 7. It seems the connection to the spreadsheet is using a "best guess" of deciding what the valid table limits are, and only takes a set number of rows into account.

To connect to the spreadsheet, I have tried both connection providers Microsoft.Jet.OLEDB.4.0 and MSDASQL and get the same problem.

Here are the connection settings I use:

Set cn = New ADODB.Connection
With cn
    .Provider = "Microsoft.Jet.OLEDB.4.0"
    .ConnectionString = "Data Source=" & filePath & ";Extended Properties=Excel 8.0;"
    - - - - OR - - - - 
    .Provider = "MSDASQL"
    .ConnectionString = "Driver={Microsoft Excel Driver (*.xls)};" & _
                        "DBQ=" & filePath & ";MaxScanRows=0;"
    .CursorLocation = adUseClient
    .Open
End With  
Set rsSelects = New ADODB.Recordset
Set rsSelects = cn.Execute("SELECT [Option#5] FROM " & "[" & strTbl & "]")

This problem only occurs when there are more than 8 rows (excluding the column names), and I have set MaxScanRow=0 for the MSDASQL connection, but this has produced the same results.

Notable project references I have included are:

  • MS ActiveX Data Objects 2.8 Library
  • MS ActiveX Data Objects Recordset 2.8 Library
  • MS Excel 11.0 Object Library
  • MS Data Binding Collection VB 6.0 (SP4)

Any help in this matter would be very appreciated!

(1) For some reason, when including a decimal point in the column name, it is interpreted as a #.


Thanks everyone! Halfway through trying to set up a Schema.ini "programmatically" from KB155512 onedaywhen's excellent post pointed me towards the solution:

.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "Data Source=" & filePath & ";Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1"";"

I would encourage anyone with similar problems to read the post and comments, since there are slight variations to a solution from one person to another.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

无法回应 2024-07-14 09:04:22

默认情况下,Excel ISAM 驱动程序会查看前几行并猜测它们的数据类型。 如果(表中后面的)数据不符合初始假设,它会皱起眉头并将其转换为 NULL。

您的 MaxScanRows=0 设置是解决此问题的关键。 听起来它会做正确的事情(扫描整个表以查找要使用的数据类型),但实际上并非如此。

有关更多详细信息,请参阅 onedaywhen 的答案,我的关于 KB282263 的第一个信息不是正确的建议。

The Excel ISAM driver by default looks into the first handful of your rows and guesses their data type. Should there be (later in the table) data that does not fit into the initial assumption, it frowns and turns it to NULL.

Your MaxScanRows=0 setting is the key to this problem. It sounds like it would do the Right Thing (scan the whole table for the data type to use), but really it doesn't.

See onedaywhen's answer for further details, my first info about KB282263 was not the correct advice.

蹲墙角沉默 2024-07-14 09:04:22

您是对的:它是根据行数猜测数据类型。 您可以更改本地计算机注册表项以影响所选的数据类型。 有关更多详细信息,请参阅此答案

You are correct: it is guessing the data type based on a number of rows. There are local machine registry keys you may be able to alter to influence the data type chosen. For more details, see this answer.

手心的海 2024-07-14 09:04:22

我能给你的最好建议是停止在 VB6 环境中这样做。 打开 Excel,按 ALT+F11 并加载 VBA IDE。 把你的代码放在那里。 在此环境中,您可以访问完整的 Excel 对象模型。

我见过很多人尝试以多种不同的方式与 Excel 进行交互,但他们都遇到了问题。 我发现使用 VBA 宏或外接程序方法是获取数据的最佳方法。 这就是 Microsoft 将 Excel 和 Project 与 TFS 集成的方式。

有时您需要稍微重新考虑该过程才能使这种方法合适。 例如,您可能需要让使用电子表格的用户运行一个宏,将数据推出电子表格,而不是运行一个进程从电子表格中提取数据,但通常这是完全可行的。

The best advice I can give you is to stop doing it in the VB6 environment. Open Excel, press ALT+F11 and load the VBA IDE. Put your code in there. From within this environment you can access the full Excel object model.

I've seen many people try and interact with Excel in many different ways and they all have problems. Using either the VBA macro, or Add-in method is a best way I have found of getting at the data. It's how Microsoft get Excel and Project to integrate with TFS.

Sometimes you need to rethink the process a little for this approach to be suitable. E.g. You may need to get the user who is using the spreadsheet to run a macro that will push the data out of the spreadsheet instead of you running a process to pull the data from the spreadsheet but usually it is quite doable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文