Access has no problem with these symbols when they are entered into an Access table, just in .csv files. I can convert the csv to Excel, and Access can read them but 1) Excel ruins the zip codes and 2) I don't want my end users to have to spend the time converting a bunch of .csv files every two weeks.

I am sure there are several ways you can do it. How do you create your csv file.....do you create the csv file by executing the transferText import commands from Access? If so, one way you can do it is to pass utf-8 for the charSet argment of the transferText method. Another way is to identify utf-8 in an import spec.

The csv is created from a mysql database. This database is in UTF-8 format from what I can tell. Our web programmers set up some code (probably in php) on our site that we click on that creates the csv file for us. I'll check into using and actually import spec in Access, I usually just use the import wizard or link to the csv files.

If you set up an import specification, you need to use it in the TransferText command.

To build a specification:
from the Table Tab in the Database window, right click, Link Table, select CSV, find the file, OK

An importing wizard is launched. In the bottom left is a button 'Advanced' - select this (this is where you identify utf-8)

A new dialog opens, which is pretty self explanatory - you can select columns, data types etc, then save as a specification. Take a note of the specification - lets say this is called "ABC Link Specification".

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

1)There is nothing that I can see in the table properties where I can tell it to have unicode properties. I do know if you type into any of the tables, including this one, it accepts the " characters.
2) I didn't have to type it, Unicode UTF-8 was an option in a drop down box, both on the import specification, and in creating a macro for the transfer text command. I think it's safe to assume that if I wrote the VBA code that did the same thing as the macro, the same thing would happen--It eliminates these characters now, instead of replacing them with garbage characters.

If you have any other suggestions, I'd be happy to try, although I might not be able to until the begining of next week.

Are you executing your macro from ms access as an import.? It would be helpful if you posted it here so that I can see it. If you place your ms access table in design view, the last field property is the unicode setting. Check that again. In the meantime, I will see if I can find any additional info about the problem you are having.

From my research , I am finding out that most of the unicode problems result from incorrect unicode encoding in the source csv file created by the sql server. This incorrect encoding is encoding that does not meet the iso standard, and makes it impossible for Access to decode even if utf-8 s used for decoding.

So, my advice is to review the encoding in the csv source file and see if you can determine how the encoding needs to be changed so that it meets the iso standard, and be "understood" by utf-8.

I found that if I went right into mysql and exported the file directly, then imported it using utf-8, it worked. So you were right on both accounts, it needed to be imported as utf-8 AND something is up with the way the file is create.

Today's users almost expect this to happen in all search boxes. After all, if their favourite search engine juggles with tens of thousand keywords while they type, and suggests matching phrases on the fly, why shouldn't they expect the same from you…

Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…