I inherited a huge, bulky MS Access database and am assigned to solve a problem in it. The problem is as follow...
System A exports its data to a pipeline-delimited .txt file. The files has special characters working correctly, for example the value "Müller" shows when opening this file in notepad or Excel.
Next, the Access DB imports the .txt file and stores the result in an internal employees table. The last name field is of data type "memo". The method to import data from the .txt file to MS Access is as follow:
Call DoCmd.TransferText(acImportDelim, _
"tblEmployees", _
"tblEmployees", _
me.txtImportFile, _
True)
After running this import and viewing the employees table I noticed that names with special characters are screwed up. "Müller" becomes "M├⌐ller" for example. I investigated some online help and found out that can include a "codepage" parameter in the TransferText call, so I set it to 65001 (which appearantly is the codepage for unicode):
Call DoCmd.TransferText(acImportDelim, _
"tblEmployees", _
"tblEmployees", _
me.txtImportFile, _
True, _
, _
65001)
Now that I have ran the import script again, I see no difference whatsoever, the special characters are still misformed. I'm running out of steam so I hope one of you has some advise on how to resolve this...
Both versions of your TransferText operation are using a SpecificationName named tblEmployees. What Code Page is specified in that Specification?
Try importing the text file manually. Choose "Advanced" from the Import Text Wizard. Then select Unicode in the Code Page list box. You may need to test with different Code Page selections until you find which one imports your text correctly.
Which ever Code Page selection works, save your choices as a specification and use it in your TransferText command, without supplying a separate CodePage parameter.
Using CodePage=1200 (msoEncodingUnicodeLittleEndian) solved the issue in my case.
there is an unicode list to use in VBA:
http://msdn.microsoft.com/en-us/library/office/aa432511(v=office.12).aspx
Related
I have a pass through query built in Teradata set to export data to an Excel spreadsheet. I'm trying to automate it, but when I run the macro or open the query, a window pops up asking for the data source. I have an ODBC connection created and I'm thinking there has to be a way to make the macro pass the data source name so it will run without interaction.
Edit: Adding Macro as requested
Function AutoExec()
On Error GoTo AutoExec_Err
DoCmd.OutputTo acOutputQuery, "Performance Interval Data", "ExcelWorkbook(*.xlsx)", _
"filepath\filename.xlsx", False, "", , acExportQualityPrint
DoCmd.Quit acExit
AutoExec_Exit:
Exit Function
AutoExec_Err:
MsgBox Error$
Resume AutoExec_Exit
End Function
Couple of concerns, (can't validate any of this right now as I do not currently have access to Access for testing), but it looks like:
You're trying to OutputTo a query, to the best of my knowledge that
is not feasible.
Your file path is setup as filepath\filename.xlsx unless that is the actual location and name of your Excel sheet, something seems
wrong there to me.
I don't really think this macro relates to an ODBC of any sort in its current state.
But, you should at least start with fixing the filepath issue. That should be the full path to your Excel file and the full name of the file as well. (i.e. C:\TEMP\TestExcelSheet.xlsx)
All that being said, you may want to just go with something like this (although its a little difficult to tell if this is what you actually want or not):
'Export Excel file from Query
DoCmd.TransferSpreadsheet acExport, , "acOutputQuery", _
"C:\TEMP\TestExcelSheet.xlsx", True
NOTE: "acOutputQuery" should be the actual name of your passthrough query, "C:\TEMP\TestExcelSheet.xlsx" would be your destination path, and True adds the query's headers into the sheet, False to ignore the headers.
The following lines of code should export data from a query to a *.txt file, but results in an error.
strPath = "N:\apprais\targetDirectory\"
DoCmd.TransferText acExportDelim, "spcDataFile", "qryExportAppraisal", strPath & "DATAFILE.TXT"
Based on this https://msdn.microsoft.com/en-us/library/office/ff835958.aspx, I don't think it should be necessary to have a Schema.ini file (unless it's a fixed-width file). Also when I executed the command in an older version of the application, I was able to export the data from the query to the *.txt file without the Schema.ini file.
Ultimately, I need to know if I'm correct about the Schema.ini, and if I am, is there a default location that specification files are saved to in Access 2010? I can't seem to find where it's defined. I've looked in External Data > Saved Imports/Exports, but am not able to find anything resembling spcDataFile
I have this code that works on one spreadsheet, but not another. I am just trying to automate the transfer of an excel data range to an access table, like so
DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12, "UsysFastTrack", strFilePath, False, strRange
strFilePath and strRange are just strings that contain the full file path (including the worksheet name and extension) and the name of an excel range in the worksheet, respectively. This line causes an error
The Microsoft Access database engine could not find the object ...
This error appears a lot online and somewhere I saw the advice to try the import wizard to see what I get and lo and behold, right as I hit the last Next
This is the exact same error and it stops me dead in my tracks. What's funny is that you can see the range exists in the spreadsheet before your very eyes.
What's going on here?
Looks like the names of your named ranges are not valid, they are similar to regular ranges. Try to change names
I am trying to import a tab-delimited txt file into an Access table using VBA. In my code, I want to insert it into a table that has not yet been created.
Here is what I tried doing. Note - I was able to make this work with a CSV, and without including this: DataType:=xlDelimited, Tab:=True
Sub InsertData()
'import CSV into temp table
DoCmd.TransferText TransferType:=acLinkDelim, TableName:="tbl_TEMP", _
FileName:=FileNameVariable, HasFieldNames:=True, DataType:=xlDelimited, Tab:=True
End Sub
When I run this block, I get the following error on DataType:=xlDelimited, Tab:=True
Compile error: Named argument not found
How should I change this in order to pull in the tab-delimited txt file so each column from the txt has its own column in Access?
As you have seen from the other articles on the topic, there really isn't a generic way to import tab-delimited text files. All of the other solutions I've seen say that you should import the tab-delimited text file once, save the import specification, and then use that import specification for all subsequent imports. The problem there is that if you want to import a different tab-delimited file the specification may not match.
The only way I've found to do it generically (short of "rolling your own" code using FileSystemObject, Split(s, vbTab), etc.) is to create a completely generic specification for all 255 possible fields and use that. It requires a one-time setup as follows:
Copy the CSV data from the Pastebin here, paste it into your favorite text editor, and save it as GenericTabSpecification.csv.
Open that file in Excel, select all 256 rows and 4 columns, then hit Ctrl+C to copy.
In Access, start the import wizard for text files and choose any tab-delimited file. (We won't actually be importing it.)
When you get to the first page in the wizard, click the "Advanced..." button.
In the Import Specification dialog, verify the settings (Field Delimiter, Text Qualifier, etc.) then click the top-left corner of the Field Information grid so all rows are selected:
Hit Ctrl+V to paste the data from Excel into the grid. The grid should now contain 255 rows.
Click the "Save As..." button and name the specification GenericTabSpecification. Once that is done, cancel out of the wizard.
Now we can do a generic import from VBA using a statement like this
DoCmd.TransferText _
TransferType:=acImportDelim, _
SpecificationName:="GenericTabSpecification", _
TableName:="newTable", _
FileName:="C:\Users\Gord\Desktop\foo.txt", _
HasFieldNames:=False
I created a test MS Access DB to export a table to Excel and a text file.
This works for Excel:
DoCmd.OutputTo acOutputQuery, "QryExportToExcel", _
acFormatXLS, XFile, False
For the text file, I created a specification and used this code
DoCmd.TransferText acExportDelim, "Mytable Import Specification", "mytable", "D:\myfolder\test1.txt", False
In the error message, I get "test1#txt".
The Microsoft Office Access database engine could not find the object
"test1#txt". Make sure the object exists and that you spell its name
and the path name correctly.
I tried creating test1.txt in the same path. To my surprise, this deleted the file which is already present.
Software: MS ACCESS 2007
The Microsoft Office Access databasse engine could not find the object "test1#txt". Make sure the object exists and that you spell its name and path name correctly.
This is a generic (and rather useless) error message that Access outputs in case anything goes wrong. One example would be a misspelled field name in the import/export specification.
You can get the "real" error message by trying the import operation "manually" in the Access user interface (rather than through code).
The question author reported the problem was "because I was using an Import Specification for Exporting a file."
They resolved the problem by using an Export Specification.
Because you are doing DoCmd.TransferText, Access is expecting that the file Test1.txt exists in that location. Try creating the file first, and then do a transfer of the text.
You can try this code before the export to create the file:
Public Sub CreateExportFile()
Dim strFileName As String
Dim SomeStringToOutput
strFileName = "d:\myfolder\test1.txt"
Open strFileName For Output As #1
End Sub
I was having a similar situation and found that a file schema.ini was in the destination folder. This was created when an acExportMerge was performed previously and it caused this error. Make sure that file has been deleted prior to executing a new TransferText.