Still having local issue in msodbcsql17

[YoEight]

Greetings,

I still experiencing the issue mentioned #18.

I used the last driver version:

~ ❯❯❯ brew info msodbcsql17
microsoft/mssql-release/msodbcsql17: stable 17.2.0.1
ODBC Driver for Microsoft(R) SQL Server(R)
https://msdn.microsoft.com/en-us/library/mt654048(v=sql.1).aspx
/usr/local/Cellar/msodbcsql17/17.1.0.1 (9 files, 2.7MB)
  Built from source on 2018-06-28 at 17:36:17
/usr/local/Cellar/msodbcsql17/17.2.0.1 (9 files, 2.7MB) *
  Built from source on 2018-09-20 at 10:32:21
From: https://github.com/Microsoft/homebrew-mssql-release/blob/master/Formula/msodbcsql17.rb
==> Dependencies
Required: unixodbc ✔, openssl ✔
==> Options
--without-registration
        Don't register the driver in odbcinst.ini
==> Caveats
If you installed this formula with the registration option (default), you'll
need to manually remove [ODBC Driver 17 for SQL Server] section from
odbcinst.ini after the formula is uninstalled. This can be done by executing
the following command:
    odbcinst -u -d -n "ODBC Driver 17 for SQL Server"

I got the infamous error:

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: collate_byname<char>::collate_byname failed to construct for UTF-8

locale -a

en_NZ
nl_NL.UTF-8
pt_BR.UTF-8
fr_CH.ISO8859-15
eu_ES.ISO8859-15
en_US.US-ASCII
af_ZA
bg_BG
cs_CZ.UTF-8
fi_FI
zh_CN.UTF-8
eu_ES
sk_SK.ISO8859-2
nl_BE
fr_BE
sk_SK
en_US.UTF-8
en_NZ.ISO8859-1
de_CH
sk_SK.UTF-8
de_DE.UTF-8
am_ET.UTF-8
zh_HK
be_BY.UTF-8
uk_UA
pt_PT.ISO8859-1
en_AU.US-ASCII
kk_KZ.PT154
en_US
nl_BE.ISO8859-15
de_AT.ISO8859-1
hr_HR.ISO8859-2
fr_FR.ISO8859-1
af_ZA.UTF-8
am_ET
fi_FI.ISO8859-1
ro_RO.UTF-8
af_ZA.ISO8859-15
en_NZ.UTF-8
fi_FI.UTF-8
hr_HR.UTF-8
da_DK.UTF-8
ca_ES.ISO8859-1
en_AU.ISO8859-15
ro_RO.ISO8859-2
de_AT.UTF-8
pt_PT.ISO8859-15
sv_SE
fr_CA.ISO8859-1
fr_BE.ISO8859-1
en_US.ISO8859-15
it_CH.ISO8859-1
en_NZ.ISO8859-15
en_AU.UTF-8
de_AT.ISO8859-15
af_ZA.ISO8859-1
hu_HU.UTF-8
et_EE.UTF-8
he_IL.UTF-8
uk_UA.KOI8-U
be_BY
kk_KZ
hu_HU.ISO8859-2
it_CH
pt_BR
ko_KR
it_IT
fr_BE.UTF-8
ru_RU.ISO8859-5
zh_TW
zh_CN.GB2312
no_NO.ISO8859-15
de_DE.ISO8859-15
en_CA
fr_CH.UTF-8
sl_SI.UTF-8
uk_UA.ISO8859-5
pt_PT
hr_HR
cs_CZ
fr_CH
he_IL
zh_CN.GBK
zh_CN.GB18030
fr_CA
pl_PL.UTF-8
ja_JP.SJIS
sr_YU.ISO8859-5
be_BY.CP1251
sr_YU.ISO8859-2
sv_SE.UTF-8
sr_YU.UTF-8
de_CH.UTF-8
sl_SI
pt_PT.UTF-8
ro_RO
en_NZ.US-ASCII
ja_JP
zh_CN
fr_CH.ISO8859-1
ko_KR.eucKR
be_BY.ISO8859-5
nl_NL.ISO8859-15
en_GB.ISO8859-1
en_CA.US-ASCII
is_IS.ISO8859-1
ru_RU.CP866
nl_NL
fr_CA.ISO8859-15
sv_SE.ISO8859-15
hy_AM
en_CA.ISO8859-15
en_US.ISO8859-1
zh_TW.Big5
ca_ES.UTF-8
ru_RU.CP1251
en_GB.UTF-8
en_GB.US-ASCII
ru_RU.UTF-8
eu_ES.UTF-8
es_ES.ISO8859-1
hu_HU
el_GR.ISO8859-7
en_AU
it_CH.UTF-8
en_GB
sl_SI.ISO8859-2
ru_RU.KOI8-R
nl_BE.UTF-8
et_EE
fr_FR.ISO8859-15
cs_CZ.ISO8859-2
lt_LT.UTF-8
pl_PL.ISO8859-2
fr_BE.ISO8859-15
is_IS.UTF-8
tr_TR.ISO8859-9
da_DK.ISO8859-1
lt_LT.ISO8859-4
lt_LT.ISO8859-13
zh_TW.UTF-8
bg_BG.CP1251
el_GR.UTF-8
be_BY.CP1131
da_DK.ISO8859-15
is_IS.ISO8859-15
no_NO.ISO8859-1
nl_NL.ISO8859-1
nl_BE.ISO8859-1
sv_SE.ISO8859-1
pt_BR.ISO8859-1
zh_CN.eucCN
it_IT.UTF-8
en_CA.UTF-8
uk_UA.UTF-8
de_CH.ISO8859-15
de_DE.ISO8859-1
ca_ES
sr_YU
hy_AM.ARMSCII-8
ru_RU
zh_HK.UTF-8
eu_ES.ISO8859-1
is_IS
bg_BG.UTF-8
ja_JP.UTF-8
it_CH.ISO8859-15
fr_FR.UTF-8
ko_KR.UTF-8
et_EE.ISO8859-15
kk_KZ.UTF-8
ca_ES.ISO8859-15
en_IE.UTF-8
es_ES
de_CH.ISO8859-1
en_CA.ISO8859-1
es_ES.ISO8859-15
en_AU.ISO8859-1
el_GR
da_DK
no_NO
it_IT.ISO8859-1
en_IE
zh_HK.Big5HKSCS
hi_IN.ISCII-DEV
ja_JP.eucJP
it_IT.ISO8859-15
pl_PL
ko_KR.CP949
fr_CA.UTF-8
fi_FI.ISO8859-15
en_GB.ISO8859-15
fr_FR
hy_AM.UTF-8
no_NO.UTF-8
es_ES.UTF-8
de_AT
tr_TR.UTF-8
de_DE
lt_LT
tr_TR
C
POSIX

