none
Probleme bei Änderungen im SSIS Datenfluss RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden
    Hallo,

    ich habe ein Problem (bzw. sehe ich es als solches), wenn ich einen Datenfluss modifiziere und dann von der Quelle bis zum Ziel alles neu anlegen muss, da die Metadaten nicht korrekt wieder verknüpft werden. Wenn ich einen bestehenden Datenfluss um Tabellenspalten erweitere oder diese lösche, muss ich die Tabelle im SQL Ziel neu anlegen; wenn ich hingegen nur einen Filter z. B. im SQL Statement bzw. Query setze, ebenfalls. Das verursacht stets sehr viel Aufwand, da ich die nachfolgenden Elemente immer erneut wieder anlegen darf.

    Im erweiterten Editor habe ich auch die "Aktualisieren" Taste betätigt, ändert trotzdem nichts.

    Gibt es eine Möglichkeit, diesen Mehraufwand zu vermeiden? Oder mache ich etwas in der Handhabung falsch?

    Danke für Eure Unterstützung,

    Gruß
    Jürgen
    Mittwoch, 15. Februar 2012 17:23
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Jürgen,

    Du hättest noch etwas den Aufbau des Packages beschreiben sollen (den ich "zufällig" kenne), damit man es nachvollziehen kann:
    Also ein Package mit einem Datenfluß-Task, dort eine "Ado.Net Datenquelle" für einen SQL Server, einen "Abgeleitete Spalte" Task und eine "Ado.Net Ziel", wieder ein SQL Server.

    Soweit kann ich das Verhalten nachvollziehen, sobald man in der Quelle in der SQL Abfrage nur einen Filter hinzufügt, werden für alle folgenden Tasks Fehler angezeigt, in der Fehlerliste steht dann eine solche Meldung

    Validation error. Datenflusstask: Datenflusstask: 'Eingabespalte 'AddressID' (73)' weist die Herkunfts-ID '294' auf, die noch nicht im Datenflusstask verwendet wurde.

    wobei in der Meldung immer nur das PrimaryKey Feld aufgeführt ist und die oben fett markierte ID sich bei jeder Änderung ebenfalls ändert. Von daher vermute ich mal, das bei jeder Änderung an der Ado.Net Quelle intern für den PK eine neue ID vergeben wird und die nicht in den weiteren Tasks mit geändert wird.

    Wenn Du dann aber auf "Edit" (Bearbeiten) oder "Advanced Editor" (Erweiterer Editor) gehst, kommt als erstes der Dialog "Restore Invalid Column References Editor" hoch. Wenn Du hier "Map using column name" auswählst, werden die fehlerhafte Referenzen über den Feldnamen automatisch wieder zugeordnet.
    In meinen Tests hat das bisher immer problemlos funktioniert.

    Bei OleDB Datenquellen habe ich das Problem bisher noch nie gehabt, zudem ist es performanter als Ado.Net in SSIS, da dieses immer noch und weiterhin Unmanaged Code ist. Auch wenn Du bisher keine Performanzprobleme hast, solltest Du alles von Ado.Net auf OleDB umstellen; Daten werden mit der Zeit immer mehr und das Package wird aus so immer länger laufen.

    Noch ein Tipp: In manchen Fällen ist es besser, als "Zwischenschicht" Views (Abfragen) für SSIS / SSAS zu verwenden. Dann kannst Du einfach nur die View ändern, ohne Anpassungen am BIDS Projekt vornehmen und diese neu deployen zu müssen.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    • Als Antwort markiert juergen_ks Mittwoch, 22. Februar 2012 18:45
    Dienstag, 21. Februar 2012 16:22
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Jürgen,

    Du hättest noch etwas den Aufbau des Packages beschreiben sollen (den ich "zufällig" kenne), damit man es nachvollziehen kann:
    Also ein Package mit einem Datenfluß-Task, dort eine "Ado.Net Datenquelle" für einen SQL Server, einen "Abgeleitete Spalte" Task und eine "Ado.Net Ziel", wieder ein SQL Server.

    Soweit kann ich das Verhalten nachvollziehen, sobald man in der Quelle in der SQL Abfrage nur einen Filter hinzufügt, werden für alle folgenden Tasks Fehler angezeigt, in der Fehlerliste steht dann eine solche Meldung

    Validation error. Datenflusstask: Datenflusstask: 'Eingabespalte 'AddressID' (73)' weist die Herkunfts-ID '294' auf, die noch nicht im Datenflusstask verwendet wurde.

    wobei in der Meldung immer nur das PrimaryKey Feld aufgeführt ist und die oben fett markierte ID sich bei jeder Änderung ebenfalls ändert. Von daher vermute ich mal, das bei jeder Änderung an der Ado.Net Quelle intern für den PK eine neue ID vergeben wird und die nicht in den weiteren Tasks mit geändert wird.

    Wenn Du dann aber auf "Edit" (Bearbeiten) oder "Advanced Editor" (Erweiterer Editor) gehst, kommt als erstes der Dialog "Restore Invalid Column References Editor" hoch. Wenn Du hier "Map using column name" auswählst, werden die fehlerhafte Referenzen über den Feldnamen automatisch wieder zugeordnet.
    In meinen Tests hat das bisher immer problemlos funktioniert.

    Bei OleDB Datenquellen habe ich das Problem bisher noch nie gehabt, zudem ist es performanter als Ado.Net in SSIS, da dieses immer noch und weiterhin Unmanaged Code ist. Auch wenn Du bisher keine Performanzprobleme hast, solltest Du alles von Ado.Net auf OleDB umstellen; Daten werden mit der Zeit immer mehr und das Package wird aus so immer länger laufen.

    Noch ein Tipp: In manchen Fällen ist es besser, als "Zwischenschicht" Views (Abfragen) für SSIS / SSAS zu verwenden. Dann kannst Du einfach nur die View ändern, ohne Anpassungen am BIDS Projekt vornehmen und diese neu deployen zu müssen.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    • Als Antwort markiert juergen_ks Mittwoch, 22. Februar 2012 18:45
    Dienstag, 21. Februar 2012 16:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    ich bin bislang davon ausgegangen, das die alten Datenflüsse gelöscht werden müssen, damit Sie beim Überarbeiten neu und korrekt wieder aufgebaut werden. Scheinbar funktioniert es nun dank Deines Vorschlages!

    Die ADO Verbindungen werde ich austauschen, da sie in der Tat nicht sehr performant sind.

    Besten Dank

    Gruß Jürgen

    Mittwoch, 22. Februar 2012 18:45
    |