{"id":160,"date":"2010-04-11T16:05:41","date_gmt":"2010-04-11T15:05:41","guid":{"rendered":"http:\/\/csopro.de\/biblog\/2010\/04\/temporaere-tabellen-in-ssis-verwenden\/"},"modified":"2010-04-11T16:05:41","modified_gmt":"2010-04-11T15:05:41","slug":"temporaere-tabellen-in-ssis-verwenden","status":"publish","type":"post","link":"https:\/\/www.csopro.de\/biblog\/2010\/04\/temporaere-tabellen-in-ssis-verwenden\/","title":{"rendered":"tempor\u00e4re Tabellen in SSIS verwenden"},"content":{"rendered":"

F\u00fcr manche Aufgaben erscheint es sinnvoll, Daten zun\u00e4chst in tempor\u00e4re Tabellen zu \u00fcbertragen, um sie dann zum Beispiel per Insert oder Update in die Zieltabelle zu \u00fcberf\u00fchren (damit kann man ein „Bulk Update“ durchf\u00fchren).<\/p>\n

Dazu kann man nat\u00fcrlich im SQL-Server beliebige Tabellen anlegen, die dann nur „logisch“ tempor\u00e4r sind, da sie ja st\u00e4ndig in der Datenbank sind.<\/p>\n

Der SQL Server bietet aber auch tempor\u00e4re Tabellen an, die sessionweit (# – sobald die Connection geschlossen wird, verschwindet die Tabelle) oder global (## – sobald die letzte Connection geschlossen wird, die diese Tabelle verwendet, verschwindet sie) gelten.<\/p>\n

Diese in SSIS zu verwenden, mag z.B. Sinn machen, wenn man keine Tabellen-Erstellungs-Rechte auf dem Zielserver hat.<\/p>\n

Sie zu verwenden, ist nicht ganz einfach:<\/p>\n

Nehmen wir an, wir wollen eine tempor\u00e4re Tabelle mit einer einzigen numerischen Spalte anlegen, so geht das so:<\/p>\n

\n

\nCREATE TABLE [dbo].[#ZielTabelle]
\n(
\n[zahl] [int] NOT NULL
\n)<\/p>\n

Randbemerkung:
<\/u>Man kann auch Primary Keys vergeben, z.B. mit folgendem Statement:<\/p>\n

\n

CREATE TABLE [dbo].[#ZielTabelle]
\n(
\n[zahl] [int] NOT NULL,
\nCONSTRAINT ZielTabelle_PK PRIMARY KEY CLUSTERED
\n(
\n[zahl] ASC
\n)
\n)<\/p>\n<\/blockquote>\n

Das w\u00e4re aber nicht so gut, da dann ein Vorteil verloren geht: Eine solche tempor\u00e4re Tabelle (#) kann mehrfach existieren (je Connection einmal). Verwendet man aber einen festen Primary-Key-Namen, so geht das nicht mehr. Man k\u00f6nnte in den Namen des Primary Key eine GUID einbauen und h\u00e4tte wieder Eindeutigkeit.<\/p>\n<\/blockquote>\n

Dieses Create-Table-Statement baut man in eine Execute-SQL-Task und kann dann folgenden Workflow abbilden:<\/p>\n

\"Workflow\"<\/p>\n

Den DROP TABLE braucht man nicht unbedingt, da nach Schlie\u00dfen der Connection die Tabelle eh verschwindet. Aber aus Gr\u00fcnden der Hygiene empfehle ich es.<\/p>\n

Unser Datenflusstask soll im Beispiel einfach alle Zahlen von 1 bis 10 in die tempor\u00e4re Tabelle schreiben:<\/p>\n

\"DataFlow\"<\/p>\n

Die Skript-Komponente hat folgenden Code:<\/p>\n

\n

public override void CreateNewOutputRows()
\n{
\nfor (int i = 1; i <= 10; i++)
\n{
\nAusgabeBuffer.AddRow();
\nAusgabeBuffer.Zahl = i;
\n}
\n}<\/p>\n<\/blockquote>\n

Nun haben wir aber ein Problem: Die temp-Tabelle taucht nicht in der Liste der Tabellen auf. Deswegen empfiehlt es sich, auf dem Entwicklungsrechner eine Tabelle mit der selben Struktur anzulegen, und diese dann auszuw\u00e4hlen (hier „ZielTab_gibtsNetProduktiv“):<\/p>\n

\"Ziel\"<\/p>\n

Nun kann man auf dem n\u00e4chsten Reiter die Zuordnungen – wie gewohnt – einstellen (was in diesem Beispiel sehr einfach ist \ud83d\ude42 ):<\/p>\n

\"Zuordnungen\"<\/p>\n

Noch haben wir aber nichts gewonnen, da die tempor\u00e4re Tabelle nicht verwendet wird.<\/p>\n

Es m\u00fcssen deshalb noch ein paar Einstellungen vorgenommen werden:<\/p>\n