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 <[email protected]> 
> 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:* [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]> 
>> 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. 
>>
>
>

Reply via email to