Manchmal sind es beim Troubleshooting nicht die komplizierten Dinge, die einen lange beschäftigen, sondern die einfachen Dinge, die man zu spät überprüft.
Genau so einen Fall hatte ich vor Kurzem bei einem Kunden. Am Ende konnten wir das Problem lösen und gleichzeitig landete ein neuer Punkt auf meiner persönlichen Troubleshooting-Checkliste:
Wenn ein On-premises Data Gateway beteiligt ist, zuerst die tatsächlich installierte Version prüfen.
Das Problem
Der Kunde wollte Daten aus einem lokalen SQL Server mit einem Dataflow Gen2 in Microsoft Fabric laden und anschließend in einem Lakehouse speichern.
Der Zugriff auf die Datenquelle funktionierte zunächst problemlos. Die Daten konnten im Power Query Editor angezeigt und transformiert werden.
Das Problem trat erst bei der Konfiguration des Ziels auf. Dort erschien die Fehlermeldung:
„There was a problem validating the destination. Please try again.“
Leider ist diese Meldung relativ generisch und gibt wenig Aufschluss darüber, wo die eigentliche Ursache liegt.
Also begann das klassische Troubleshooting: Einstellungen vergleichen, verschiedene Konstellationen testen und Stück für Stück mögliche Ursachen ausschließen.
Begleitet von den vermutlich jedem bekannten Aussagen:
„Ja, das habe ich auch schon probiert.“
„Bei meiner Kollegin funktioniert ihre Quelle.“
„Das Gateway aktualisieren wir monatlich. Das macht inzwischen die IT.“
Dabei geht es mir ausdrücklich nicht um Schuldzuweisungen. Im Gegenteil, gerade beim Troubleshooting zeigt sich immer wieder, wie sinnvoll zwei alte Grundsätze sind:
Vertrauen ist gut, Kontrolle ist besser. Und vier Augen sehen mehr als zwei.
Der entscheidende Hinweis: das Data Gateway
Während unserer Tests fiel uns irgendwann ein interessantes Verhalten auf:
Solange im Dataflow keine lokale Datenquelle über das On-premises Data Gateway verwendet wurde, ließ sich das Lakehouse als Ziel konfigurieren.
Sobald das Gateway ins Spiel kam, trat das Problem auf.
Damit rückte die Gateway-Version in den Fokus.
Die installierte Version war offenbar noch nicht so alt, dass grundsätzlich keine Verbindung mehr möglich gewesen wäre. Genau das machte die Fehlersuche so verwirrend. Der Zugriff auf den lokalen SQL Server funktionierte schließlich.
Nach dem Update des Gateways funktionierte jedoch auch die Konfiguration des Lakehouse-Ziels.
Warum das Verhalten so verwirrend war
Besonders interessant fand ich, dass das Problem nicht bereits beim Zugriff auf die Quelle sichtbar wurde.
Der Dataflow konnte:
- auf den lokalen SQL Server zugreifen,
- die Daten anzeigen,
- die Daten im Power Query Editor transformieren.
Erst beim Speichern der Daten in das Lakehouse trat das Problem auf.
Dadurch lag der Verdacht zunächst natürlich eher beim Ziel als beim Gateway der Quelle.
Zusätzlich gab es noch einen weiteren Effekt: Wurde das Default Lakehouse bereits als Ziel konfiguriert, bevor die lokale Gateway-Quelle zum Dataflow hinzugefügt wurde, konnte diese Konstellation teilweise weiterhin verwendet werden.
Wir haben während der Analyse also einiges über das konkrete Verhalten dieser Kombination gelernt.
Ob diese Details in einigen Monaten noch relevant sind, weiß ich nicht. Microsoft Fabric entwickelt sich schnell weiter und auch das On-premises Data Gateway wird regelmäßig aktualisiert.
Das eigentliche Learning ist für mich deshalb ein anderes.
Mein Learning für das nächste Troubleshooting
Wenn bei einem Dataflow Gen2 ein On-premises Data Gateway beteiligt ist und irgendwo unerwartete oder wenig aussagekräftige Fehler auftreten:
Nicht nur fragen, ob das Gateway regelmäßig aktualisiert wird – die tatsächlich installierte Version prüfen.
Eine funktionierende Verbindung zur Quelle bedeutet nicht zwangsläufig, dass die eingesetzte Gateway-Version mit allen Funktionen kompatibel ist, die anschließend im Dataflow verwendet werden.
Und genau deshalb steht bei mir beim nächsten vergleichbaren Problem ziemlich weit oben auf der Liste:
Welche Gateway-Version ist eigentlich installiert?
Vielleicht erspart dieser kleine Hinweis jemandem bei der nächsten Meldung „There was a problem validating the destination“ ein paar Stunden Troubleshooting.
