Database-specific configuration/configuration files to choose a database

[Claje]

Aliases are a really powerful tool, particularly when you have multiple environments (EG Test, Prod) and need a published workflow to work without any code changes (In particular in an IT or Release/Change Control model).  By configuring a system alias on your Test and Prod servers, code will dynamically point to the correct server.

However, aliases can be somewhat cumbersome if you have a lot of databases on a server, and those database names change by environment.  Effectively, you end up needing an alias for each Database, which runs into naming convention and standardization issues.

Having the ability to configure a "database value" or a "database alias" would do a lot to help this.  This could either be a file that would be attached (allowing for easy config changes without risk of modifying the underlying code structure) or a secondary tier of aliases, so that a connection string might go from:

aka:SQLSERVER (contains sqlserver and database information)

to:

aka:SQLSERVER||aka:database - so that at runtime Alteryx would evaluate the SQLSERVER alias and the database alias to create the correct connection string for that environment.

[JulieM]

@Claje thanks very much for the feedback.  I'm marking this post as under review and will look forward to seeing any others who would like to see this comment or vote this up.  Keep the feedback coming!  

[SeanAdams]

The additional piece to this is making it easier for admins to manage this - especially when there's a mix of in-DB and ODBC/OleDB connections against that database (right now, the admins end up having to deploy a DSN setup to every single worker node)

[KylieF]

Updating this idea's status back to Under Review, to be in line with past product updates.

[KylieF]

Thank you for contributing to the Alteryx Community! Our product team was have reviewed your idea and have placed it on the roadmap. We'll update this status again once we get a bit closer to the feature being available.

[goodej]

I like this idea and agree 100% with the use case regarding multiple environments and the need for dynamic connections.  However, please consider that the proposed solution maintains dependency on the alteryx credential & odbc manager to maintain the credentials for the alias.  What happens to your alias when the odbc password changes?  The credentials will still need to be updated in multiple locations (potentially across several environments, and probably several users within a team) or workflows will break.

Why not accept a connection string instead?  The alias can be used to get the latest connection information from your key vault and dynamically pass the connection string at runtime.  Connection changes can happen in one location without requiring any updates in alteryx workflows.  Switching between environments would be handled by the alias specified in your config file (.ini, .yml, etc).