Alteryx Designer Desktop Ideas

Alteryx 2019.4 introduced support for Tableau's .hyper extract format, however it only supports single table extracts. .hyper files have supported multiple tables since mid-2018, so I'd like Alteryx to support that as well.

Here are a couple of current use cases (as of February 2020) and one future one.

- We have malaria incidence data that is joined to multiple sets of spatial data. Doing all of the joins in the extract creation process to build a single table extract is not possible due to processing time & memory constraints, so we use a multiple-table extract.

- There are multiple ways to do row level security in Tableau. A common way is to have separate tables for the data & the entitlements and then use calculations at run-time to filter the data, and for that having a multiple table extract is ideal.

- In 2020 Tableau will be introducing new data modeling capabilities (this was first demoed at the 2018 Tableau Conference, there were sessions on it at the 2019 Tableau Conference) where one goal is vastly improved performance for large fact table to fact table joins where previously we'd have to do much more data preparation. This is another case where multiple table extracts would be useful.

I've attached a sample Hyper file with two tables in the extract (it's zipped because the Community site doesn't accept .hyper files).

Supporting alternative schema and table names in Hyper extracts https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Input-tool-Support-more-than-Extract-Extract... is a prerequisite for this because by definition multiple table extracts have multiple table names.

A related idea is supporting multiple table extracts for the Output tool: https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Support-multiple-table-extracts-in-the-Table...

Jonathan

Alteryx 2019.4 added support in the Input tool for Tableau .hyper extract files. The tables stored in the .hyper files have a schema and a table name. Tableau's old .tde files and Hyper files created by Alteryx & Tableau Desktop use "Extract.Extract" as the schema.tablename. However when using Tableau's Hyper API the default schema is "public" and the table name is arbitrarily specified by the user or application.

This has two impacts:

1) Without this support Alteryx can't open many .hyper files created by other applications. By way of example I've attached a sample .hyper file (in a .zip because the community software doesn't allow .hyper files) that has the schema.tablename "public.table1".

2) Also support for names beyond Extract.Extract is required in order to support multiple table extracts (submitted as a separate Idea).

Please update the Input tool so the user can select the particular schema and table name from the .hyper file.

Jonathan

Similar to previous ideas from @patrick_mcauliffe and @shailesh_patel - would like to request 2 things:

Default on Folder Picker Interface tool

The folder picker tool does not currently allow a default value - this unnecessarily adds work if users have the same value 90% of the time.

Please add a field for the default value that will show when the interface starts up

Similar ideas:

- Default on Date interface: https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Default-Date-for-Interface-Tool/idi-p/35770

- Default on File Selector: https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Default-file-location-in-file-broswer-Interf...

We have a large SAS Programming team that keeps most of thier data sets in a Unix environment. A more robust ODBC connection to this data would greatly enhance our use of Alteryx. The current SAS odbc Driver tends to lock Alteryx up. Creating edits to the connection also tends to lock ateryx up to an unrecoveable point.

As Tableau has continued to open more APIs with their product releases, it would be great if these could be exposed via Alteryx tools.

One specifically I think would make a great tool would be the Tableau Document API (link) which allows for things like:

- Getting connection information from data sources and workbooks (Server Name, Username, Database Name, Authentication Type, Connection Type)

- Updating connection information in workbooks and data sources (Server Name, Username, Database Name)

- Getting Field information from data sources and workbooks (Get all fields in a data source, Get all fields in use by certain sheets in a workbook)

For those of us that use Alteryx to automate much of our Tableau work, having an easy tool to read and write this info (instead of writing python script) would be beneficial.  

It would be useful if enhancements could be made to the Sharepoint Input tool to support SSO. In my organisation we host a lot of collaborative work on SharePoints protected by ADFS authentication and directly pulling data from them is not supported with the SharePoint input tool, it is blocked. The addition of this feature to enable it to recognise logins would be very useful.

A problem I'm currently trying to solve and feel like I'm spending way too much time on it..

I have a data set which has some data in it from multiple languages, and I only want English values.  I was able to get rid of the words with non English letters with a little regular expression and filtering.  However, there's some words that do contain all English letters but aren't English.  What I'm trying to do is bring in an English dictionary to compare words and see which rows have non English words according to the dictionary.  However, this is proving to be a bit harder than I thought.  I think I can do it, but it feels like this should be much simpler than it is.

It would be great to have a tool that would run a "spell check" on fields (almost all dictionaries for all languages are available free online).  This could also be useful also just for cleaning up open text types of data where people type stuff in quickly and don't re-read it! 🙂

Currently the OLEDB/ODBC connection string for a server that requires a password can be injected into with a password that contains a ; or a |.  There may be other values that cause this as well - these are the ones our company has found so far.

This lowers the security of passwords for our other systems, by limiting what characters we can use.

// This is my new formula
MAX([Price] * [Quantity],0)
// This was my old formula
// [Price] * [Quantity]

