FAQ and Troubleshooting
Last updated
Was this helpful?
Last updated
Was this helpful?
See our section about the installed packages about that.
See our section about the installed packages about that.
There are some keywords that can't be used as result variable names. The UI will prevent you from typing those words into the name text field of your result.
There is a button in the top right corner, right next to the save button. Click it to extend the right sidebar. Click again to hide it.
If you get the following error message
then the vectors assigned to your result variables have a different length. Remember that the result variables will be combined to a tabular format, which requires them to have the same length. The length of the results is checked iteratively - so if your 3rd result variable appears in the error message you can assume that results 1 and 2 had the same length.
If your output in the script editor is longer than the displayed rows (= 200 rows) the script editor can not validate the length and no error message will appear. So if you have problems with your script double-check the length of your results.
If you get an error 127 message like the one below
then to at least one defined result variable, no value is assigned.
A commonly used library used in R scripts is the "dplyr" package which uses a special version of data.frames, so-called "tibbles". In our script editor, this data type can't be used as output. If a tibble is used as the output of the script the following error message appears:
Tibbles can be used anywhere in the script, but the final assignment to the result variables has to be data.frames or vectors. Therefore you can use the "as.data.frame( )" function to convert the tibble into a data.frame for the final assignment to the result variable.
Note: Although you can assign data.frames to result in variables use this feature only for debugging because in widgets a result variable is expected to be a vector!
If you get the following error message when executing your python script it is possibly due to the use of # to mark a line as a comment.
Please use single or tripple " to mark a line as a comment instead and do not mix comments with code within a line.
The majority of these problems are caused by unhandled cases in your script. These are for example empty datasets or unexpected entries in your data. Below you can find some common cases and how to deal with them.
If you use relational filters in your data (e.g. today, this month) your data might have changed or there is no data available for this period of time. A common pitfall is that a script can't handle an empty dataset. To avoid this problem add an initial check-in your script where you check if there is data in your input dataset by e.g. evaluating the number of rows.
Another common mistake is that some assumptions in the script are not true or that the data used for testing is different from the data used when applying the script to real data. This could be for example that a column is assumed as numeric, but it also includes some entries which are not only numeric (like '123b'). Another example could be that empty cells (NA's) are not handled in a script.
So if your script doesn't work as expected also check the entries in your input data and add necessary checks or conversions in your script.
The input data of your script in the script editor can be different from the input your script gets when it is used in a widget on a dashboard. In the script editor, only the filters defined in the datasets are applied to the data. For a widget on a dashboard also the dashboard filters are forwarded to the dataset (for more information on 'dashboard filters' see here).
So one problem can be the data itself. Either because there is no data or there are some unexpected or unhandled entries (for more information see section above).
Another cause for this problem can be the script itself. As already mentioned here and in the 'Common errors' section above, the length of all result variables in a script has to be the same. If your output in the script editor is longer than the displayed rows (= 200 rows) and the length of the output variables is different, you can not identify this problem in the script editor. In these cases the script seems to execute successfully, but used in a widget this script will through an error. To avoid this check if your script produces the same length for each output variable.
You can't step through your script for debugging, but you can use the preview of your script input and output at the bottom of the script editor.
Our recommendation is to first create only one output variable. Name it for example "results" and use the data type "String" for this variable. In this case, you can assign any type of object (data.frame, vector, scalar) and data type (number, character, boolean, etc.) to it.
Write your entire script and assign the data or variable to any line where you want to inspect it to the "results" variable, but keep in mind that only the last assignment will be displayed in the output.
When your script works as expected and you are finished with debugging you can remove this output variable and create all the desired output variables.
Especially data of type boolean which also includes "NA" entries can lead to some confusion and misinterpretation. In the example below a vector with boolean data is converted into some different data types and assigned to the result variables of the respective data type. In this example, the data type of each variable is also represented in the postfix of its name e.g. "_as_string".
In the output section, you can see that the NA entries for boolean are displayed as FALSE, for the string as NULL, and for number types as NaN.
We recommend to use the as.numeric() instead of the as.integer() conversion function. Otherwise, you get the minimum of the possible number range of a signed 32-bit integer (-2147483648) as result of the NA entry.
If you use auto-generated series for your widget (with strings in the series column and on the x-axis) and the order of your x-axis or the grouping is not as you would expect because your data is ordered, the following might help you.
Consider the following dataset
thing [string]
month [string]
y [numeric]
T1
January
2
T1
March
5
T2
January
1
T2
February
2
T2
March
3
T3
February
3
T3
March
4
If you use auto-generated series with a thing as a series column, month as x-axis, and y as y-axis March will be the second month on the x-axis before February. Because using auto-generated series with a string data type on the x-axis causes the x-axis entries to be sorted by the order of the appearance of each unique entry in the input data. The solution is to "complete" the dataset such that every combination of things a month appear in the dataset. The result should look as follows
thing [string]
month [string]
y [numeric]
T1
January
2
T1
February
NULL
T1
March
5
T2
January
1
T2
February
2
T2
March
3
T3
January
NULL
T3
February
3
T3
March
4
For example, in R you could use the following code (from the tidyverse package) to do that, given that your dataset is stored in the R data frame "df".
You can find this information here...
