MSSQL: dynamisches SQL mit nicht globaler TempTable

MSSQL: dynamisches SQL mit nicht globaler TempTable (19 Beiträge, 203 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hat jemand eine Ahnung, wie ich bei einem dynamischen SQL eine Table-Variable in die Session übergebe?

mit einer globalen temporären Tabelle funktioniert das Query einwandfrei, aber ich will mich nicht auch noch drum kümmern, auf Existenz der Tabelle abzufragen, die Tabelle anzulegen und sie danach noch zu droppen ... also gibts eine Möglichkeit, bei einem dynamischen SQL eine ganz normale @tmpTable zu übergeben?

my car @ Spritmonitor.de

na hat keiner eine Idee?

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Völlig abseits von MSSQL:

In manchen Datenbanken kannst CREATE TEMPORARY TABLE absetzen - die gilt dann nur in der Session und ist von aussen (also aus anderen Sessions) unsichtbar - natürlich dürfen unterschiedliche Sessions eine Temporary Table desselben Namens anlegen - und natürlich sind die dann unterschiedlich.

Könnte das deine Aufgabe lösen ? Den Check auf Tabellenexistenz bist dann los.

Alternativ:
Wahrscheinlich gibt's in MSSQL genauso Catalog-Tables, auf die Du losgehen kannst - dann könntest deiner stored Procedure den Tabellennamen als Varchar oder so übergeben und in der Procedure auf die Catalogs losgehen.

Oder es ist doch völlig anders in MSSQL

naja das Problem ist eher, dass das dynamische SQL in einer eigenen Session geöffnet wird und meine bereits vorhandenen temporären Tabellen nicht sichtbar sind!

deswegen muss man ja auch bei dyn. SQL die Variablen in die Session übergeben, allerdings gelingt mir das nicht mit Tabellen

die globalen temporären Tabellen (werden mit ##Variablennamen deklariert und nicht mit @Variablennamen) werden nicht im Speicher angelegt, sondern in der tempDB und deshalb sind sie auch in den anderen Sessions sichtbar! allerdings bleiben die Tabellen so lange bestehen, bis du den SQL-Dienst abdrehst oder du sie droppst ... und das möcht ich mir eben sparen ... weils aus Prinzip auch anders gehen muss

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Versteh' ich jetzt nicht...

naja das Problem ist eher, dass das dynamische SQL in einer eigenen Session geöffnet wird und meine bereits vorhandenen temporären Tabellen nicht sichtbar sind!

deswegen muss man ja auch bei dyn. SQL die Variablen in die Session übergeben, allerdings gelingt mir das nicht mit Tabellen

Du sagst also:
(i) dynamisches SQL in einer eigenen Session ist
(ii) temporäre Tabellen nicht aus fremden Sessions abrufbar sind
(iii) du Tabellen an dynamisches SQL übergeben willst

Also (ii) ist bei vielen RDBMS so - soweit ok.
Wenn aber die temporären Tabellen in einer anderen Session als das dynamische SQL sind (was immer das auch genau ist

) - und man auf temporäre Tabellen nicht aus fremden Sessions zugreifen kann - dann kann es gar nicht gehen, dass man die Tabellen übergibt (schließlich wären die dann nicht benutzbar

).

Wie wäre es, wenn du pro Session eine unique globale Temp-Table anlegst - zB mit der SessionID im Namen ? Und diese SessionID übergibst der stored Procedure ?

Aber wieso muss dynamisches SQL überhaupt in anderen Sessions laufen ? Was ist das überhaupt ? Und ... darfs denn das ?

Du sagst also:
(i) dynamisches SQL in einer eigenen Session ist
(ii) temporäre Tabellen nicht aus fremden Sessions abrufbar sind
(iii) du Tabellen an dynamisches SQL übergeben willst

genau ...

Wenn aber die temporären Tabellen in einer anderen Session als das dynamische SQL sind (was immer das auch genau ist ) - und man auf temporäre Tabellen nicht aus fremden Sessions zugreifen kann - dann kann es gar nicht gehen, dass man die Tabellen übergibt (schließlich wären die dann nicht benutzbar ).

doch, weil man bei dem Aufruf eines dynamischen SQL Variablen übergeben kann

das hier ist dynamisches SQL:

Declare @SQL nVarChar(1000) --N.B. string must be unicode for sp_executesql
SELECT @SQL = 'SELECT * FROM pubs.DBO.Authors WHERE au_lname = @AuthorName'

Exec sp_executesql @SQL, N'@AuthorName nVarChar(50)', @AuthorName = 'white'

hier wird zum Beispiel 'white' in die Session als Variable @AuthorName übergeben ... wenn ich jetzt in meiner jetzigen Session zB einen Cursor über den Authoren hätte, könnte ich anstatt 'white' auch eine Variable übergeben ...

ich benötige das dynamische SQL deshalb unbedingt, weil ich eine variable dynamisch verändere und das ist sonst nicht möglich!

Wie wäre es, wenn du pro Session eine unique globale Temp-Table anlegst - zB mit der SessionID im Namen ?

ich will eben keine globale Temp-Table anlegen, weil ich mich dann ja um die Existenz kümmern muss ... bei einer nicht globalen Temp-Table wird die Table beim Beenden der Session gelöscht und das muss eben irgendwie auch mit einem dynamischen SQL gehen

Aber wieso muss dynamisches SQL überhaupt in anderen Sessions laufen ?

weil das dynamische SQL über exec sp_executesql aufgerufen wird und das läuft automatisch in einer neuen Session!

Was ist das überhaupt ?

http://www.sqlteam.com/article/introduction-to-dynamic-sql-part-1

Und ... darfs denn das ?

ich glaub schon

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Also, soweit ich das jetzt verstanden habe, versuchst du in Session 2, welche von Session 1 aufgerufen wird, auf Daten in einer temp-Table zuzugreifen, welche in Session 1 erstellt wurde(bzw. die Daten).

Ich kenn nicht alle DB-Systeme, aber ich kann mir nicht vorstellen, dass das in irgendeinem DB-System geht. Schließlich ist das der Sinn von temp-Tables, dass Daten in Temp-Tables ausserhalb von der jeweiligen Sessions nicht gesehen werden! Unabhängig von dynamischen SQL.

Du kannst zwar Variablen übergeben, aber nicht ganze Session-Informationen, und dazu gehört die Temp-Table.
emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

ja, wahrscheinlich hast eh recht ... ich hab halt gehofft, dass es doch irgendwie geht, weil ich globale temp-Tables (die nicht im Speicher sondern in der tempdb liegen) nicht verwenden möchte!

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

weil ich globale temp-Tables

es ist egal, ob du globale temp tables verwendest oder nicht. Du wirst in Session 2 nicht auf die Daten von Session 1 zugreifen können.

emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

doch, mit globalen temporären Variablen funktioniert ja das Query

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

liefert es auch Daten?
emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

jep ... aber wie gesagt, eine globale temporäre Tabelle ist nichts anderes als eine normale Tabelle - einziger Unterschied ist halt der Speicherort!

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Ich würde dir ja gerne helfen, nur hab ich abnhand deiner Beschreibung nicht verstanden, was du eigentlich machen willst.

emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

ich möchte dem dynamischen SQL eine nicht-globale temporäre Tabelle übergeben!

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

hm ich dachte, du möchtest mir helfen ...

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Ich bin mir noch immer nicht sicher, was du genau willst.

Verstehe ich das richtig, dass das SQL immer verschiedene Tabellen mit identischem Aufbau liest. Die tatsächliche Tabellennamen ist erst zur Laufzeit bekannt?
Sind diese möglichen Tabellen temp-Tables? Werden diese erst zur Laufzeit erstellt?

Gibt's in MSSQL sowas wie Synonyme (wie in Oracle)? Dann könntest einfach ein Synonym verwenden, und dieses entsprechend umbiegen.

emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

hier gehts nicht um Synonyme oder um den Tabellennamen selbst, sondern darum, dass ein dynamisches SQL in einer eigenen Session ausgeführt wird und somit die temporären Tabellen meiner Ursprungs-Session nicht im dynamischen SQL sichtbar sind!

http://forum.geizhals.at/t691514,5930813.html#5930813

DECLARE @table TABLE (column1 int, column2 varchar(255))

Declare @SQL nVarChar(1000) --N.B. string must be unicode for sp_executesql
SELECT @SQL = 'SELECT * FROM pubs.DBO.Authors WHERE au_lname = @AuthorName'

Exec sp_executesql @SQL, N'@AuthorName nVarChar(50)', @AuthorName = 'white'

beim exec sp_executesql übergibt man die bereits vorhanden (und klarerweise benötigten) Variablen in das dynamische SQL ... nur funktioniert diese Übergabe nicht:

@tmpTable TABLE (column1 int, column2 varchar(255)) = @table

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Kannst du das nicht einfach mit einem String erledigen?
So in etwa:

declare @tabelle as varchar(50) = 'Tabellenname'
declare @sqlstring as varchar(400)

set @sqlstring = 'select top 100 * from ' + @tabelle
execute(@sqlstring)
___________________________

Ich glaube an das Gute im Menschen,
ich verlasse mich aber lieber auf das Schlechte in ihm.

schön wärs

aber nein, so gehts nicht ...

my car @ Spritmonitor.de

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung