Is someone using the TDS adapter to connect to MSSQL in the production environment? What are the limitations? I need only insert and update to one single table.
Thanks! 
1 Like
That should be complete fine. A few of Dashbit clients use TDS for more complex operations than that. 
3 Likes
So the only limitation I have come across is NTLM/integrated authentication. There’s been some work done to address it but I’m not sure where it is at. Otherwise, TDS works great for me in a small department line of business application.
If you do need integrated auth, MsSQLEx (GitHub - findmypast-oss/mssqlex: Microsoft SQL Server Adapter for Elixir) works (I used it “raw”, without Ecto, vendored it into my project and tweaked some of the data type conversions to suit the project). However, it sits on top of Erlang’s ODBC implementation, and system installed drivers, so there are a few more potential points of failure. Also, text fields have limited length: Text type restricted to maximum length of 4000 · Issue #2 · findmypast-oss/mssql_ecto · GitHub. It also appears somewhat abandoned in favour of TDS. Definitely run with TDS if you can.
2 Likes
+1. I use it in a read only fashion.
The datetime types can be a bit annoying if the data is actually stored with precision of 7. If you control the creation of tables it’s not an issue.
2 Likes
Currently using it in production and it has been working perfectly. I have a Postgres backed repo for my application data and then a TDS repo for a specific integration that I need. Running both side by side works great.
I am using it to read/write a legacy mssql database with about 300 tables and millions of records with no problem.
It seems that using references keyword in table migrations do not work, but that is not a big problem, you can define your columns without using references.
Many of the tables use a non integer primary key. Ecto handles them with any problem.