locale

~ ❯❯❯ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

odbcinst -j

~ ❯❯❯ odbcinst -j
unixODBC 2.3.7
DRIVERS............: /usr/local/etc/odbcinst.ini
SYSTEM DATA SOURCES: /usr/local/etc/odbc.ini
FILE DATA SOURCES..: /usr/local/etc/ODBCDataSources
USER DATA SOURCES..: /Users/yoeight/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

I don't have that issue if I use the 13 version.

OSX: 10.14

Thanks for your time.

[karinazhou]

Hi @YoEight Thank you for reporting this. We have a fix for this issue after the 17.2 release. Though we have a 17.3 preview for Linux, the 17.2 is the latest version available for Mac. You may have to wait until the next 17.3 RTW release in the early 2019.

A possible workaround for now is to change the LC_CTYPE to "en_US.UTF-8". This should eliminate the locale error.

Thanks,
Karina

[keithbrinks]

@karinazhou I am having the same issue (using ODBC 17.2.0.1 on MacOS 10.14.2). Except, my locale settings differ in that my LC_CTYPE is already set to en_US.UTF-8:

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

The error message I get is:

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: collate_byname<char>::collate_byname failed to construct for C/C/en_GB.UTF-8/C/en_GB.UTF-8/C

I have tried to explicitly set the locale via setlocale() (trying with both LC_COLLATE and LC_ALL), doing so generates only a slightly different message:

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: collate_byname<char>::collate_byname failed to construct for en_US.UTF-8/C/en_GB.UTF-8/C/en_GB.UTF-8/C

Are there any other potential workarounds we can try until 17.3 is released?

Thanks

[karinazhou]

Hi @keithbrinks ,

That looks weird... To investigate it further, could you please check a few more things?

1. Check the version of the driver version you are using.
   To do this, please go to the /usr/local/etc/odbcinst.ini and get the full path of the libmsodbcsql.17.dylib and run the command line:
   ls -l <full path of libmsodbcsql.17.dylib>
   This will show you the symbolic link for the driver if you install the driver from homebrew.

2. About setlocale()
   Could you send me the setlocale() command line you have used explicitly? Are you calling this at the beginning of your application?
   Moreover, please run these two command lines after that explicit setlocale() call and print out their return values:
   setlocale(LC_ALL, NULL)
setlocale(LC_CTYPE, NULL)

Thanks,
Karina

[keithbrinks]

Hi @karinazhou,

This is the result to your first question:

/usr/local/lib/libmsodbcsql.17.dylib -> ../Cellar/msodbcsql17/17.2.0.1/lib/libmsodbcsql.17.dylib

