This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Hopefully this is the right place to post this and it hasn't been suggested already but I think it would be useful to add a numeric indicator to the formula tool to show how many formulas are being done with one tool. It would be useful when going back into or sharing workflows that a user would know more than one function is being carried out at that point. Currently I change the annotation to show how many but I think it would be useful if the icon changed dynamically. Below is a mockup of what I think it should look like.
If you have a field length of say 10 in a Select Tool, then you use a Left Join tool and change that length to say 4. This turns that field red - as it should. Then add a Select tool after the Union. It should say 4 in the second Select tool. But instead it says 10. If it was changed to 10 (and it wasn't) then the field s/b red.
Today I have some workflows which have certain steps that occur after files are output. I have these set up inside of Tool Containers so that I can easily enable/disable them as I am working if I do not want to produce output for this particular run. However, sometimes if I need to troubleshoot on a workflow that I haven't worked on for awhile, I can neglect to disable these, which can cause errors. This is usually harmless, but annoying.
Having two more options on Tool Containers could really help to improve this!
Disable When Browse Tools Disabled would be useful for any analysis/debugging steps that I only want to run when I am browsing to find data, but should not run otherwise.
Disable When Output Disabled would be really useful to ensure that these tools are turned off alongside the "Disable all tools that write output" option in Workflow-Configuration-Runtime.
This would save me a lot of unnecessary error messages and moments of panic, and would make these types of workflows easier for other users to debug without extensive notes.
A common problem with the R tool is that it outputs "False Errors" like the following: "The R.exe exit code (4294967295) indicted an error"
I call this a false error because data passes out of the R script the same as if there were no error. As such, this error can generally be ignored. In my use case, however, my R tool is embedded within an iterative macro, and the error causes the iterator to stop running.
I was able to create a workaround by moving the R tool to a separate workflow and calling it from the CReW runner macro within my iterator, effectively suppressing the error message, but this solution is a bit clumsy, requires unnecessary read/writes, and uses nonstandard macros.
Hi, I have searched through the community, and I wasn't able to find a duplicate for this idea. If in fact there is, I apologize and please point me to that post. I think that it would be a good idea to have date options in the summarize tool that would allow for grouping at higher levels of the date. I often have a date field that is specific to the day (i.e. 2018-01-01), and I just want to group by the year or month. Currently in order to do this, I have to create a formula before the summarize tool that formats the date according to how I want to group it, and then I am able to group off that field in the summarize tool. It would be nice if in the summarize tool, I could select the date field, and then have the option to group it at year, month, week, etc.
Presently when mapping an Excel file to an input tool the tool only recognizes sheets it does not recognize named tables (ranges) as possible inputs. When using PowerBI to read Excel inputs I can select either sheets or named ranges as input. Alteryx input tool should do the same.
I like the new cache option in 2018.3, but I would like a user setting added that would allow me to 1) write the cache files to a local drive and 2) have them persist when I re-open Alteryx. Currently, the files are written to the user defaulted temp space and don't persist when Alteryx is closed down. Thanks!
In a database, a view is the result set of a stored query on the data, which the database users can query just as they would in a persistent database collection object. This pre-established query command is kept in the database dictionary. Unlike ordinary base tables in a relational database, a view does not form part of the physical schema: as a result set, it is a virtual table computed or collated dynamically from data in the database when access to that view is requested. Changes applied to the data in a relevant underlying table are reflected in the data shown in subsequent invocations of the view. In some NoSQL databases, views are the only way to query data.
Views can provide advantages over tables:
Views can represent a subset of the data contained in a table. Consequently, a view can limit the degree of exposure of the underlying tables to the outer world: a given user may have permission to query the view, while denied access to the rest of the base table.
Views can join and simplify multiple tables into a single virtual table.
Views can act as aggregated tables, where the database engine aggregates data (sum, average, etc.) and presents the calculated results as part of the data.
Views can hide the complexity of data. For example, a view could appear as Sales2000 or Sales2001, transparently partitioning the actual underlying table.
Views take very little space to store; the database contains only the definition of a view, not a copy of all the data that it presents.
Depending on the SQL engine used, views can provide extra security.
With the amount of users that use the publish to tableau server macros to automate workflows into Tableau, I think its about time we had a native tool that publishes to Tableau instead of the rather painful exercise of figuring out which version of the macro we are using and what version of Tableau Server we are publishing to. The current process is not efficient and frustrating when the server changes on both the Tableau and Alteryx side.
In order to debug a call to a REST API - it is often necessary to take the web call, and pop this into a web browser. Can you add a second output to a RestAPI tool (a derivative of the Download tool) that has a second output that provides the full web call that was made, including the full parameterised URL. This would make it MUCH easier to debug rest API calls.