https://msdn.microsoft.com/en-us/library/ms716246%28v=vs.85%29.aspx?f=255 <https://msdn.microsoft.com/en-us/library/ms716246%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396> &MSPPError=-2147217396
suggests that if you call the version without the A or W suffix you get the ANSI version. From: [email protected] [mailto:[email protected]] On Behalf Of Scott Jones Sent: Thursday, February 4, 2016 1:55 PM To: julia-users <[email protected]> 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 <[email protected] <javascript:> > 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.
