How to read Excel file with ADO?
I am trying to read an Excel file using ADO just as I have done with Access files for years. The code I am using is listed below. The problem is all the fields of the recordset are given the type adVarChar and numbers in the spreadsheet are not read into the recordset. Only cells containing text are read in. Recordset items corresponding to cells containing numbers are blank. Can anyone suggest a fix?
Set oXLDBConn = New ADODB.Connection
oXLDBConn.ConnectionString
"Provider=MSDASQL;" & _
"DRIVER={Microsoft Excel Driver (*.xls)};" & _
"DBQ=" & sWSheetFileSpec
oXLDBConn.Open
Set oXLRecset = New ADODB.Recordset
sSQL = "SELECT * FROM " & sRangeName
oXLRecset.Open sSQL, oXLDBConn, adOpenDynamic, adLockOptimistic
sWSheetFileSpec is the path to the spreadsheet file and sRangeName is the name given in the worksheet to the range of cells being read.
Remember, I want to do it with ADO if possible, not OLE Automation. By-the-way, can ADO connect and read from text files as well? Curently I manually create a recordset and use file I/O operations to populate it.
Set oXLDBConn = New ADODB.Connection
oXLDBConn.ConnectionString
"Provider=MSDASQL;" & _
"DRIVER={Microsoft Excel Driver (*.xls)};" & _
"DBQ=" & sWSheetFileSpec
oXLDBConn.Open
Set oXLRecset = New ADODB.Recordset
sSQL = "SELECT * FROM " & sRangeName
oXLRecset.Open sSQL, oXLDBConn, adOpenDynamic, adLockOptimistic
sWSheetFileSpec is the path to the spreadsheet file and sRangeName is the name given in the worksheet to the range of cells being read.
Remember, I want to do it with ADO if possible, not OLE Automation. By-the-way, can ADO connect and read from text files as well? Curently I manually create a recordset and use file I/O operations to populate it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the help guys. Please continue to provide your thoughts.
Now, I have continued to experiment with the problem and have come to some conclusions about the cause and the consequence of those causes. Let me share them with you and I hope you will comment on it so we can learn.
This is my first attempt to access Excel files with ADO, my previous experience was entirely with Access databases, and I have now concluded that ADO IS INADEQUATE FOR ACCESSING EXCEL FILES. Here is the reason.
Unlike Access, Excel does not prevent you from putting a value in a cell which is not compatible with the format of the cell. You can put string "abc" in a cell formatted for currency, and this, I have found, is the source of the problem with ADO. I found that whenever ADO encounters a value in a cell which is not compatible with the format of the cell, what ADO puts in the corresponding field of the recordset is weird. On some occasions it puts nothing (I can deal with that), but most of the time it does things like put the value from the cell above (which in my case was compatible with its format) in that field. This behavior makes it almost impossible to recognize that a problem occurred either programmatically or even by visually inspecting the result. Because of this behavior then, I have concluded that, unless you can make sure that the source Excel file does not contain a value in a cell which is not compatible with the cell format, ADO is inadequate to use on it, since the errors in the result are deceptively difficult to notice.
What do you think?
I will release the points to the most helpful comment, or if someone can outline a practical scheme to force ADO to read an Excel file in a way where the problem fields are, at least, identifiable.
By the way, formatting all the cells as “General” does not solve the problem.
Now, I have continued to experiment with the problem and have come to some conclusions about the cause and the consequence of those causes. Let me share them with you and I hope you will comment on it so we can learn.
This is my first attempt to access Excel files with ADO, my previous experience was entirely with Access databases, and I have now concluded that ADO IS INADEQUATE FOR ACCESSING EXCEL FILES. Here is the reason.
Unlike Access, Excel does not prevent you from putting a value in a cell which is not compatible with the format of the cell. You can put string "abc" in a cell formatted for currency, and this, I have found, is the source of the problem with ADO. I found that whenever ADO encounters a value in a cell which is not compatible with the format of the cell, what ADO puts in the corresponding field of the recordset is weird. On some occasions it puts nothing (I can deal with that), but most of the time it does things like put the value from the cell above (which in my case was compatible with its format) in that field. This behavior makes it almost impossible to recognize that a problem occurred either programmatically or even by visually inspecting the result. Because of this behavior then, I have concluded that, unless you can make sure that the source Excel file does not contain a value in a cell which is not compatible with the cell format, ADO is inadequate to use on it, since the errors in the result are deceptively difficult to notice.
What do you think?
I will release the points to the most helpful comment, or if someone can outline a practical scheme to force ADO to read an Excel file in a way where the problem fields are, at least, identifiable.
By the way, formatting all the cells as “General” does not solve the problem.
As you discovered, when using ADO to read Excel files, your files needs to be very clean. When I need to open and process XLS files, I mostly open the file into Excel and read values from my VB application. This way I can do every validation I need.
Hi,
This echos my comment above as to using the Excel object to access the file ...
Regards
David
This echos my comment above as to using the Excel object to access the file ...
Regards
David
This question appears to be abandoned. A question regarding it will be left in the Community Support
area; if you have any comment about the question, please leave it here.
Unless there is objection or further activity, one of the moderators will be asked to accept the comment
of <dtodd>.
The link to the Community Support area is:
https://www.experts-exchange.com/jsp/qList.jsp?ta=commspt
DO NOT ACCEPT THIS COMMENT AS AN ANSWER.
area; if you have any comment about the question, please leave it here.
Unless there is objection or further activity, one of the moderators will be asked to accept the comment
of <dtodd>.
The link to the Community Support area is:
https://www.experts-exchange.com/jsp/qList.jsp?ta=commspt
DO NOT ACCEPT THIS COMMENT AS AN ANSWER.
Thanks, emoreau for your help here.
I have finalized this question, and will monitor it for comments.
Moondancer - EE Moderator
I have finalized this question, and will monitor it for comments.
Moondancer - EE Moderator
"Provider=MSDASQL.1;Persis
Here is one I use for excel:
"Provider=MSDASQL.1;Persis