So, we have a simple deployment pipeline. 2 stages: 'Test' and 'Production'. We use it for dataflows accessible by all staff.
Obviously (but I'll explain for clarity), we create the dataflow in 'Test' and deploy it to production when it's all tested and ready. We also use the 'Test' workspace to makes adjustments to dataflows that are then pushed to 'Production'.
We have a simple dataflow for dates called 'DateTable'. It calculates things like yearly quarters, financial quarters, day of the week (Monday, Tuesday etc), number of the week (1 for Sunday, 2 for Monday etc), so that people can simply pull this into their semantic models instead of having to do any time/date related calculations themselves. It connects to a single datasource (an sql database which is rarely touched and hasn't, just to be clear, been updated or changed) and just worked.
We rarely touch DateTable because we don't need to. It updates with new future dates every week and as dates and times in the past aren't famous for changing retroactively, it only gets touched when something is requested that it doesn't currently contain ('Any chance you could add in a column for what day this date last year was?' that type of thing).
Recently, we've had a couple of refresh failures and we've identified that DateTable seems to be the cause. When we went to investigate we noticed that in lineage view instead of being connected to 1 sql database it seems to be connected to 3 sql databases, the extra 2 we've never connected it to because there is literally no need (it's just dates!), and one of these databases doesn't even exist any more. This is causing us a problem (obviously) as we can't sever these connections because within the data model they don't exist. We tried updating credentials for all datasources to see if we could circumvent the issue by ignoring it ('Sure, these connections shouldn't exist, but maybe we ignore that and just connect to them anyway') but obviously this doesn't work for the database that no longer exists.
Oddly, the dataflow itself still updates fine, but other things connected to it don't.
I hit on the idea to simply deploy the Test version we have to Production because they should be identical and am hit with an error message saying that it can't be deployed because:
Deployed items with the same name in the target and source stages are not bound. This may be due to recent actions, such as deleting or adding new items, still being in process.
And, now I'm out of ideas...actually, that's not true. The only idea I have left is to export the JSON and recreate the dataflow, but that comes with a whole bunch of downstream issues as this is our most used dataflow.
Is anyone able to tell me how and why our dataflow has magically acquired new connections (connections that don't exist in the data model) and why I can't deploy the test version?
