Windows 7 vs. Windows 10: Output tool changes to 'create table' in Windows 10

[Cedric]

Hello, community:

I have a pretty strange problem that I need to discuss to see if there is a fix for. Let me set things up with a little context.

Context

I work in a small team; there are three users and we often work on Alteryx flows in tandem. The newest member of our team was exploring and learning about our new flows, but if he tried to run them, they would result in an error. We've come to the strange conclusion that it is because he's using Windows 10 and the other two of us are using Windows 7.

The Issue

I have an illustration of this. But here's the short synopsis: When a Windows 7 user opens a workflow and it writes to a database, in Windows 7, the configuration options retain our last known state in Alteryx. Most of the time, we're doing an 'Update, insert if new' or the driver-equivalent of that.

Our poor Windows 10 user will open the same workflow from the same location immediately after a Windows 7 user saves it, and the output tool defaults to 'Create a new table'

If he runs that flow without explicitly changing the output tool, he receives an error message. Worse yet, if he saves the workflow unwittingly, it will throw an error when we schedule the workflow as a part of a larger batch of jobs we run. So, essentially, he's off-limits to saving workflows or even opening certain workflows currently due to this strange bug. 

Here are pictures:Windows 7 view

Windows 10 view of the same file

 Additional details

While the example above is using the Teradata bulk loader protocol, the same issue happens if the Windows 10 user is using an ODBC protocol.

---

 Has anyone had this problem before? And, better yet, does anyone have a solution or workaround?

Our current plan of attack is to downgrade the user to Windows 7. We have some other issues with Windows 10 that necessitate this. But I thought I would bring it up to the community to alert Alteryx to this problem as well. 

Thanks,

Cedric

[jgo]

My apologies... I got confused with which image was Win7 and which was Win10 on the PM you sent me (thought top was Win10).

Hmm... Can you see if the "x64" shows up next to "Alteryx Designer" in the title bar on the Win7 machine?

@LindaT- any ideas on this?

[Cedric]

X64 definitely shows up in the Win7 Alteryx (and on the Win10).

[cid:image001.png@01D27253.A22C7400]

[jgo]

@Cedric,

OK good, just wanted to make sure it wasn't something simple that was overlooked.

There's a few things that don't seem to add up when referencing your screen shots and trying to reproduce the same result on my computer. It might be time to schedule a WebEx to screen share if you'd like to continue troubleshooting. If so, send me an email (available in my profile) with some times you're available tomorrow and we'll get something scheduled.

[jgo · Accepted solution]

OK, so to close this out...

While still not 100% why it was behaving this way, the issue was with how the alias was set up on the Win10 machine. Even though it was set up to use a 32bit ODBC connection, it was still attempting to use the bulk loader.

Corrected the issue by simply reconfiguring that alias and properly setting it to use the 64bit ODBC, which now shows all the proper/expected non-bulk loader output options.

[Cedric]

I feel that we should change the name of this to 'Output tool changes to "create table"'.

And in short, the issue is that the Alteryx aliases had conflicting alias connection strings.

If sharing aliases, the Alteryx aliases need to match exactly. It had nothing to do with our drivers or our operating system and everything to do with Alteryx alias mismatch.

Thanks @jgo for your help on this. It was instrumental.