none
SSIS: Wie suche ich in einer Spalte am besten nach einem Ausdruck eines Verweisdataset

    Frage

  • Ist wahrschenlich banal:

    Aber wie suche ich am geschicktesten einen Ausdruck (z.b.eine Auftragsnummer 'A12345690') in einer SPalte  einer anderen Tabelle ("Auftragsbestätigung zu A12345690") ? Ich möchte dann den Verweisschlüssel der zweiten Tabelle anderweitig nutzen.

    Die Lookup-Transformation  scheint mir ungeeignet.

    Samstag, 24. August 2013 21:55

Alle Antworten

  • ("Auftragsbestätigung zu A12345690")

    Ist das der Inhalt der Spalte??
    Oder nur "A12345690"?

    Warum geht das mit Lookup nicht? genau dafür wäre es da.

    Wenn die Tabelle oberes enthält, sollte man das Design nochmals überdenken, die Spalte in eine eigene Spalte überführen, um dann genau mit diese Techniken, für die relationale Datenbanken optimiert sind, zu arbeiten. Notfalls hilft auch eine calculated column + Lookup bis zur Behebung.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Sonntag, 25. August 2013 13:59
  • Okay, ich glaube ich habe mich unklar ausgedrückt:

    Die Spalte IN der gesucht werden soll enthält den kompletten Verwendungszweck einer Bankbuchung.

    Also eben NICHT nur A12345690, sondern mehr Text "Gutschrift fuer A12345690. Danke schoen" - oder so ähnlich.

    Eine Gleichheitssuche geht also leider nicht.

    Es müsste also irgednwas mit "LIKE '%A12345690%" herauskommen.

    Ich habe zwar etwas gelesen, dass man in der Lookup-Komponente die SQL-Anweisung ändern kann, aber es wurde auch ausrücklich davor gewarnt dies zu tun - stimmt auch, schon probiert :-)

    Die Ausdruckssuche scheint sich mehr auf Volltexte zu beziehen und nimmt sich eher richtige Wörter vor.

    Montag, 26. August 2013 12:36
  • ..

    Also eben NICHT nur A12345690, sondern mehr Text "Gutschrift fuer A12345690. Danke schoen" - oder so ähnlich.

    ...

    Es müsste also irgednwas mit "LIKE '%A12345690%" herauskommen.

    Ich habe zwar etwas gelesen, dass man in der Lookup-Komponente die SQL-Anweisung ändern kann, aber es wurde auch ausrücklich davor gewarnt dies zu tun - stimmt auch, schon probiert :-)

    Die Ausdruckssuche scheint sich mehr auf Volltexte zu beziehen und nimmt sich eher richtige Wörter vor.

    Ach sooo. Das war nur ein Beispiel für versch. Varianten. Dann ist es in der Tat nicht ganz so simpel.

    Natürlich kann man sich mit LIKE bzw mit SUBSTRING und PATINDEX eine Expression bauen, die nach einer Zeichenfolge mit bestimmter Länger oder Muster sucht, diese in eine eigene Spalte extrahieren und dann vorgehen wie vorgeschlagen.

    Das geht aber nur, wenn der Aufbau wirklich eine feste, verlässliche Struktur hat.

    Warum man bei der Lookup Komponente den Ausdruck nicht ändern soll, ist mir jetzt ein Rätsel. Im Gegenteil: Wem Performance irgendwie wichtig ist, der SOLLTE das tun. Wenn es komplex wird, kann man sogar eine Prozedur hinterlegen. Aber das ist nicht direkt Thema.

    Wirklich Spaß macht das mit SUBSTRING/PATINDEX aber nicht. Daher würde ich Dir empfehlen, diese Spalte mit einer Script-Transformation mithilfe von VB.net/C#-net und regex zu verarbeiten und das Output in einer Hilfsspalte zu speichern - um also letztlich die Daten für weitere Verarbeitung (joinen) zu normalisieren . On the fly würde ich das nicht machen, da es einfach unsauber und schwer nachvollziehbar ist.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Montag, 26. August 2013 13:02
  • Hmmm. Ich hatte eigentlich mehr an den  simple-trick gedacht.

    Dabei müsste doch genau dieses Problem ein STandard-Problem in der Datenbank-Technik sein. "Finde @Par1 als Substring von [columnx]"

    Montag, 26. August 2013 13:07
  • Hmmm. Ich hatte eigentlich mehr an den  simple-trick gedacht.

    Dabei müsste doch genau dieses Problem ein STandard-Problem in der Datenbank-Technik sein. "Finde @Par1 als Substring von [columnx]"

    Aber @Par1 ist ja nicht statisches in Deinem Fall. Mal ist es A123, mal A234. Daher musst Du es extrahieren. Wie gesagt, mit SUBSTRINGT und PATINDEX.

    Was Du da hast, liegt nicht in normalisierter Form vor. Relationale Datenbanken leben davon, das man Relationen zwischen normalisierten Entitäten aufbaut. Wenn man das nicht tut, leidet man automatisch früher oder später Schmerzen...

    Daher, wie oben aufgezeigt, in eine relationale Form überführen, dann ist es easy mit dem Joinen.

    Die reine Suche ist mit LIKE '%[a-z][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]%' auch machbar.. aber das langt für diese Anforderung nunmal nicht aus.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Montag, 26. August 2013 13:20
  • Okay, die Geschichte mit SUBSTRING und PATINDEX hat funktioniert.

    Die Abfrage, welche die Buchungen liefert, generiert jetzt eine zusätzliche Spalte mit den Rechnungsnummern. Diese sind weitgehend homogen:

    Die Ausgabe ist als DWSTR

    Liefert momentan mit Eingrenzung 44 Zeilen

    demgegenüber steht das Verweisdataset, das momentan 194 Zeilen liefert.

    Leider landen dennoch alle Zeilen aus der Eingabe (44) im Ausgang für nicht-übereinstimmende Zeilen.

    Der generierte SQL-Code lautet:

    select * from (SELECT        RechCode, ValidityDate, DatensatzID, Amount
    FROM            qry_Extrahierte_Rechnungsnummern
    WHERE        (NOT (RechCode IS NULL))) [refTable]
    where [refTable].[RechCode] = ?

    Kann ich diesen Parameter irgendwie einsehen oder sonstwie dem Fehler auf die Spur kommen ?

    Dienstag, 27. August 2013 18:49
  • Lass Dir doch mal in einem Dataviewer die Daten anzeigen, wenn nicht schon direkt in der Quelle.

    DT_WSTR ist sicher gemein. Also Unicode. Das sollte aber nicht das Problem sein.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Dienstag, 27. August 2013 19:37
  • Habe ich schon.

    Im Eingang kommen eben die 44 Zeilen

    Das Verweisdataset ergibt eben besagte 194 Zeilen, auch per Vorschau ansehbar.

    DataViewer sind im Zweig für übereinstimmende und nicht-übereinstimmende installiert.

    Bei den nicht-übereinstimmenden Zeilen kommen alle 44 Zeilen an , im anderen Zweig eben 0!

    Nur wieso ?

    Die zu vergleichenden Spalten sind beide DWSTR

    Dienstag, 27. August 2013 19:47
  • Dafür kann es diverse Gründe geben.

    Da ich nicht dabei zusehen kann, würde ich mal versuchen, es direkt über T-SQL zu Joinen - und sehen, was dabei herauskommt.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Mittwoch, 28. August 2013 11:28