What inspired this Wish List Request?
When performing a database query that takes a few seconds, the Workflow Builder tries to move to the next step before the table has been returned from the database. This causes a dialog to show up, asking the user for the table. It's not readily apparent, but waiting until the table shows up, then clicking cancel actually causes the Workflow to run as expected.
Please describe the new or improved feature or solution you would like to see.
Changing the script from "<< Run" to "<< Run Foreground" manually eliminates this problem. Example below using AWS sample database:
New SQL Query(
Connection(
"ODBC:BI=0;BoolsAsChar=1;ByteaAsLongVarBinary=1;CommLog=0;D6=-101;DATABASE=datademo;DSN=AWS_Demo;Debug=0;FakeOidIndex=0;Fetch=100;FetchRefcursors=0;LFConversion=1;LowerCaseIdentifier=0;MaxLongVarcharSize=8190;MaxVarcharSize=255;OptionalErrors=0;PWD=%_PWD_%;Parse=0;Protocol=7.4;ReadOnly=0;RowVersioning=0;SERVER=jmpdemo.ckpyug0kokan.us-east-1.rds.amazonaws.com;SSLmode=disable;ShowOidColumn=0;ShowSystemTables=0;TextAsLongVarchar=1;TrueIsMinus1=0;UID=jmpSE;UnknownSizes=0;UnknownsAsLongVarchar=0;UpdatableCursors=1;UseDeclareFetch=0;UseServerSidePrepare=1;XaOpt=1;"
),
QueryName( "Tablet Data" ),
Select,
From( Table( "Tablet Data", Schema( "public" ), Alias( "t1" ) ) )
) << Run foreground; //default from Workflow Builder is just ") << Run;"
What would the value be to you and/or other users if this new feature is provided?
Less errors/workarounds needed in the Workflow Builder
Is this an external customer request?
No
Is there a competitive software package that has this feature or solution that we should be aware of?
No
Will this impact a renewal, expansion, or adoption at a customer, and does this put an account at risk if we do not address this?
No--it's just streamlining/improving the user experience.
