
[x] Client messages
[x] Login – When the client makes the determination to establish a TDS protocol connection with the server side, the client sends a Login message data stream to the server.
[ ] Sever messages
[ ] Error and Info
[ ] Simplify TypeInfo
Message enumintroduce a Message enum where its decode method delegates based on token type and returns the enum plus how much of the buffer was consumed so we can remember that in the stream
[ ] Encode for TypeInfo
[ ] Decode Row to a Vec of column data
Original Issue
The "normal" connection string for a Microsoft SQL Server would look like:
"Server=myServerName,myPortNumber;Database=myDataBase;User Id=myUsername;Password=myPassword;"
How do I make this work with sqlx.
Thanks,
Ashley
We don't support MS-SQL yet, so we haven't really thought about the connection strings. It will probably adapted to use a regular URL format since the connection string format is usually a purely client-side convention, that way we don't have to implement an ad-hoc parser.
It's worth discussing though, as we intend to implement support sometime soon.
Out of curiosity, what about providing ODBC support for sqlx? If it could use any wrapped ODBC driver through RODBC would that be feasible to then get MS-SQL support as well as say Oracle, DB2, etc? Is there some fundamental architectural reason that an ODBC driver could not be created for sqlx?
I haven't personally looked into how feasible support for ODBC is at a _base_ level. There are a few reasons why I'm not interested though:
SQLx needs to interact directly with the protocol layer in ways that don't make any sense ( to an abstraction layer ) to support its query macros. As a concrete example, the RowDescription message from Postgres contains a field described as "the attribute number of the column". That is completely useless information for any normal usage _however_ we make use of that field to inspect columns for NOT NULL for null-ability inference in query!.
SQLx wants to remain as pure Rust as possible. There are obvious concessions we have to make to support Oracle and SQLite. However, where possible, we aim to be pure, _safe_ Rust.
SQLx wants to deeply integrate with _Rust_ Async IO. We want to be polling TCP streams using the same reactor that is polling anything else in your application.
With that said, will be aiming to add support for new databases at a regular interval. DB2 is next on my list after MSSQL.
tiberius is no longer maintained (the repo is read-only now).
Help me sqlx, you're my only hope.
With some research, it looks tiberius has a new home at prisma/tiberius. They've done quite a bit of work and believe they are putting out a cleaned up and improved async version in days to weeks.
Initial support for MSSQL is available on master. This includes compile-time checked queries. Please open issues to request specific functionality or report bugs with the implementation.
Wonderful news!
I'm looking forward to trying this new functionality out, I have run into an issue:
sqlx = { git = "https://github.com/launchbadge/sqlx", features = [ "mssql" ] }
I get the following error:
Updating git repositoryhttps://github.com/launchbadge/sqlx
Updating crates.io index
error: failed to select a version forlibc.
... required by packagesqlx-core v0.4.0-pre (https://github.com/launchbadge/sqlx#475ed9e1)
... which is depended on bysqlx v0.4.0-pre (https://github.com/launchbadge/sqlx#475ed9e1)
... which is depended on byapiportal_net v0.1.0 (C:\Users\AshleySBuss\IdeaProjects\Rust\apiportal_net)
versions that meet the requirements^0.2.71are: 0.2.71
Any ideas or when may you have the crate ready?
But still, this is a major leap forward.
Thank you,
Ashley
@4parsleythelion probably you have a dependency which requires another version of libc as sqlx-core does. I had a similar error, because rand requires version 0.2.68 of libc but sqlx-core requires 0.2.71.
You should be able to resolve that with cargo update. They are just differing patch versions.
Most helpful comment
Initial support for MSSQL is available on master. This includes compile-time checked queries. Please open issues to request specific functionality or report bugs with the implementation.