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. >
