Variable issue on db backup step

Hi,

I´m having some issues with using a variable as the password for doing a database backup step. I use variables called “databasePassword” and scope them per environment and then I use that variable for the “SQL password” box (I tick the box for custom binding and then select the variable “databasePassword” so the text field then reads “#{databasePassword}”.

2 of 4 environments works fine, on the other 2 I get a login error:
ConnectToDatabase : An error occurred connecting to the database server!
System.Management.Automation.MethodInvocationException: Exception calling “Connect” with “0” argument(s): “Failed to connect to server …” —> Microsoft.SqlServer.Management.Common.ConnectionFailureException: Failed to connect to server … —> System.Data.SqlClient.SqlException: Login failed for user ‘xxx’.

Trying the same username password when logging into to the SQL server using Management Studio works fine, as does using the password directly in the SQL password field on the db backup step in Octopus so the actual credentials are fine and the user has the same roles on all servers.

It doesn´t matter if I mark the variable to be sensitive or not.

A bit lost, don´t know how to resolve this and I need the variable as we have different passwords on the servers.

BR, Petra

Hi,

Thanks for reaching out. I think a good way to test this out would be to try it on another project:

  • Create a brand new project that only has 1 step that executes a simple “Select top 1 from [table]” on the database.

  • Use the same lifecycle you are using in your official project for the new one.

  • Add all the password/connection string variables from scratch.

  • Add the 2 variables mentioned in this doc http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables . If something goes wrong, they will eventually help us troubleshoot this.

Create a release, deploy it in the 4 environments and let me know how it goes.

Regards,
Dalmiro

Hi,

It seemed to help to remove the variables entirely, remove the DB step and save the process and then putting them back again. Looks like some sort of mismatch of configuration in Octopus server DB when saving the variables and/or DB step.

BR, Petra