Ten eerste moet ik zeggen dat ik geen MySQL gebruik, maar ik weet wel van ODBC-stuurprogramma's. In ODBC zijn er verschillende API's voor unicode en ansi. De ansi-API's eindigen op A en de unicode-API's eindigen op W (bijvoorbeeld SQLPrepareA en SQLPrepareW). De ansi-API's accepteren bytes/octetten voor tekenreeksen en kunnen daarom alleen chrs 0-255 aan. De unicode-API's accepteren SQLWCHAR's die 2 byte UCS-2-gecodeerde unicode-codepunten zijn (nieuwere MS SQL Server-versies kunnen UTF16-gecodeerde tekenreeksen aan) en kunnen dus ongeveer de eerste 65000 codepunten in unicode aan.
Dus als u Unicode-gegevens moet opslaan, heeft u geen keuze welk stuurprogramma u wilt gebruiken.
Ik zou me niet laten afschrikken door de opmerkingen over snelheid van Carnangel om de unicode-driver te gebruiken en zijn opmerkingen bevatten in ieder geval geen feiten. Hij verwijst misschien naar:
Als u unicode-gegevens opslaat in MySQL, wordt deze UTF-8-gecodeerd en via uw netwerk als UTF-8 overgedragen. Aan de clientzijde zal het ODBC-stuurprogramma de UTF-8-gecodeerde gegevens naar UCS-2 moeten converteren, aangezien dit is wat ODBC nodig heeft. Uiteraard geldt het omgekeerde.
Als u een ANSI ODBC-toepassing schrijft (die de ansi ODBC-apis gebruikt) met een unicode ODBC-stuurprogramma, dan zal de ODBC-stuurprogrammamanager de UCS-2 moeten converteren, het stuurprogramma keert terug naar 8 bit (lossy) en converteert de 8 bit gegevens die u aan de bestuurder doorgeeft aan UCS-2. Doe dat dus niet.
Tegenwoordig zou het me verbazen als iemand nog steeds ANSI ODBC-stuurprogramma's gebruikt.