On Thursday, February 4, 2016 at 1:33:33 PM UTC-5, Stefan Karpinski wrote: > > Not a model of clarity (ANSI and Unicode are not encodings), but this page > seems to be the best resource on this: > > https://msdn.microsoft.com/en-us/library/ms709439(v=vs.85).aspx > > It seems that there's a parallel "Unicode" API for ODBC drivers that > support it. Moreover: > > Currently, the only Unicode encoding that ODBC supports is UCS-2, which >> uses a 16-bit integer (fixed length) to represent a character. Unicode >> allows applications to work in different languages. > > > So using Klingon is off the table. Although the design of UTF-16 is such > that sending UTF-16 to an application that expects UCS-2 will probably work > reasonably well, as long as it treats it as "just data". >
That comment is probably years (decades?) out of date. There is no limit of just UCS-2. > This still doesn't explain why some drivers are accepting UCS-2/UTF-16 > when called with the non-Unicode API. > When you do so, are you actually calling the functions with the A, or just the macro without either A or W? The macro will compile to either the A or the W form, depending on how your application is built. This is a better page in MSDN: https://msdn.microsoft.com/en-us/library/ms712612(v=vs.85).aspx describing what is going on. > >
