New SQL Server from backup; application has successful login on 1 database, but fails on another: 0x80040e4d
Here is a summarization of our efforts to make this work:


We set up a new SQL Server using SQL Server Express 2014 and attached the .MDF files from the most recent backup. 
We created a user and gave access to all the databases; by giving ownership and db_datareader and db_datawriter to the user for all the relevant databases, and by granting rights under User Mapping. 
In the application we needed to get back online: The initial connection string, that worked fine with the old SQL server before it crashed, was: DSN=&lt;SQL_Server&gt;;UID=&lt;User Id&gt;;PWD=&lt;Password&gt;;Database=&lt;Catalogue&gt;; 


Our initial attempt was to replace &lt;SQL_Server&gt; with the IP-address to the new SQL Server (with and without port). 
This did not work; so we changed DNS=.. to Server= (with and without port); this did not work either. 
All these attempts gave errors that the connection string was invalid. So we looked up different connection strings for IP-Addresses using OLE DB and found this: Provider=sqloledb;Data Source=&lt;IP-address&gt;;Network Library=DBMSSOCN;Initial Catalog=&lt;Database&gt;;User ID=&lt;User&gt;;Password=&lt;Password&gt;;. This worked, but only for one of the connections, for database A, while database B still failed. 

The application successfully connects and reads data from database A, but fails with error: "Login failed for user 'goa'." on database B. 


The SQL Server log files shows the following:
Login failed for user 'goa'. Reason: Password did not match that for the login provided. [CLIENT: &lt;IP Address&gt;] and Error: 18456, Severity: 14, State: 8. 

We tried changing the passwords, and then neither connection worked. This gives me the impression that there were some encryption problem (because I recalled a mention of encryption in one of the forums I had browsed, looking for answers), and that the SQL Server tried to decrypt the password with the wrong key or something, and by chance uses the correct key in certain circumstances.


To solve this potential encryption problem; we added Integrated Security=SSPI; to the connection strings, this did not help. Nor did Integrated Security=yes; or Trusted_connection=yes;. 

To make sure this was not a matter of the number of connections, or a limit in the number of open connections at a time: we changed the order of the connections so that database B went first, and A went second; and this time it was still the database B that failed. 
We tried ressurecting the users from the original SQL server, by creating those users and executing: EXEC sp_change_users_login 'Auto_Fix', '&lt;user&gt;', NULL, '&lt;Password&gt;'. This gave a positive result: The number of orphaned users fixed by adding a new logins and then updating users was 1.. Thanks to @SQLPRODDBA and @Chad-Mattox 


This is what worked for us:


Changing the connection string to: 
Driver={SQL Server};Server=&lt;IP-Address&gt;;UID=&lt;User Id&gt;;PWD=&lt;Password&gt;;Database=&lt;Catalogue&gt;;That is going back to the initial format and adding Driver=.. to the string. For this connection we did not use a ressurected user from the old SQL server.