Gallery using username/password in ODBC?

Question

A user had previously uploaded a workflow to our gallery and had run it there successfully.  Today, he said he was getting the Teradata error "username, password, or account is invalid" when he tried to run it on the gallery.  This has happened before when I had to change my password (which I did this morning).  Is it possible that our gallery is using my username and password for Teradata?

I had set up our gallery to require users to save their own credentials when uploading workflows (not use the server's).  I was the one who set up and tested the ODBC on the server, using my userid and password.

We've had this happen before and updating my userid and password in the ODBC on the server does work.  Is there a way to fix this?  Also, we're running the 11.7.4.37815 version of the gallery.

Heidi__dup_127 · Answer

Thanks, Mark. So I don't know how that workflow turned out (the user has left for the day) but here's what happened for my workflow that I needed to upload to our gallery.  I changed the password under "Manage In-DB Connections" in Designer (the alias for the connection).  When I uploaded the workflow to the gallery, I got an error and it wouldn't run on the gallery.  Next I logged into the server and ran Designer as administrator.  I went into "Manage In-DB Connections" and updated the connection (same alias) with my new password. Then when I ran the workflow on the gallery it ran without any errors. So is this the reason why other users workflows with the same connection name are using my userid and password?

MarqueeCrew · Answer

@Heidi__dup_127,

Within the workflow there is a tool with the ODBC connection string saved.  The user data is encrypted as part of the workflow.  That userid + password combination is now no longer valid.  There are options here for you.

* User opens and re configures all tools with the ODBC connection string.
* A saved connection ALIAS is used and all jobs that require Teradata access reference the configuration for that connection.

If you are running jobs for others (you're not the real person executing the query), I prefer the creation of SERVICE ACCOUNTS that are shared.  The service account may have different access (e.g. read-only) and may have different password requirements.  The connection for "ALTERYX_TERADATA" ID is managed by the Alteryx Admin and users can run jobs where the ID is embedded as part of the workflow.

For now, it might just be easier to update the connection within the failing workflow and put this on the to-do list.  It's something that requires some planning.  If you're off to Inspire18, it is a good topic for the Solutions Center.

Cheers,

Mark