<div dir="auto">You can try my odbc fork <div dir="auto"><a href="https://github.com/arcusfelis/eodbc/blob/master/README.md">https://github.com/arcusfelis/eodbc/blob/master/README.md</a><br></div><div dir="auto"><br></div><div dir="auto">It has an option to return types and some unicode fixes.</div><div dir="auto"><br></div><div dir="auto">It should work in Linux with mssql fine.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 8 Sep 2019, 15:44 Ingela Andin, <<a href="mailto:ingela.andin@gmail.com">ingela.andin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi!</div><div><br></div><div>I did some maintaing of this code a long time ago. I know that one objectives of the erlang ODBC-client was to try and make it easy for Erlang code to access SQL databases and the Erlang user should only have to care about Erlang vs SQL-datatypes.  However not all ODBC-backends are truly transparent in this regard, so I am afraid  it fails in this respect. Also you can input a lot of backend specific strings which makes the code dependent on the backend, in which case you might as well use a backend specific client.  Also, as I remember it, the implementation was made for a specific purpose, for which it works, and never extended to be more compleate (no communicated demand for it). As you observed this application has not really been developed for the last 10 Years and there is no plans from OTP to devleop it further (we have no own use of it). So it is really up to Open Source users to contribute if they think it useful.  As long as it is included in OTP it is possible to make pullrequests.<br></div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den ons 4 sep. 2019 kl 08:59 skrev Jan Chochol <<a href="mailto:jan.chochol@gooddata.com" target="_blank" rel="noreferrer">jan.chochol@gooddata.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tyson,<br>
<br>
Reason for using SQL_C_CHAR as physical encoding for SQL_BIGINT is,<br>
that there are not much better options.<br>
You can use SQL_C_NUMERIC, but it will not help in your case (it is<br>
still string containing digits plus some metainformation).<br>
<br>
Reason for not using SQL_C_SBIGINT or SQL_C_UBIGINT is, that it is not<br>
possible to found if SQL_BIGINT is signed, or unsigned, so it can lead<br>
to situation, that some values could not be returned. And it also<br>
requires ODBC 3.0, which is not supported by all drivers.<br>
<br>
What can Erlang ODBC client do, is to encode returned SQL_C_CHAR to<br>
number, but it can affect backward compatibility (it can be<br>
implemented in configurable way).<br>
<br>
>From my point of view, problem is that Erlang ODBC implementation<br>
tries to simplify interface too much, so it can not be used in some<br>
situations.<br>
Most problematic part is, that it does not return type information<br>
about columns (there is 'odbc:describe_table/2', but it can not be<br>
used in all cases for all requests), and different column types are<br>
encode to same Erlang type (we had own problems with distinguishing<br>
between SQL_WCHAR and SQL_CHAR).<br>
I do not see any easy way to fix this - it would probably require<br>
complete rewrite of Erlang ODBC client.<br>
<br>
On the other way - other languages have also big problems with ODBC -<br>
e.g. Perl DBD::ODBC has quite a lot problems with Unicode.<br>
<br>
Regards,<br>
Jan Chochol<br>
<br>
On Tue, Sep 3, 2019 at 3:13 PM Tyson Buzza <<a href="mailto:tyson.buzza@gmail.com" target="_blank" rel="noreferrer">tyson.buzza@gmail.com</a>> wrote:<br>
><br>
> Does anyone know why the ODBC SQL_BIGINT is implemented as SQL_C_CHAR? There must be a reason for it, but this code is 10 years old so I'm not sure who to ask. I'm wondering if the original reason would even be relevant anymore.<br>
><br>
> I'm currently writing an Ecto adapter using ODBC and this is making it difficult. If you use a big int in your schema, Ecto expects an integer and gets a string instead. Either way the solution is to create a cache holding the type information and parse the string if a number is expected. I'm just wondering if this can be fixed for other people with my problem in the future.<br>
><br>
> I'm talking about this file <a href="https://github.com/erlang/otp/blob/master/lib/odbc/c_src/odbcserver.c" rel="noreferrer noreferrer" target="_blank">https://github.com/erlang/otp/blob/master/lib/odbc/c_src/odbcserver.c</a><br>
><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank" rel="noreferrer">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank" rel="noreferrer">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank" rel="noreferrer">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>