Unstable success/error result - gallery data connection

[Felipe_Ribeir0]

Hi all,

I have a gallery data connection (to a SQL Server database, using a normal input tool) that is being used by an Alteryx App. It always runs perfectly locally, but through the gallery it is unstable.

By unstable i mean that sometimes, it runs perfectly. Sometimes, i get the "Unable to translate alias" error: 

Any idea about why this "random" behaviour might be happening? 

Thanks.

[Ariharan]

Hi @Felipe_Ribeir0 , 

Alteryx has identified a defect in the 21.3 version which is preventing the alias file from being packaged when workflows are uploaded from Designer to Gallery. Without this alias file, you get this error.

Please refer to the article here for more details, and for updates: https://community.alteryx.com/t5/Alteryx-Server-Knowledge-Base/TDES-3766-Designer-2021-3-Error-quot-...

Regards, 

Ariharan R

[gabrielvilella]

The issue is not related to the saving process. It's the execution, sometimes it fails randomly. My only guess here is that there might be something wrong with the MongoDB. Alteryx support might have better insights on this. 

[Felipe_Ribeir0]

Hi @Ariharan and @gabrielvilella 

Thanks for your inputs here. What i found after some testing/looking at the logs is that the error occurs always with the same worker node. This seems to explains the "random" part, the ramdoness is related to the queue/availability of the workers.

Now i am waiting for further investigations from the server admin side to confirm that and to know exacly what is wrong with the specific worker.

[Ariharan · Accepted solution]

Hi @Felipe_Ribeir0 , 

I think your server admin team needs to configure the same SQL setting on the worker node. 

Or they can use priority tags to assign your job to not run on an issued worker node.

Regards,

Ariharan R

[Felipe_Ribeir0]

Hi @Ariharan 

Yes, we did exactly that. First we started assigning jobs just for the properly configured worker. After that and some further investigations, they claimed that the error is due to having different versions of SQL Server drivers installed on the workers. 

Unfortunately they were not able to fix this yet since it is a relatively large environment, but from the business perspective, using just one worker is not a big problem for now.

Thanks.