Normalerweise würde man solche Fragestellungen. welcher Dezimalzahl nun 1011001 entspricht, damit beantworten, in dem man auf den Client verweist. Was aber, wenn man einfach wissen will, wie so etwas in T-SQL aussehen könnte? Ob man es dann später einsetzt, ist ja eine andere Sache:
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():
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 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:
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().
Die Anforderung, zufällig ausgewählte Datensätze zurückzugeben, findet man recht häufig. Analyse einer Stichprobe ist eine wahre Spielwiese für Statistiker. In T-SQL kann dies recht einfach umgesetzt werden.