MariaDB 10.1.16, Charset uft8, Access 2010/2016, DAO 3.6, VBA

Thank you for your report!
Could you please elaborate a little bit on how to repeat the problem?
It's ok to do that in German

Thank you for you detailed description.

Would it be possible to also provide ODBC trace for that function execution?
Also, do you set a charset in your DSN?
Thanks!

It does not depend, whether I set a charset or not.
[^ODBC.pdf] i Stopped logging just after the bug.

Thanks once again - that helps.

Would be possible also to see definition of the table `adressen`(SELECT *
FROM adressen WHERE TS > '2017-02-28 14:41:41)?

Doesn't it have 'binary' or 'collate utf8_bin' for varchar fields/table? The thing is, that DAO request all fields as SQL_C_BINARY, and it does so because SQLDescribeCol returned SQL_VARBINARY for seemingly all varchar fields.
That would be possible if the server reported those fields as binary.
This causes, that our ODBC connector returns all values as they are in the table. SInce you said all data is utf8, you get all those values as utf8, and not as utf16, that uses ODBC for Unicode encoding, and that DAO expects to get as Unicode data.
And I've seen in the trace, that for some other fields in other queries, type reported as SQL_WCHAR, and DAO requests those fields data as SQL_WCHAR.
So, I expect there is no bug here in our connector. But let's wait to see the table structure.

Thank you for your analysis.
Please see tbl_adressen.pdf.

So, they were utf8_bin? And you've altered the table and removed utf8_bin? jpg is "before" and pdf is "after"? Did that help?

If did not, please provide "show create table adressen" result, so I could test what is wrong with the table.
Otherwise I am closing the issue.

I haven´t altered the tables. Here the create statement:

CREATE TABLE `adressen` (
`NUMMER` smallint(6) NOT NULL,
`VORNAME` varchar(40) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`ZUNAME` varchar(40) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`VOLLMACHT` varchar(40) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`STRASSE` varchar(35) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`PLZ` varchar(7) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`ORT` varchar(25) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`BANK` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL COMMENT 'Land',
`TELEFON` varchar(60) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`EMAIL` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`UID` varchar(20) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`USER` varchar(20) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`TS` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`NUMMER`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;
/*!40101 SET character_set_client = @saved_cs_client */;

I am not sure there is a bug here. Server reports binary flag for fields, thus connector report to dao that fields are binary, dao fetches values as binary.
On other hand, if someone chooses utf8_bin collation for his/her utf8 field, unlikely he/she expects it to be treated as a binary field. And maybe connector should not trust server, and check some other conditions, to establish the fact whether the field is binary or not. I will think some more on this.

Does that table have utf8_bin collation intentionally? To change to other collation would be one work-around for your problem. Other work-around to view those fields correctly, probably, would be to use convert/cast functions for those fields.

The fix has been pushed (to 2.0 branch) as rev. b0e0d7c2a489dd4436256a7f8bb644f6641fa8ad

I've decided that is a bug And fixed. If you care to verify it - I have attached the dll with it. That is not any official release, and good only for testing/verification.
And thanks once again - you were really helpful!