I'm interested in the topic of workarounds on this as well. But first, Ben: can you elaborate more what you mean by "I can do 1x level of dependent SQL input queries, where 1 dropdown list is dependant upon selection from a parent dropdown list". Are you saying you can reference a '${userInputVar}' varaible in your SQL for a Table Column of Type Query? I ask because I thought the issue was you basically can not make 'any' outside references to other UI variables in the same table or elsewhere of any other UI fields of any type (string, enum, etc). That's what I think I was seeing.
As for workarounds, there could be some topic-specific work arounds. If folks share what they're trying to do with their table input, we could all share workaround ideas.
In the case I'm thinking of (filling out a table of info to create SVM LIFs ... like IP, home-port, etc) the only work around I can envision is to just NOT ask the user for certain information and have workflow logic that auto-determines what you originally envisioned as a dependent-SQL Query. That's not easy in many cases with multiple nodes, ports and VLANs.
FWIW EDIT:
... for clarity, I attached this dar file which is the simplest workflow to demo the problem. Look at the Table column to select an aggregate. I'd like it only show certain aggregates (those whose name contains the operator selected string), but because the attempt to reference another UI variable doesn't work, it has to list all aggregates. I've commented out the WHERE clause that doesn't work properly at execution (it works in test-mode). Un-comment to see the problem.
