Klar, T-SQL ist Case-Insensitive. Mein SQL Statement ist syntaktisch korrekt, egal ob ich nun sELECT sElEcT, SELECT oder select schreibe. Jede dieser Varianten wird immer funktionieren. Auch bei Datenbank-, Schema-, Tabellen- und Spaltennamen ist der SQL Server tolerant, was die Benutzung der Shift-Taste betrifft (anders als das beispielsweise bei manchen MySQL-Installationen der Fall ist). Es ist dem SQL Server egal, ob ich die Tabelle [dbo].[Table1] oder die Tabelle [DBO].[TaBLE1] abfrage. Sofern eine Tabelle mit dem Namen „Table1“ im Schema „dbo“ existiert, wird die Abfrage ein Resultat liefern.
Um das zu veranschaulichen führen wir folgenden Test durch: wir erzeugen eine kleine Test-Tabelle mit einigen Einträgen, fragen diese Einträge ab und ändern bei einer der Spalten die Groß- und Kleinschreibung.
if OBJECT_ID(‚[dbo].[PlayingCases]‘) is not null
begin
drop table [dbo].[PlayingCases]
end
CREATE TABLE [dbo].[PlayingCases]
(
id int not null,
val varchar(10) not null
)
insert into [dbo].[PlayingCases]
(id, val)
values
(1, ‚first‘),(2,’second‘),(3,‚third‘)
select id, val from [dbo].[PlayingCases]
exec sp_rename ‚[dbo].[PlayingCases].[id]‘, ‚ID‘, ‚COLUMN‘
select id, val from [dbo].[PlayingCases]
Wie erwartet liefern beide Abfragen das selbe Resultat:
Jetzt wollen wir die Tabelle in SSIS verwenden. Dazu legen wir sie zunächst neu an und füllen sie wieder mit unseren drei Beispieleinträgen. Außerdem legen wir eine Zieltabelle für den Datenstransfer an:
CREATE
TABLE [dbo].[PlayingCases_Destination]
(
id int
not
null,
val varchar(10)
not
null
)
Jetzt legen wir im BIDS in einem neuen SSIS-Projekt einen einfachen Datenflusstask an, der die Daten aus PlayingCases nach PlayingCases_Destination transferiert. Der Source-Adapter sieht wie folgt aus:
Die Spalten sind dann die soeben neu angelegten:
Mit dem entsprechenden Zieladapter können wir nun den Datentransfer durchführen:
Benennen wir nun also wie oben die ID-Spalte der Quelltabelle um:
exec
sp_rename
‚[dbo].[PlayingCases].[id]‘, ‚ID‘, ‚COLUMN‘
Wenn wir jetzt das Paket neu ausführen, erhalten wir einen Fehler:
Wir haben zwar die Metadaten des Quell-Objekts verändert, da die Spaltennamen aber nicht case-sensitiv sind, hätten wir erwartet, dass die Änderung der Groß- und Kleinschreibung eines Spaltennamens keine Auswirkungen auf die Lauffähigkeit der Pakete hat. Pakete können tolerant gegen eine Veränderung der Cases der Spaltennamen gemacht werden, indem man in der Quelle ein SQL-Statement angibt, das alle Spalten auflistet.
Es empfielt sich deshalb die SSIS Best practice zu befolgen, dass man nur Spalten in Datenflüsse lädt, die im Datenfluss auch verwendet werden und diese im Quellstatement explizit benennt und sich von vorne herein auf Naming Conventions für Datenbankobjekte zu einigen und diese auch einzuhalten, damit bei eventuellen Korrekturen nicht an unerwarteter Stelle Probleme auftreten.