Tag: "t-sql"
Determinismus von CHARINDEX und PATINDEX
In BOL werden CHARINDEX() und PATINDEX() als nichtdeterministische Stringfunktionen aufgelistet. Warum eigentlich? Man sollte meinen, das ceteris paribus auch bei diesen Funktionen stets ein identisches Ergebnis herauskommt. Richtig, und gleichzeitig nicht! Der Grund, warum beide Funktionen als nichtdeterministisch geführt werden, findet sich dann in den Erklärungen zu PATINDEX():
Daten aus Excel abfragen
In fast allen Online Communities sieht man solche Fragen mit schöner Regelmässigkeit auftauchen. Die vielleicht einfachste Methode, diese Daten abzufragen, besteht in der Verwendung von OPENROWSET:
Dynamisches SQL innerhalb einer Funktion
Dynamisches SQL kann nicht innerhalb einer Funktion ausgeführt werden. Genausowenig können Stored Procedures aufgerufen werden. Der einzige Workaround hier ist, eine andere Logik anzuwenden, um um den dynamischen Teil herumzukommen. So führt z.B. folgendes zu einem Fehler:
Sequentielle Nummerierung eines Resultsets
Eine beliebte Frage mit unzähligen Antworten. Meine Lieblingsantwort darauf ist, dies in der Präsentationsschicht seiner Anwendung zu machen. IMHO ist dies Aufgabe des Clients, nicht des Servers. Wenn es aber unbedingt in T-SQL gemacht werden soll, kann man folgendes machen:
USE PUBS
GO
SELECT
(
SELECT COUNT(*)
FROM Authors
WHERE au_id <= A.au_id
) AS Lfd_Nr
, au_lname, au_fname
FROM
Authors AS A
ORDER BY
Lfd_Nr
GO
Lfd_Nr au_lname au_fname
----------- ---------------------------------------- --------------------
1 Hello World Johnson
2 Green Marjorie
3 Carson Cheryl
4 O'Leary Michael
5 Straight Dean
6 Smith Meander
7 Bennet Abraham
8 Dull Ann
9 Gringlesby Burt
10 Locksley Charlene
11 Greene Morningstar
12 Blotchet-Halls Reginald
13 Yokomoto Akiko
14 del Castillo Innes
15 DeFrance Michel
16 Stringer Dirk
17 MacFeather Stearns
18 Karsen Livia
19 Panteley Sylvia
20 Hunter Sheryl
21 McBadden Heather
22 Ringer Anne
23 Ringer Albert
(23 row(s) affected)
Bei umfangreichen Resultsets kann die obige Methode schon mal einige Zeit in Anspruch nehmen. Ist also nur bedingt empfehlenswert. Eine Alternative ist vielleicht die Verwendung der IDENTITY Funktion zusammen mit einer temporären Tabelle, so wie hier:
SELECT
IDENTITY(INT,1,1) AS Lfd_Nr
, au_lname
, au_fname
INTO #authors
FROM authors
ORDER BY au_id
SELECT *
FROM #authors
ORDER BY Lfd_Nr
DROP TABLE #authors
Lfd_Nr au_lname au_fname
----------- ---------------------------------------- --------------------
1 Hello World Johnson
2 Green Marjorie
3 Carson Cheryl
4 O'Leary Michael
5 Straight Dean
6 Smith Meander
7 Bennet Abraham
8 Dull Ann
9 Gringlesby Burt
10 Locksley Charlene
11 Greene Morningstar
12 Blotchet-Halls Reginald
13 Yokomoto Akiko
14 del Castillo Innes
15 DeFrance Michel
16 Stringer Dirk
17 MacFeather Stearns
18 Karsen Livia
19 Panteley Sylvia
20 Hunter Sheryl
21 McBadden Heather
22 Ringer Anne
23 Ringer Albert
(23 row(s) affected)
In SQL Server 2005 ist dies übrigens einfacher durch die Implementierung von ROW_NUMBER().
Dynamisches SQL : Fluch und Segen
Original von Erland Sommarskog; deutsche Übersetzung von Frank Kalis
Wenn Sie die verschiedenen Newsgroups über Microsoft SQL Server verfolgen, wird Ihnen auffallen, dass häufig Fragen gestellt werden, warum die Statements:
SELECT * FROM @tablename
SELECT @colname FROM tbl
SELECT * FROM tbl WHERE x IN (@list)
nicht funktionieren.
Kleines Beispiel über DECIMAL und FLOAT
Oftmals fragt man sich, wann DECIMAL und wann FLOAT verwendet werden soll; bzw. ob und wenn Ja, wofür FLOAT überhaupt verwendet werden soll. Eine allgemeingültige verbindliche Antwort hierauf gibt es wahrscheinlich nicht. Vielmehr hängt dies von den jeweiligen Anforderungen ab. Festhalten lässt sich aber, daß überall dort, wo ein hoher Anspruch an Genauigkeit bei Zahlen und Berechnungen herrscht, DECIMAL verwendet werden sollte. Genaugenommen fällt mir jetzt nur ein Gebiet ein, wo FLOAT eher angebracht scheint: Astronomie, bzw, überall dort, wo mit extrem grossen oder kleinen Zahlen gerechnet wird.
