Forum Discussion
Memorable MemberWhich focused table when editing/opening a gen2 dataflow?
In the service when I open a gen2 dataflow for the first time I'm constantly bitten by the experience. The first thing PBI wants to do is kick off a long-running refresh to an API (web connector). There is no way to stop it.
How do I deterimine which table will be focused when the gen2 dataflow editor is first opened?
...
<RantBegin>
As stated I cannot seem to figure out which table it wants to refresh when the dataflow is first opened. No matter what I do, it seems to jump to the worst possible table in the dataflow and start refreshing that one. I've tried reordering, and creating other tables to tempt the service to focusing on something else. However the editer always decides to ignore the other tables and put the initial focus on the longest-running table refresh that it can find.
I've also tried organizing tables into folders, and tucking away the bad table in a place where it can't be found. That doesn't work either.
Can someone please tell me the rules used in the PBI dataflow editor decides to place focus on a table? It is totally obnoxious that the editor will focus on an arbitrary element of the dataflow. It is even worse that we are unable to prevent the editor from launching random refresh operations on each mouse-click or keyboard-press. The only reliable way to manage our dataflows is to turn off the on-prem gateway for the majority of the time, and then turn it on again when I want to be flooded by uncontrollable and random queries.
</RantEnds>
3 Replies
- GilbertQ
Super User
Hi dbeavon3
I think based on my experience this happens to always keep the first table that was created. The only thing I can think of is to use a parameter to not return all the information from your table. This is so that when the dataflow opens it will only get a subset of the data?
dbeavon3Hi GilbertQ
The parameter option is pretty good, however the most problematic environment is production. In production we aren't using a subset of data. In the chance that we need to open the dataflow in production for review or for troubleshooting, then it will send an uncontrollable torrent of queries to our back-end systems. (Everybody hates it when PBI developers are opening their datasets and dataflows to review something in production.)
...On that note, you don't happen to know if PQ has ever introduced any sort of context/environment information that can be inspected to see if I'm in my "IT-DEV" workspace or in my "IT-PROD" workspace? This type of thing would greatly simplify some of these problems. I suppose your answer to that is to have a parameter for it, and manually edit it, every time we deploy from one environment to another.
IMO, PQ rarely seems to have features that most normal developers would expect. Thankfully I only spend about 5% of my time doing PQ development work but it is never fun or productive. It is not an "easy" software development experience either, whatever the product team may say, unless we happen to be working with something trivial like 100K rows of data or less.
