Repository navigation
Error: Conversion error: Conversion error: Key-value pairs must be separated by a ; #313
Description
Hi!
I was playing with the crate but I couldn't get it running, after putting my connection string
static CONN_STR: Lazy<String> = Lazy::new(|| {
env::var("TIBERIUS_TEST_CONNECTION_STRING").unwrap_or_else(|_| {
"Server=tcp:myspecialserver.mycompany.com,1433;Database=DB_MYDB;User Id=myspecialuser;Password=goodpassword".to_owned()
})
});(I don't use ; in any other place in the string except to separate the keys). Then, when it compiles, cargo runs displays
Error: Conversion error: Conversion error: Key-value pairs must be separated by a `;`
Can you give me some hint? I lookup for that error on the tiberius crate but found nothing about Key-value pairs
I don't know how can I debug this error :(
Activity
anandhuremanan commentedon Jun 20, 2024
Any update on this?
MattJackson commentedon Sep 18, 2026
That error actually comes from the
connection_stringparser, and it almost always means an unescaped special character in one of the values — most often a;,{,}, or=in the password — is confusing the key/value splitter (your redacted sample parses fine, so it's likely in the real values). Two fixes: wrap the offending value in braces in the ADO string (e.g.Password={p;a}ss}), or skip string parsing entirely and build the config programmatically withConfig::new()+config.authentication(AuthMethod::sql_server(user, pass)). If neither helps, could you share the (redacted-but-structurally-identical) string that fails?AucaCoyan commentedon Sep 20, 2026
Mmmm no, I don't even remember the password I was trying to use for that connection. Nor have I access to that server anymore :(
Is it a good case to be tested thoroughly with property based or generated passwords at test time?
MattJackson commentedon Sep 20, 2026
Thanks for the follow-up — and I think property-based testing is a good instinct here.
We were able to reproduce something in this area. A password with certain special characters wouldn't parse — for example a base64-style password ending in
=padding (something likePassword=Zm9vYmFy==) failed with the same "Key-value pairs must be separated by a;" error you hit. It didn't look like it was only=, either — a few structural characters (;, quotes,{, as well as=) could trip the parsing depending on how the value was written.It seems the underlying
connection-stringcrate parsed a bit differently from ADO.NET (it looks like it wouldn't let a value contain=). We've made a change to parse ADO strings ourselves, splitting each pair on the first=the way ADO.NET appears to, so that base64 example now parses for us. We also added tests across the special characters — not just the=case — rather than a single example, and it feels a good deal more solid. There may still be edges we've missed, though, so if you or anyone hits another value that won't parse, please reopen with an example and we'll take a look.feat(config): in-house ADO.NET-superset connection-string parser (#313)
feat(config): in-house ADO.NET-superset connection-string parser (#313)
feat(config): in-house ADO.NET-superset connection-string parser (#313)
MattJackson commentedon Sep 24, 2026
Fixed in #451, shipped in v0.13.0 (https://github.com/tiberius-rs/tiberius/releases/tag/v0.13.0). Closing.