So that's basically a useless API then? I guess we should use the W version everywhere.
On Tue, Feb 9, 2016 at 12:38 AM, Jameson <vtjn...@gmail.com> wrote: > Calling the ANSI version doesn't preclude the possibility of getting UTF16 > data back. In particular, that would be code page 1200 (utf16le) or 1201 > (utf16be) for Microsoft Windows. MSDN is inconsistent in their usage of A > and whether it means ANSI, OEM, localized-locale, or application-dependent > (aka other) and generally makes no statement about how the bytes may need > to be handled or interpreted. > > > On Friday, February 5, 2016 at 1:44:20 PM UTC-5, Stefan Karpinski wrote: >> >> It does, but that's not what we're seeing – at least with some ODBC >> drivers. >> >> On Fri, Feb 5, 2016 at 1:18 PM, David Anthoff <anth...@berkeley.edu> >> wrote: >> >>> >>> https://msdn.microsoft.com/en-us/library/ms716246%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 >>> >>> >>> >>> suggests that if you call the version without the A or W suffix you get >>> the ANSI version. >>> >>> >>> >>> *From:* julia-users@googlegroups.com [mailto: >>> julia-users@googlegroups.com] *On Behalf Of *Scott Jones >>> *Sent:* Thursday, February 4, 2016 1:55 PM >>> *To:* julia-users <julia-users@googlegroups.com> >>> *Subject:* Re: [julia-users] load a Julia dataframe from Microsoft SQL >>> Server table >>> >>> >>> >>> >>> >>> On Thursday, February 4, 2016 at 4:29:46 PM UTC-5, Stefan Karpinski >>> wrote: >>> >>> On Thu, Feb 4, 2016 at 1:50 PM, Scott Jones <scott.pa...@gmail.com> >>> wrote: >>> >>> >>> >>> 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. >>> >>> >>> >>> The ODBC package calls the functions without A or W. What it's calling >>> can't be a macro since macros aren't callable via ccall. But changing ODBC >>> to call the W version of everything may be the fix here. >>> >>> >>> >>> That very well may be the solution: looking for example at libiodbc on >>> the Mac, it has 3 different versions of all those functions, and I'm not >>> sure just what behavior you get when using the form without the A or W. >>> I've always used ODBC with the C headers, unlike the direct linking that >>> Julia is doing, so that it always gets the W version since I compile as a >>> Unicode build. >>> >> >>
