System.Data.SQLite

The encrypted database file that was created using 1.0.79.0 cannot be opened using 1.0.82.0 if the password has white space character(s).

To reprodue the bug,

1. Create new encrypted database file using 1.0.79.0 library and provide "Test Test" as password. And insert some test data.

2. Try to open the encrypted database file using 1.0.82.0.

Does the password start or end with whitespace or is it simply embedded within it?

The current behavior that I'm seeing (with the new tests I just added) is:

1. If the password within a connection string starts with a space,
   that is preserved.

2. If the password within a connection string contains an embedded space,
   that is also preserved.

3. If the password within a connection string ends with a space, that is
   *NOT* preserved.

The above behavior is based on the connection string parsing code, as it
appears to have existed since prior to version 1.0.79.0.

If possible, it would be better to use the SetPassword method on the connection
object instead of embedding the password itself within the connection string,
to guard against possible future refactoring of the connection string parsing
code.

It would be very helpful if you could more precisely describe the issue
you are seeing, including a short C# code example if possible.

Ticket will be closed after the end-of-business on Friday, December 14th, 2012
if no response is received by then.

The problem occurs only when the password is embedded in a connection string using SQLiteConnectionStringBuilder like this:

SQLiteConnectionStringBuilder connectionStringBuilder = new SQLiteConnectionStringBuilder();
connectionStringBuilder.DataSource = this.dataFilePath.ToString();
connectionStringBuilder.Password = "My Password";
connectionStringBuilder.ForeignKeys = true;
connectionStringBuilder.DefaultIsolationLevel = IsolationLevel.Serializable;
connectionStringBuilder.FailIfMissing = true;
string connectionString = connectionStringBuilder.ToString();
SQLiteConnection connection = new SQLiteConnection(connectionString);

But after changing above code like following as you suggested, everything works fine.

SQLiteConnectionStringBuilder connectionStringBuilder = new SQLiteConnectionStringBuilder();
connectionStringBuilder.DataSource = this.dataFilePath.ToString();
connectionStringBuilder.ForeignKeys = true;
connectionStringBuilder.DefaultIsolationLevel = IsolationLevel.Serializable;
connectionStringBuilder.FailIfMissing = true;
string connectionString = connectionStringBuilder.ToString();
SQLiteConnection connection = new SQLiteConnection(connectionString);
connection.SetPassword("My Password");

Thank you.

Your example provided me an important clue to the root of the problem.

The connection string parsing code was modified to support URI file names and in 
the process, it was changed to no longer strip surrounding double quotes from the 
resulting connection property values.

This has now been fixed by trunk check-in [46ee3d16d6].

Could you please confirm that the current trunk code no longer shows the issue 
for you (i.e. when using the SQLiteConnectionStringBuilder)?