Am Microsoft SQL Server gibt es drei offizielle Arten von temporären Tabellen, aber tatsächlich sind es sogar fünf. Je nach Art der Verwendung findet sich leicht etwas passendes.<\/p>\n
sitzungsbezogene temporäre Tabellen<\/strong><\/p>\n Die lokale Tabelle wird direkt in einer Session angelegt. Beispiel:<\/p>\n lokale temporäre Tabellen<\/strong><\/p>\n Die lokale Tabelle wird in einer Stored-Procedure (oder einem anderen Gültigkeitsbereich) angelegt. Die Syntax ist genau wie beim obigen Beispiel.<\/p>\n globale temporäre Tabellen<\/strong><\/p>\n Bei der globalen Tabelle ist es egal in welchem Gültigkeitsbereich sie angelegt, wird. Sie kann in allen Stored-Procedures und Funktions zugegriffen werden. Für die Syntax anbei noch ein Beispiel:<\/p>\n In der Praxis finde ich diese Art der Tabellen sehr unpraktisch und würde von deren Verwendung abraten. Was hat man davon, wenn die Existenz der Tabelle so stark mit der anlegenden Verbindung zusammenhängt, dann wäre doch die sitzungsbezogene temporäre Tabelle deutlich verständlicher.<\/p>\n (normale) Tabelle in TempDB<\/strong><\/p>\n Bei der normalen Tabelle in der TempDB muss man das Recht haben Tabellen anzulegen, also z.B. SysAdmin oder DdlAdmin in der TempDB sein. Für die Syntax wieder ein Beispiel:<\/p>\n Rechte in der Praxis<\/em><\/p>\n 1. Möglichkeit: Man kann die Benutzer, die diese Tabellen anlegen dürfen als User in der TempDB anlegen. Dass muss man allerdings nach jedem Server-Start machen, weil da die TempDB gelöscht und neu aus einer Kopie der Model-Datenbank angelegt wird. Diese Benutzer bekommen dann das Recht "CREATE TABLE". Dazu könnte man sich eine Autostart-Prozedur anlegen, die die anzulegenden User aus einer eigens dafür anzulegenden Tabelle liest und anlegt. Tabellenvariablen<\/strong><\/p>\n Und dann gibt es da noch die Tabellenvariablen. Sie funktionieren im Grunde fast genau wie lokale temporäre Tabellen<\/p>\n Collate in der Praxis<\/em><\/p>\n In obigen Beispielen habe ich immer die Collation angegeben. Das ist immer dann wichtig, wenn ich nicht sicher davon ausgehen kann, dass sie Server-Default-Collation mit der Collation in "meiner" Datenbank übereinstimmt. Da temporäre Tabellen in der TempDb angelegt werden, wird für Zeichenketten automatisch die Default-Collation des Servers verwendet, wenn es nicht anders angegeben wird.<\/p>\n","protected":false},"excerpt":{"rendered":" Am Microsoft SQL Server gibt es drei offizielle Arten von temporären Tabellen, aber tatsächlich sind es sogar fünf. Je nach Art der Verwendung findet sich leicht etwas passendes. sitzungsbezogene temporäre Tabellen Die lokale Tabelle wird direkt in einer Session angelegt. Beispiel: create table #localtable( id integer identity(1,1) not null primary key, f nvarchar(100) collate Latin1_General_CI_AS […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/444"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=444"}],"version-history":[{"count":0,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/444\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=444"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=444"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=444"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}create table #localtable(
\n\tid integer identity(1,1) not null primary key,
\n\tf nvarchar(100) collate Latin1_General_CI_AS not null
\n);<\/code><\/p>\n\n
\nErst nach dem Ende der Verbindung wird die Tabelle automatisch entfernt. Es sei denn sie wird vorher explizit mit einem DROP-Befehl entfernt.<\/li>\n\n
\nNach dem Ende der Prozedur wird die Tabelle automatisch entfernt. Es sei denn sie wird vorher explizit entfernt.<\/li>\ncreate table ##globaltable(
\n\tid integer identity(1,1) not null primary key,
\n\tf nvarchar(100) collate Latin1_General_CI_AS not null
\n);<\/code><\/p>\n\n
create table tempdb.dbo.mytable(
\n\tid integer identity(1,1) not null primary key,
\n\tf nvarchar(100) collate Latin1_General_CI_AS not null
\n);<\/code><\/p>\n\n
\nNach dem Anlegen der Tabelle muss dann der Benutzer die Rechte auf die Tabelle explizit vergeben. Das alles ist umständlich und erfordert jede Menge Aufwand. Dafür ist es "nach Vorschrift": Jeder hat nur so viele Rechte, wie er benötigt.
\n2. Möglichkeit: Man gibt der Gruppe Public in der TempDB das Recht "CREATE TABLE". Auch hier schlage ich eine Autostart-Prozedur vor. Die anzulegenden Tabellen nennt man "tempdb.guest.DECLARE @MyTempTable table (
\n id integer identity(1,1) not null primary key,
\n\tf nvarchar(100) collate Latin1_General_CI_AS not null);<\/code><\/p>\n\n