Imagine being able to SELECT your text block (could be many lines) and right-clicking to see an option to Comment or Un-Comment those configuration statements.  I thought that you'd like it too.

Cheers,

Mark

90% of the time when dragging in an input tool I need to drag in a select tool to pick only the fields that you want.  Best practice suggests this should be 100% of the time for efficiency.  Embeding this functionality within the input tool itself would save a step.

I'd like to be able to disable a tool container but not minimize it so I can still see what's in there. Maybe disabled containers could be grayed out the way the output tools are when you disable them. We would still need to retain current features in case people like it that way, but it would be nice to choose.

To keep from being too specific, the "Idea" is that Alteryx Designer should do better at recognizing and handling Date/Times on input. Thoughts include:
 
1) Offer more choices in the Parse: DateTime tool, including am/pm.
2) Allow users to add new formats to the Parse: DateTime lists.
3) Include user-added formats in the Preparation: Auto Field tool's library.
4) Don't require zero-padding of days and hours in the DateTimeParse() function.  (1/1/2014 1:23:45 AM looks enough like a date that DateTimeParse() should be able to figure it out, but it stumbles on day and hour.)
 
My particular difficulty is that I have incoming date/times with AM/PM components.  I've gone ahead and created a macro to take care of that for now, but it certainly seems like that sort of thing would be handled automatically.
 
Thanks!

A recent post solution (https://community.alteryx.com/t5/Data-Preparation-Blending/Can-somebody-tell-me-where-is-quot-Choose...) by @patrick_digan alerted me to a loss of functionality of the Input Tool.  In order to define a range of data via SQL to Excel (e.g. Sheet3$A1:C10) you need to know a work-around instead of just modifying the SQL.  The work-around is to modify the XML.  I would like to see that functionality returned to the Input tool.

Cheers,

Mark

Bulk Load for Vertica (especially with the gzip compressed format) is very powerful, I can upload several dozens of millions of rows in a few minutes. Can we have it please?

https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/AdministratorsGuide/BulkLoadCOPY/UsingCOP...

Hello all,

It's really frustrating to have an "alteryx field type" in In-Database Select. It doesn't even make sense since we're manipulating only data in SQL database where those types does not exist. What we should see is the SQL field type.

Best regards,

Simon

Hello all,

According to wikipedia https://en.wikipedia.org/wiki/Materialized_view

 In computing, a materialized view is a database object that contains the results of a query. For example, it may be a local copy of data located remotely, or may be a subset of the rows and/or columns of a table or join result, or may be a summary using an aggregate function.

The process of setting up a materialized view is sometimes called materialization.[1] This is a form of caching the results of a query, similar to memoization of the value of a function in functional languages, and it is sometimes described as a form of precomputation.[2][3] As with other forms of precomputation, database users typically use materialized views for performance reasons, i.e. as a form of optimization.

So, I would like to create that in Alteryx, for obvious performance reasons in some use cases.

This is not a duplicate of https://community.alteryx.com/t5/Alteryx-Designer-Desktop-Ideas/In-DB-Create-View/idi-p/157886

Best regards,

Simon

Hello all,

According to wikipedia :
https://en.wikipedia.org/wiki/Embedded_database

An embedded database system is a database management system (DBMS) which is tightly integrated with an application software; it is embedded in the application.

It's often like a single file/dll that you can use inside an application without the user having to connect (or at least to configure it) to it (it's all done inside the application). So, it's widely portable.


Why it does matter ?

As of today, there is not a single example of in database workflow because all the supported databases need the user to:

1/install an odbc driver (most of time, he won't have the rights to do so)

2/configure an odbc connection (sometimes, he doesn't have the rights to)

3/configure a connection on Alteryx (ok, he can)
So it requires IT action, which can be pretty long (in ùany organization, it requires several weeks !!). And even with all of that,the users must be granted privilege to access database and the customer need to develop its own examples and write its own specific documentation.

Well, this is not efficient.

What I suggest is Alteryx to use one of embedded database for training support/one tool examples. SQLlite seems good, maybe a more analytics oriented (like DuckDB ) would be more efficient.
The requirement are, I think, the following :
-OpenSource and free
-Fast
-SQL compliant
-With a bulk load ability

Best regards,

Simon

Hello all,

So, right now, we have two very separated products : Alteryx Designer and Alteryx Designer Cloud. But what if you want to go from Alteryx Designer on your desktop to the cloud ?

well, you will have to rewrite every single workflow because you can't publish or import your current workflow on Alteryx Designer Cloud. You cannot  export Designer Cloud workflow to Alteryx Designer on Desktop either.

This is a huge limitation on cloud implementation and sells and the ONLY product I know that's not compatible between on-premise and cloud.

Please Alteryx, this is a no-brainer situation if you want to convince your customers !

Best regards,

Simon