As for the setlocale(), admittedly I wasn't entirely sure what I was doing so I just threw it my Helper.php file (using the Laravel framework), so no, it would not have been at the beginning of the application. I have now moved to the top of the index.php file, so it should be the very first thing that runs.

The explicit command I'm using at this point:

setlocale(LC_CTYPE, "en_US.UTF-8");

And the error log shows the following:

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: collate_byname<char>::collate_byname failed to construct for en_US.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8

Doing a var_dump of setlocale(LC_ALL, NULL) and setlocale(LC_CTYPE, NULL) both return the following:

string(1) "C" 

[patrick0888]

@keithbrinks
I had the same error using Laravel.

Fixed it by adding this to AppServiceProvider.php boot method.

setlocale(LC_ALL, 'en_US.UTF-8');

[keithbrinks]

@patrick0888 Thanks for the tip. I just tried adding that, but I'm getting the same error still.

[karinazhou]

@keithbrinks To narrow down the issue a bit, could you please run a simple c++ test on your Mojave and see whether the issue is still happening or not?
You can find the sample code from
https://github.com/Microsoft/homebrew-mssql-release/issues/18#issuecomment-397163613

Please copy the Reproducible code into a cpp file, e.g. locale_test.cpp. And do the following modification:

1. Change setlocale(LC_ALL, "C/UTF-8/C/C/C/C"); to
   setlocale(LC_CTYPE, "en_US.UTF-8")

2. Change printf("std::locale name : %s\n", std::locale(setlocale(LC_CTYPE, NULL)).name().c_str()); to

printf("setlocale LC_ALL: %s\n", setlocale(LC_ALL,NULL));
printf("setlocale LC_CTYPE: %s\n", setlocale(LC_CTYPE, NULL));

NOTE: this will show your current LC_ALL string and LC_CTYPE.

3. Provide the correct connection string, e.g.
   driver={ODBC Driver 17 for SQL Server};server=<server_ip>;uid=<username>;pwd=<password>

After that, run this command line to compile the cpp file:
g++ -fshort-wchar -std=c++11 -stdlib=libc++ -I /usr/local/opt/msodbcsql17/include/msodbcsql17/ -o locale_test locale_test.cpp -g -lodbc

Once you get the locale_test executable, simply run ./locale_test to see the output.

These should return some messages like this:

setlocale LC_ALL: C/en_US.UTF-8/C/C/C/C
setlocale LC_CTYPE: en_US.UTF-8
[01000] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed database context to 'master'. (5701)
[01000] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed language setting to us_english. (5703)
Connected
data : 1

You may also play around with setlocale() by passing different locale value, e.g.
setlocale(LC_ALL, "en_US.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8")
which is from your previous error message.

This test will go through the ODBC driver directly and eliminate the impact from PHP stuff.

Thanks,
Karina

[keithbrinks]

@karinazhou I followed your steps and am able to reproduce the exact same same result as your example:

setlocale LC_ALL: C/en_US.UTF-8/C/C/C/C
setlocale LC_CTYPE: en_US.UTF-8
[01000] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed database context to 'master'. (5701)
[01000] [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed language setting to us_english. (5703)
Connected
data : 1

It may be worth noting that per this issue I posted earlier today, I am able to connect to the SQL Server fine and able to perform GET, PATCH, and DELETE requests to the application without any issues. However, when performing POST requests, the request goes through to the application fine and is even sent to the database where records are being created. But the issue lies with, what I assume is, the response the database is giving back (or how the ODBC drive is handling it?).

Depending on which web server I'm using (Apache or Nginx) I either get a 502 error, or a ERR_EMPTY_RESPONSE. When testing the POST request using Postman, it just says 'Could not get any response'.

Neither PHP or my application throw any errors. The only error I get is in the Apache/Nginx error which seems to be eluding to the ODBC driver/locale issue:

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: collate_byname<char>::collate_byname failed to construct for en_US.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8

Maybe that doesn't help -- I'm just struggling to determine where the issue is actually coming from.

[karinazhou]

@keithbrinks The sample code I listed is to test whether the ODBC driver on your side can deal with locale correctly. It looks like that the driver works fine with your locale setting because there is no libc++abi.dylib error returned from the test.

The error message you get is probably from the std::locale() call when passing invalid locale value into it. In the driver, we only get the LC_CTYPE and pass it into std::locale(). From your case, it seems to pass en_US.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/en_US.UTF-8 to std::locale() function which throws the error. However, I am not sure which part is actually causing this error. It may be inside your application or inside the PHP driver.

Thanks,
Karina

[karinazhou]

Hi @YoEight and @keithbrinks ,

I am going to close this issue because there is no updates on this since Dec, 2018. Please feel free to reopen it if you have more questions about this.

Thanks,
Karina