Related
I'm currently using a code to update a file with a loop running through multiple sheets. Up until now, the code ran smoothly. On today's run, I encountered "run-time error '-2147319767 (80028029)' Automation error, Invalid forward reference, or reference to uncompiled type."
The error occurs on the line Workbooks("Upload.xlsm").Worksheets(branchName).Range("C7").PasteSpecial Paste:=xlPasteValues and presents itself on the 6th iteration of the loop.
I used On Error Resume Next as a temporary measure to complete the run as it was imperative to have it done at that time.
Upon completion, 3 of the iterations had failed (sixth, seventh and tenth). The three had no correlation to one another (i.e. different copy sources, values, etc) but had other iterations with the exact same copy source/values which completed successfully.
Running another copy command at a later time onto these sheets resulted in the same error. I eventually had to delete and recreate the sheet to resolve the error.
' Uploads file update
fpath = Workbooks("TEG Rates.xlsm").Worksheets("Link List").Range("E3").Value
Workbooks.Open fpath & "Upload.xlsm"
For branchNo = 21 To 37
branchName = Workbooks("TEG Rates.xlsm").Worksheets("Link List").Range("A" & branchNo).Value
branchGroup = Workbooks("TEG Rates.xlsm").Worksheets("Link List").Range("B" & branchNo).Value
' Copy/Paste Buy & Sell
Workbooks("TEG Rates.xlsm").Worksheets(branchGroup).Range("D7:G111").Copy
Workbooks("Upload.xlsm").Worksheets(branchName).Range("C7").PasteSpecial Paste:=xlPasteValues
For no = 7 To 10
Workbooks("Upload.xlsm").Worksheets(branchName).Range("D" & no).Value = "=ROUND(100/C" & no & ",6)"
Next no
Workbooks("Upload.xlsm").Worksheets(branchName).Range("D14").Value = "=ROUND(100/C14,6)"
Workbooks("Upload.xlsm").Worksheets(branchName).Range("D15").Value = "=ROUND(10000/C15,4)"
Workbooks("Upload.xlsm").Worksheets(branchName).Range("D16").Value = "=ROUND(100/C16,6)"
Workbooks("Upload.xlsm").Worksheets(branchName).Range("D19").Value = "=ROUND(100/C19,6)"
Next branchNo
Workbooks("Upload.xlsm").Close SaveChanges:=True
Application.CutCopyMode = False
While currently I am able to operate this code, my concern is that my team will encounter this whilst I'm away. What could have caused this/what can I do to prevent this from occurring? I'd be willing to provide the files if required.
My friend and I had the same issue. I enabled the "AccessibilitycplAdmin 1.0 type admin" under Tools > References (within the VBA editor), that fixed the issue in both computers
I had the same issue with a macro today.
Noticed that the error popped up when selecting a sheet using Sheets(sheet_name_var).Select.
A workaround that I've found is:
- Make a copy of the sheet the macro was having problems with,
- Delete the original sheet,
- Rename the copy to the original name.
Hope this helps.
I was having the same error caused by an issue that was potentially related, and it was helpful to create a worksheet object rather than referencing a sheet within a workbook all in one step. So, instead of:
Workbooks("Upload.xlsm").Worksheets(branchName).Range("C7").PasteSpecial
You could instead try:
Dim xlWB as Excel.Workbook
Dim xlWS as Excel.Worksheet
Dim xlRange as Excel.Range
Set xlWB = Workbooks("Upload.xlsm")
Set xlWS = xlWB.Worksheets(branchname)
Set xlRange = xlWS.Range("C7")
xlRange.PasteSpecial Paste:=xlPasteValues
Sometimes it's beneficial to break up the steps, even though it is doing the same thing.
The only way I found to solve it was:
Change the property "Load To" for all query results in the damaged Sheet to "Only Create Connection".
Make a copy of the Sheet
Delete the damaged Sheet
Rename the just created Sheet to the name of the damaged one
Change all the query results to the new Sheet in the same original location
I hope this helps.
I had a very similar issue, I have several similar excel files, all with the same code. The code ran in all excels but one, with the same error:
"run-time error '-2147319767 (80028029)' Automation error, Invalid forward reference, or reference to uncompiled type."
I was able to solve the problem by saving the corrupt excel as .xlsx instead of .xlsm, closing all excel applications, reopen the .xlsx, add the code and save as .xlsm. Now it is working...
Exactly same thing happened to me. But with a little bit more serious consequences as my dashboard was already in production.
It was really shocking as code as running smoothly just 5 mins earlier.
Here's the changes that I made -
Conditional formatting
Pivot table updates - major formatting updates
I believe some weird combination of conditional formatting over pivot table might have caused this issue.
One peculiar symptom associated with this corrupted workbook/sheet as that I was unable to see any macro in the dialogue while I was trying to assign a macro to the button.
The dialogue box was empty ! not listing any macros from any module/form/worksheet.
Tried -
Removing pivot table
Resetting formatting
Removing conditional formatting
Restarting excel
Restarting system
None of the above worked !
Next solution, as suggested by Horacio, is to duplicate and delete the corrupted sheet.
This immediately solved the issue.
Similar problem - same error. The sheet is the results of a query "Load To" table. Followed the idea from https://stackoverflow.com/users/13737858/horacio-cano. Changed "Load to" from table to Connection only; deleted the sheet; changed "Load to" to new table; refreshed query. Macro runs without error.
I solved this by removing the reference to Microsoft Scripting Runtime in Tools>References selecting "Ok" and then re-adding it again.
(Not the exactly the same situation as posted by the OP, but the same error message:)
I got the same error message while trying to delete an ActiveX element in a UserForm.
Turns out that I still had (another) user form open as a modal window in the Excel app (which was in the background because I was trying to edit it the Visual Basic Editor).
Simply closing the user form solved the issue.
Not really an answer, but my 2 cents on the matter (a comment could not fit it :))
I found that the underlaying error comes from .NET:
Exception Source: mscorlib
Exception Type: System.Runtime.InteropServices.COMException
Exception Message: Invalid forward reference, or reference to uncompiled type. (Exception from HRESULT: 0x80028029 (TYPE_E_INVALIDSTATE))
Exception Target Site: InvokeDispMethod
With that, I found that this page:
https://developercommunity.visualstudio.com/t/live-code-analysis-causes-compiler-errors-in-code/599442
System.Runtime.InteropServices.COMException : A reference to the component 'MyProjectReference' already exists in the project.
at VSLangProj.References.AddProject(Project pProject)
So it appears the error is linked to some cached file(s) used internally and language stuff.
Now if you look here : What does 'Cor' stand for?
MSCorLib.dll officially became the acronym for Multilanguage Standard
Common Object Runtime Library.
If you finally add in the mix that I was manupulating files in Excel while changing the UI Language in settings just before I got a corrupted file with the same error that the OP mentions, I would guess the error definitely has some thing to do it!...
I'm building an Excel-based tool that has to be both Windows and Mac compatible. This tool needs to pull data from and push data to a SQL Server. I've written and tested a way to do this that works in Windows and should work in Mac as described here (though that link pertains to Excel 2011):
On Error GoTo err1
Dim connstring As String
Dim sqlstring As String
Dim dArr As Variant
Dim qt As QueryTable
Dim sht As Worksheet
Set sht = ThisWorkbook.Sheets(1)
connstring = "ODBC;DRIVER={SQL Server};SERVER=SERVERNAME;DATABASE=master;Trusted_Connection=yes"
sqlstring = "SELECT 1"
Set qt = sht.QueryTables.Add(Connection:=connstring, Destination:=sht.Range("A1"), Sql:=sqlstring)
With qt
.BackgroundQuery = False
.RowNumbers = False
.Refresh
End With
This approach doesn't work in Excel 2016 for Mac. In fact, when I record the process of adding a connection on a Mac, the QueryTables.Add method doesn't even show a Connection or SQL argument...
Instead of creating the tables programmatically, I thought a workaround could be to manually create the tables and then change the CommandText for the tables programmatically as needed (for different parameters, etc.). But when I try to access the CommandText property of the QueryTable object, the Mac VBEditor tells me that it can't find the member!
Has anyone successfully created ODBC QueryTables programmatically in Excel 2016 for Mac or is this another shortfall of Excel 2016?
I was going crazy trying to find a workaround for this when I came across your question, wishing someone had answered it. I just discovered a work-around today. My problem seems similar to yours so maybe my solution will help you out:
I was unable to use QueryTables.Add or CommandText in VBA, but I was able to create the tables manually and then use data from the excel sheet as a parameter.
I created the ODBC connection manually by clicking New Database Query>From Database, which you probably know how to do. I entered my SQL into the Microsoft Query window as such:
SELECT DISTINCT WIN
FROM RETAIL.OFFER
WHERE WIN LIKE 'XS%'
AND WIN NOT LIKE 'XS92500'
AND WIN NOT LIKE 'XS%a'
AND TITLE = 'The Binge'
I'm new to SQL so it may not be pretty but it worked. However, I needed the title to be a parameter that came from a cell in the spreadsheet instead of having to go in and manually update the SQL each time. I was able to do this by going into Connections>Properties>Definition>Edit Query and changing the SQL to this:
SELECT DISTINCT WIN
FROM RETAIL.OFFER
WHERE WIN LIKE 'XS%'
AND WIN NOT LIKE 'XS92500'
AND WIN NOT LIKE 'XS%a'
AND TITLE = ?
Note: It only worked when I actually pressed the Edit Query button, it changed all the ' to curvy apostrophes if I edited it in the Definition window.
Excel then prompted me to select a parameter to replace the ? in the SQL. You can select a cell in the spreadsheet or enter any other string for the parameter. You can also go back into connections and edit the parameters if needed.
Now, I just use a VBA macro to refresh all connections and pass the data from the cells into the query. This works in my use case, sorry if you already knew about making parameters in this way and you need to use VBA. I couldn't get my VBA to work on my mac either, even though it worked perfectly on my PC. Hopefully this will be helpful to someone out there!
I have been battling with this issue for a couple of days and read a lot of posts about renaming connections and still cannot achieve what I need to.
Essentially I have a workbook that has multiple sheets each with a different pivot table using a different connection.
I need to use VBA to insert date range criteria from a "Control" tab into the sql statement of each connection because as we all know pivots can't use the ? parameter.
However, as we also know, Excel renames the connection when you modify it, so changing the command text with VBA ends up creating new connections and leaving redundant ones.
Using some other very useful posts in this forum I have successfully managed to
- change the command text
- delete the old connection and rename the new one assuming its name to be "Connection"
thus:
text = "... new SQL query here..."
ActiveWorkbook.Connections("GLCosts").ODBCConnection.CommandText = text
' assume excel has renamed the "GLCosts" connection to "Connection"
ActiveWorkbook.Connections("Connection").Refresh
' delete the original and rename the new one to the old name
ActiveWorkbook.Connections("GLCosts").Delete
ActiveWorkbook.Connections("Connection").name = "GLCosts"
As long as each Sub() does this in turn then it should be fine as the "new" connection name will always be "Connection" (i.e. not "Connection1" etc)
HOWEVER
What I have found is that Excel only renames the connection IF THERE IS A CHANGE TO THE COMMAND.TEXT
Therefore, if the user doesn't actually change the date criteria values (held in Sheets("Control").Range("D4")) but DOES run the macro to refresh the pivots then the macro fails because the command text hasn't been modified, and there's no new connection string to rename as the old name.
So....
I tried to be clever. In each Sub() I first set text = "... a valid sql query but not the one i want...", then replace the command.text of the connection with this dummy query thus forcing excel to create a new connection which I can rename. Then when i set text = "...the correct sql query" excel will again create a new connection called "Connection" and I can repeat the renaming and deleting steps.
This should have been fine but for some reason it just crashed excel and I haven't tried it again
Does anyone have an actual solution to this? Should I try the clever stuff bit again?
Any ideas gratefully received
I have also encountered this bug when updating the CommandText property of an ODBC connection. I found that if you temporarily switch to an OLEDB connection, update your CommandText property and then switch back to ODBC it does not create the new connection. Don't ask me why... this just works for me.
Create a new module and insert the following code:
Option Explicit
Sub UpdateWorkbookConnection(WorkbookConnectionObject As WorkbookConnection, Optional ByVal CommandText As String = "", Optional ByVal ConnectionString As String = "")
With WorkbookConnectionObject
If .Type = xlConnectionTypeODBC Then
If CommandText = "" Then CommandText = .ODBCConnection.CommandText
If ConnectionString = "" Then ConnectionString = .ODBCConnection.Connection
.ODBCConnection.Connection = Replace(.ODBCConnection.Connection, "ODBC;", "OLEDB;", 1, 1, vbTextCompare)
ElseIf .Type = xlConnectionTypeOLEDB Then
If CommandText = "" Then CommandText = .OLEDBConnection.CommandText
If ConnectionString = "" Then ConnectionString = .OLEDBConnection.Connection
Else
MsgBox "Invalid connection object sent to UpdateWorkbookConnection function!", vbCritical, "Update Error"
Exit Sub
End If
If StrComp(.OLEDBConnection.CommandText, CommandText, vbTextCompare) <> 0 Then
.OLEDBConnection.CommandText = CommandText
End If
If StrComp(.OLEDBConnection.Connection, ConnectionString, vbTextCompare) <> 0 Then
.OLEDBConnection.Connection = ConnectionString
End If
.Refresh
End With
End Sub
This UpdateWorkbookConnection subroutine only works on updating OLEDB or ODBC connections. The connection does not necessarily have to be linked to a pivot table. It also fixes another problem and allows you to update the connection even if there are multiple pivot tables based on the same connection.
To initiate the update just call the function with the connection object and command text parameters like this:
UpdateWorkbookConnection ActiveWorkbook.Connections("Connection"), "exec sp_MyAwesomeProcedure"
You can optionally update the connection string as well.
Here's what I do, which doesn't rely on hard-coded references, to manage the annoying process of programmatically updating the pivotCache in Excel.
First, before you have VBA alter your existing Pivot Cache/Connections, declare a string variable (currentPvtConn) in your code and set value to the current Pivot Cache name for the Pivot you intend to refresh. Also, delcare a second string variable (newPvtConn) to hold the name of the new connection Excel will undoubtedly generate...
Dim currentPvtConn As String
Dim newPvtConn As String
currentPvtConn = ActiveSheet.PivotTables("pvtUser").PivotCache.WorkbookConnection
...Now place your code to modify the CommandText...
After the refresh commands execute, Excel will create that dastardly new connection named "Connection#" and you'll be left with the old, untouched one as well. To clean up this mess, we'll need to capture the newly created connection name and store in the newPvtConnection variable we created earlier...
newPvtConn = ActiveSheet.PivotTables("pvtUser").PivotCache.WorkbookConnection
Since you now have both names stored as local variables, you can actually comare the two strings and
Finally, delete the orignal connection and rename the newly-created one. IF statement ensures a new connection was acually created before deleting/renaming anything.
If (StrComp(currentPvtConn, newPvtConn) <> 0) Then
ActiveWorkbook.Connections(currentPvtConn).Delete
ActiveWorkbook.Connections(newPvtConn).Name = "[My Original Connection Name]"
End If
... put rest of code
I'm exactly not sure why yours is crashing. I did find an obscure reference/solution to a problem where the following occurs:
Create Excel file with parameterized queries that load directly to Pivot Cache (i.e. using parameters in the command text "?")
Save beatufully-crafted file and close
Re-open and try to refresh
Excel crashes hard and closes; no chance of "repairing"
/***
Apparently, parameters aren't supported in Pivots. The problem lies in the parameter cells in a spreadsheet. Actually, when you close the file, query "forgets" what the parameter cells are, and uses blanks instead. That is why Excel crashes. I guess this is caused by the fact that pivot tables "can not be used" against parameter queries. However... Here is my workaround: no additional table necessary - only pivot table.
Create common query first (no parameters.)
Create pivot table based on query results.
Change query to parameter query.
Before refreshing data in Excel do not select cell values as parameters.
Instead, use prompt: Connection Properties=> Parameters=> "Prompt for value using following string:".
So, when you click "Refresh" on your pivot table, you will be prompted to enter parameters.
I know it is not as elegant as referring to a cell, but in this way Excel will not crash. Besides, you will not have to refresh both result and pivot table, but only pivot table.
Source MSDN: (bottom-of-page comment)
***/
I have also encountered this problem. I know the thread is old but I thought I'd share a workaround anyway.
I am using Excel 2013 (although it may also work in earlier versions), and discovered that when changing the ODBCconnection.commandtext in VBA I get the same effect, where a new connection called 'Connection' is created with the old command text and is linked to the pivot table. But the original connection has the new command text however it's not connected to the pivot any more.
If the connection you want to change in VBA is linked to an excel table rather than a pivot table, I found that the new 'connection' is not created, and instead the original connection is changed by the code yet remains linked to the table.
So I created a connection linked to an excel table on a hidden worksheet, then used this table as the source of the pivot table.
I hope this helps someone, as I was scratching my head over this for days.
I'm debugging some code and need to find out where a
DoCmd.TransferSpreadsheet acImport, , ".....
fails so I've decided to import it 'manually' line-by-line to see where it falls over.
I suppose something like this is what I'm looking for:
mySpreadSheet = ConnectTo(Spreadsheet.xlsx)
while(!mySpreadSheet.EOF)
get(mySpreadSheet.nextLine)
SQL("UPDATE MyTable with mySpreadSheet.nextLine")
I've tried Googling to no avail. Any help is much appreciated!
Additional info:
The column names of the spreadsheet and the Access table are identical.
Every data type is nvarchar(MAX) (Or "Memo" as Access calls it)
The table is a linked table to SQL Server 2008
ADO works well if you have a well defined sheet layout of your data (HansUp answer). If you need added control before loading the objects, you can hook into the excel workbook, and then pull out whatever data you like. It really depends on the level of control you need.
Public Sub LoadExcelToAccess(xlPath As String)
'uses late binding to open excel workbook and open it line by line
'make reference to Microsoft Excel xx.x Object Model to use native functions, requires early binding however
Dim xlApp As Object 'Excel.Application
Dim xlWrk As Object 'Excel.Workbook
Dim xlSheet As Object 'Excel.Worksheet
Dim i As Long
Dim sql As String
Set xlApp = VBA.CreateObject("Excel.Application")
'toggle visibility for debugging
xlApp.Visible = False
Set xlWrk = xlApp.Workbooks.Open(xlPath)
Set xlSheet = xlWrk.Sheets("Sheet1") 'modify to your perticular sheet
'depends on what your trying to do with the sheet
For i = 1 To 10
'quick and dirty: best to load items into custom class collection, then do processing there
sql = "Insert Into [Temp] (Col1) VALUES (" & xlSheet.Cells(i, 1).Value & ")"
DoCmd.RunSQL sql
Next i
'make sure to dispose of objects
xlWrk.Close
xlApp.Quit
Set xlSheet = Nothing
Set xlWrk = Nothing
Set xlApp = Nothing
End Sub
You can create an ADO connection to your spreadsheet (see Connection strings for Excel 2007), then open an ADO recordset with that connection (see StackOverflow: ADODB recordset in VBA says excel field is empty when it's not for example).
Then move through the recordset rows, and create a SQL INSERT statement using the row's values.
strInsert = "INSERT INTO MyTable (first_field, second_field) VALUES ('" & -
rs2.Field(0).Value & "', '" & rs2.Field(1).Value & "');"
Debug.Print strInsert
CurrentDb.Execute strInsert, dbFailonerror
That code snipped assumes first_field and second_field are text data types. If they are numeric, lose the single quotes.
I think that does roughly what you asked. However, before resorting to code I would check whether the spreadsheet imports cleanly into a new native Access table. (Also, check whether the data types and constraints on that new table are compatible with those of the linked SQL Server table.) If that works, maybe try importing the spreadsheet directly into SQL Server from the Management Studio, or whatever tool is appropriate.
For troubleshooting purposes, try linking to the spreadsheet and see what problems you encounter, including data displaying wrong when you view it in datasheet view.
You can also try just copying your Excel data to the clipboard and pasting it into your Access table. Whatever fails will get written into a 'Paste Errors' table by Access.
Two additional options:
Link the spreadsheet in Access like a table. In Access 2007, go to "external data" pane and select "Import Excel Spreadsheet". You should import to an existing datatable, a new datatable or just link to Excel file. Then, you would work with this new "Excel" table like an Access table (regarded the performance issues, in last case).
Try to fix the Docmd.TransferSpreadsheet problem. I've been using this method for some years, and it works fine, despite it ought to be a little tricky in some cases (I belive its your case). Please, its worthy if you give more information about your problem with this method, including your Access and Excel version.
I hope I've helped. Good luck.
Is there any way to change the default datatype when importing an Excel file into Access? (I'm using Access 2003, by the way).
I know that I sometimes have the freedom to assign any datatype to each column that is being imported, but that could only be when I'm importing non-Excel files.
EDIT: To be clear, I understand that there is a step in the import process where you are allowed to change the datatype of the imported column.
In fact, that's what I'm asking about. For some reason - maybe it's always Excel files, maybe there's something else - I am sometimes not allowed to change the datatype: the dropdown box is grayed out and I just have to live with whatever datatype Access assumes is correct.
For example, I just tried importing a large-ish Excel file (12000+ rows, ~200 columns) in Access where column #105 (or something similar) was filled with mostly numbers (codes: 1=foo, 2=bar, etc), though there are a handful of alpha codes in there too (A=boo, B=far, etc). Access assumed it was a Number datatype (even after I changed the Format value in the Excel file itself) and so gave me errors on those alpha codes. If I had been allowed to change the datatype on import, it would have saved me some trouble.
Am I asking for something that Access just won't do, or am I missing something? Thanks.
EDIT: There are two answers below that give useful advice. Saving the Excel file as a CSV and then importing that works well and is straightforward like Chris OC says. The advice for saving an import specification is very helpful too. However, I chose the registry setting answer by DK as the "Accepted Answer". I liked it as an answer because it's a one-time-only step that can be used to solve my major problem (having Access incorrectly assign a datatype). In short, this solution doesn't allow me to change the datatype myself, but it makes Access accurately guess the datatype so that there are fewer issues.
There are a couple of ways to do this. The most straightforward way is to convert the .xls file to a .csv file in Excel, so you can import into Access using the Import Text Wizard, which allows you to choose the data types of every column during the import.
The other benefit to doing this is that the import of a csv (or text) file is so much faster than the import of an xls file. If you're going to do this import more than once, save the import setup settings as an import specification. (When in the Import Text Wizard, click on the "Advanced..." button on the bottom left, then click on "Save As" and give a specification name to save the changes you just made.)
This may be caused by Excel Jet driver default settings. Check out the following registry key and change it's value from default 8 to 0, meaning "guess column data type based on all values, not just first 8 rows."
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel]
"TypeGuessRows"=dword:00000000
Please, tell if this works.
open your excel file. In Home tab change format from General to Text. then import into access
Access can do what you need, but there is no straightforward way for that. You'd have to manage some recordsets, one being your Excel data, the other one being your final Access table. Once both recordsets are open, you can transfer data from one recordset to the other by browsing your Excel data and adding it to your Access table. At this stage, it will be possible to change datatype as requested.
When importing from CSV files you can also have a look at schema.ini you will find that with this you can control every aspect of the import process.
Access will let you specify the datatype at the import process. the problem is at the "Append" process for the following times, it will not ask about the import to datatype, and it will forget you changed it. I think it is a bug in MS Access.
This is an old post but the issue persists! I agree with Deepak. To continue that thought:
Access determines the field types when linking to or importing Excel files based on the field types in Excel. If they are all default, it looks at the first X rows of data. A few ways to fix this:
Open the Excel file and add about 6 rows (under the field headers if any) that emulate the type you want. If you prefer all text, enter 'abcdef' in each cell of those first six rows.
Open the Excel file, highlight all cells, right click, and change format to 'Text' or whatever format you like. Save, then link/import into Access.
Use a macro (VBA script) to do step 2 for you each time:
Public Function fcn_ChangeExcelFormat()
On Error GoTo ErrorExit
Dim strExcelFile As String
Dim XL_App As Excel.Application
Dim XL_WB As Excel.Workbook
Dim XL_WS As Excel.Worksheet
strExcelFile = "C:\My Files\MyExcelFile.xlsx"
Set XL_App = New Excel.Application
Set XL_WB = XL_App.Workbooks.Open(strExcelFile, , False)
Set XL_WS = XL_WB.Sheets(1) ' 1 can be changed to "Your Worksheet Name"
With XL_WS
.Cells.NumberFormat = "#" 'Equiv to Right Click...Format Cells...Text
End With
XL_WB.Close True
XL_App.Quit
NormalExit:
Set XL_WB = Nothing
Set XL_App = Nothing
Exit Function
ErrorExit:
strMsg = "There was an error updating the Excel file! " & vbCr & vbCr & _
"Error " & Err.Number & ": " & Err.Description
MsgBox strMsg, vbExclamation, "Error"
Resume NormalExit
End Function
Access will do this.
In your import process you can define what the data type of each column is.