Share via

Help Please - strange error message from DoCmd.TransferText

Darren 0 Reputation points
2026-04-06T17:35:25.07+00:00

I have a MS Access front end working with an SQL backend and am now getting the bellow error message when I try to do a "TransferText".

The error:

Err Number: 2391
Err Description: Field '' doesn't exist in destination table '[Moderator note: personal info removed].'

The code in question has been working for the past 3 years and runs multiple times a day....that is until this past weekend. Every line of the code works fine and I have walked through it one line at a time but the following line of code throws the above error.

Line of code:

DoCmd.TransferText acImportDelim, , "[Moderator note: personal info removed]", "[Moderator note: personal info removed].csv", 1

I have opened the CSV file in excel and have confirmed that each of the column headings are a field in the table [Moderator note: personal info removed]. I have also opened the CSV in Notepad to confirm it looks as it should.

CSV file:

[Moderator note: personal info removed]

Is anyone able to let me know what my problem might be? I would appreciate any advice that you might have to share.

Thanking you in advance for your help.

Microsoft 365 and Office | Access | For business | Windows

2 answers

Sort by: Most helpful
  1. Q&A Assist
    2026-04-06T17:35:39.04+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The error indicates that Access is treating the first field name in the CSV as  instead of the actual column name. That character sequence is the visible form of a UTF‑8 byte order mark (BOM). Access is then trying to match a field named  to a column in tblAlchemerIntakeImport, which fails.

    This typically happens when the CSV is saved with a UTF‑8 BOM and Access’s DoCmd.TransferText does not correctly ignore it for the first column name.

    To resolve it, use one of these approaches:

    1. Resave the CSV without a BOM
      • Open the CSV in a text editor that allows encoding selection (for example, Notepad).
      • Use Save As and choose an encoding that does not add a BOM (for example, ANSI or UTF‑8 without BOM, depending on the editor’s options).
      • Run DoCmd.TransferText again.
    2. Strip the BOM before import
      • Add a small pre‑processing step in the process that creates or receives the CSV to remove the BOM from the start of the file.
      • After the BOM is removed, DoCmd.TransferText acImportDelim, , "tblAlchemerIntakeImport", "C:\InfoTech\IntakeAlchemerImport.csv", 1 should work as before.
    3. Confirm field names still match
      • Ensure the first row of the CSV (after removing the BOM) contains header names that exactly match the field names in tblAlchemerIntakeImport, as Access requires exact matches when appending/importing into an existing table.

    Once the BOM is removed or the file is saved in a compatible encoding, the error 2391 for field  should no longer occur.


    References:

    1 person found this answer helpful.
    0 comments No comments

  2. Alexis-NG 14,980 Reputation points Microsoft External Staff Moderator
    2026-04-06T18:30:07.75+00:00

    Hi @Darren,

    Good day, and thank you for articulating your concern.

    That specific string of characters  is known as a Byte Order Mark (BOM).

    It is a sequence of bytes at the start of a text stream that allows the reading program to identify the file as UTF-8 encoded. While it’s helpful for some editors, MS Access’s DoCmd.TransferText often struggles with it. Because you have the HasFieldNames argument set to 1 (True), Access is reading the very first header "Response ID" but it’s seeing it as "Response ID". Since that exact column name doesn't exist in your SQL table, the import fails.

    The reason this started happening suddenly is likely that the source system changed its export settings to include the BOM, or the way the file is being saved/moved changed recently.

    You can try the following steps to resolve this issue:

    1/ Manually remove the BOM

    To confirm this is the issue, open the CSV in Notepad

    Select File > Save As.

    Look at the Encoding dropdown at the bottom.

    If it says "UTF-8 with BOM", change it to "UTF-8" (without BOM) or "ANSI".

    Save and try your import again.

    2/ Use a schema.ini file for auto removal:

    If you switch to OEM under Define text format, a file named schema.ini is created in the same directory as the file to be replicated.

    Information about the structure can be found at Schema.ini File (Text File Driver) - Open Database Connectivity (ODBC) | Microsoft Learn

    This contains among other things beside the file name of the file to be replicated also an information about the character set under CharacterSet.

    In addition to ANSI, OEM and UNICODE, the value 65001 for UTF-8 can also be entered here.

    Create a file named schema.ini in the same folder as the CSV.

    [YourFileName.csv]
    Format=Delimited(",")
    ColNameHeader=True
    CharacterSet=65001
    

    This tells Access the file is UTF‑8, column headers exist and ignore the BOM properly

    Your existing code does not need to change.

    Please remember to verify that the first row of the CSV file after the BOM has been removed contains column headers that exactly match the field names in your file, as Access requires an exact name match when importing or appending data into an existing table.

    I hope this information is helpful. If you have any questions or need further assistance, please feel free to reach out anytime.

    Thank you for your patience and understanding.


    Note: Follow the steps in this documentation to enable email notifications if you want to receive email notifications related to this topic.


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.