Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

4. Juli 2006 um 17:22

Intellisense für SQL-Statements

Am Sonntag entdeckt und gleich installiert: Seit gestern habe ich echtes Intellisense für SQL-Statements im Query Analyser und im SQL Server Management Studio: SQL Prompt. Unglaublich, aber es funktioniert tatsächlich. Man muss dem Werkzeug lediglich nach und nach die verschiedenen Connectons beibringen, dann saugt es sich die kompletten Meta-Daten der aktuellen Datenbank rein und los gehts.

SQL Prompt

Leider klappt das bei unseren Standard-Datenbanken nicht. Wir haben so abgedrehte Namen wie "d:\firma\daten\anwendung\data\standard\ua" für unsere Datenbanken. (Das klingt schlimmer als es ist und hat für uns unbestreitbare Vorteile, sonst hätten wir das nicht gemacht.) Entweder ist er Name zu lang oder das Tool kommt mit den Sonderzeichen nicht zu recht… Es geht jedenfalls nur mit Datenbanken mit "normalen" Namen, wie "blabla" oder "Northwind".

In der einer Begrüßungsmail bekam ich (vom Absender "sales@…") die Info, dass sie für jedes Kundenfeedback dankbar sind. Ich bin ja mal gespannt, ob sie auf den Hinweis mit den Datenbanknamen tatsächlich dankbar reagieren… 😉

Ich sehe gerade, dass das Werkzeug nur bis zum 1.9.2006 kostenlos erhältlich ist (man muss sich registrieren und bekommt dann eine Begrüßungsmail). Also dann mal ran…

4. Juli 2006 um 17:18

explicit collations in cross database statements

Gestern hatten wir wieder den Fall, dass ein Lieferant in die Collation-Falle getappt ist. Sie legen eine temporäre Tabelle an und verjoinen sie mit einer Tabelle in deren Datenbank. Weil aber die TempDB (in der die temporäre Tabelle liegt) unter Umständen eine andere Default Collation hat als die Anwendungsdatenbank und bei den Create Table-Statement nichts weiter angegeben wurde, haben die Varchar-Felder der Tabellen potentiell unterschiedliche Collations.

Das führt zu dem bekannten Fehler:

Konflikt der Sortierung für die concatenation-Operation kann nicht aufgelöst werden.

Die Lösung ist ganz einfach und sollte generell eingesetzt werden, wenn man Software auf SQL Servern betreibt, die man sich mit anderen Anwendungen teilt: Man muss bei allen Operationen mit Char/Varchar/nchar/nvarchar-Typen explizit angeben welche Collation für Vergleichsoperationen verwendet werden soll. Dann ist für den SQL Server klar, wann die Zeichenketten "gleich"/"größer"/"kleiner" sind. Wenn nicht, woher soll er wissen, anhand von welcher Collation er das festlegen soll?

Die Lösung im Falle von temporären Tabellen ist noch einfacher: Es reicht wenn man beim Anlegen der Tabellen von Char/Varchar/nchar/nvarchar-Typen explizit angibt, welche Collation verwendet werden soll. Wenn man hier die gleiche Collation wählt, wie in seiner Anwendungsdatenbank, dann kann nichts schiefgehen:

create table #MyTempTab
(id integer identity(1,1) primary key,
name varchar(200) COLLATE Latin1_General_CI_AS, ...)

Das gilt übrigens auch für Table-Variablen, weil auch sie in der TempDB gespeichert werden:

declare @MyTableVar table
(id integer identity (1,1),
name varchar(200) COLLATE SQL_Latin1_General_Pref_CP1_CI_AS)

Eine andere Möglichkeit für das Anlegen der temporären Tabelle ist einfach SELECT INTO zu verwenden, auch dann wird die Collation der Quell-Attribute beibehalten.

select id, name
into #mytemptable
from Me.MyTestTable

Weitere Hinweise stehen in der Online-Hilfe des SQL Servers unter "Transact-SQL Reference | Collate" und "Transact-SQL Reference |Collation Precedence".

|