Spaltenname als Parameter in Stored Procedure

[Jelly]

Gibts ne Möglichkeit, bei einer Select Abfrage in einer Stored Procedure ein Spaltenname als Parameter zu übergeben...

SQL-Code:

set @A = 'Spaltenname'
select @A from Tabelle

Das bringt mir natürlich soviele Datensaätze, wie in der Tabelle gespeichert sind, jeweils mit dem Stringinhalt 'Spaltenname' ;

[shmia]

SQL-Code:

set @A = 'Spaltenname'
EXECUTE('select '+@A+' from Tabelle')

Wenn du aber so eine SP benötigst, ist das häufig ein Zeichen von nichtperfekten Datenbankdesign.

[Jelly]

Ich nutze folgende Zeile in einer Stored Procedure:

SQL-Code:

set @Code =  (select ct.Code from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = @PA_ID and ct.IsByEMail=1)

Und in dieser Zeile möchte ich gerne p.HKANotificationCommTyp ersetzen können durch einen String... Bei dieser Anweisung scheint die Execute Methode aber nicht zu funktionnieren, oder ich kenn die genaue Sysntax nicht. Also probiert hab ich

SQL-Code:

set @Code =  EXECUTE('select ct.Code from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = @PA_ID and ct.IsByEMail=1')

und das quittiert mir Server mit
Incorrect syntax near the keyword 'EXECUTE'.

[HendrikM]

Das Folgende sollte aber funktionieren:
declare @code char(2000)
set @Code = 'select ct.Code from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = @PA_ID and ct.IsByEMail=1'
execute(@code)

[Jelly]

Sollte man meinen, aber nein... Er erstellt mir zwar die SP, also die Syntax stimmt. Wenn ich die SP jedoch ausführe, krieg ich folgende Meldung
Line 1: Incorrect syntax near '.'.
select ct.
Zur Vollständigkeit halber hier mal die ganze SP:

SQL-Code:

create procedure spQueryMailHKA(
@P_ID int,
@MailAddress varchar(255) output)
as
declare @Code varchar(10)
declare @PA_ID int

set @PA_ID = (Select pa.ID from partner pa, property p where p.Manager=pa.ID and p.ID=@P_ID)
print @PA_ID
set @Code = 'select ct.Code from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = @PA_ID and ct.IsByEMail=1' 
execute(@code) 
print @Code

set @MailAddress = isnull((select pc.Number from PartnerComm pc, Partner pa, CommTyp ct
                            where pc.Partner=pa.ID and pc.CommTyp=ct.ID and ct.Code=@Code and pa.ID=@PA_ID),'')

print @MailAddress

[Flocke]

Die Zeile ist auf jeden Fall noch falsch:

Code:

set @Code = 'select ct.Code from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = @PA_ID and ct.IsByEMail=1'

da musst du das PA_ID aus den Anführungszeichen herausholen

Code:

set @Code = 'select ct.Code from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = ' + @PA_ID + ' and ct.IsByEMail=1'

[Nachtrag]

Außerdem bin ich mir nicht ganz sicher, ob du an die Ergebnisse herankommst. Ein EXECUTE macht das nämlich in einem eigenen Kontext, die in der SP deklarierten Variablen gelten da nicht.

Also ggf. in dem String ein select in eine temporäre Tabelle ausführen und diese Tabelle dann danach wieder auslesen.

[Jelly]

Zitat:

Zitat von Flocke

Ein EXECUTE macht das nämlich in einem eigenen Kontext, die in der SP deklarierten Variablen gelten da nicht.

Also ggf. in dem String ein select in eine temporäre Tabelle ausführen und diese Tabelle dann danach wieder auslesen.

Das scheint zu stimmen. Allerdings klappt das mit der temporären Tabelle auch nicht, denn die ist leer, nach folgendem Aufruf:

SQL-Code:

create table #temphka (Code varchar(10))
set @Code = 'select ct.Code into #temphka from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = ' + cast(@PA_ID as varchar(10)) + ' and ct.IsByEMail=1'
print @Code
execute(@Code)
set @Code = (select Code from #temphka)
print @Code
select * from #temphka

Die Selct Anweisung als solche liefert definitiv einen Datensatz. Allerdings ist #temphka leer.

[jensw_2000]

An dem selbem Problem habe ich diverse ergebnislose Tage verbracht.
Wenn EXECUTE ein SELECT aufruft anstatt eine SP (bzw. Sub-SP) mit Ausgabe Parameter kann man eine Variablenübergabe zwischen dem eingeschlossenen SELECT und der aufrufenden SP vergessen.
Die in der SP deklarierten Variablen sind dem durch EXECUTE aufgerufenem SELECT unbekannt, umgekehrt genauso ..

Ich habe damals versucht die gewünschten Parameter über eine TempTable abzurufen, ging auch nicht, weil die SP und der im EXECUTE gekapselte SELECT unterschiedliche ProcessID's haben und die TempTable schon wieder weg ist, bevor der nächste SP Befehl nach dem EXECUTE ausgeführt wird.


Ich denke dir bleiben nur 2 Varianten

1.
Baue dir ein paar kleine Sub-SP's (mit Ausgabeparametern) die du dann mit Execute aufrufst.
Über diese kannst du kann deine Variablen in der Haupt-SP füllen.

SQL-Code:

DECLARE @Code Varchar(10)

EXECUTE MeineSubSP "ein Input-Parameter", @Code    -- << hier ohne Klammern


CREATE PROCEDURE MeineSubSP
 (
  @InputParam VARCHAR(50) = NULL,
  @OutputParam VARCHAR(10) = NULL
 )
AS
BEGIN
  SELECT @OutputParam=Code FROM Irgendwo WHERE Vorname =  @InputParam
END

2.
Definiere alle möglichen SELECTS's in der SP und rufe in Abhängigkeit von einem (oder mehreren) Parametern das richtige SELECT auf ....

SQL-Code:

CREATE PROCEDURE MeineSP
 (
  @SelectID     INT = 0,
  @SelectParam  INT,
  @SelectResult VARCHAR(10) = NULL
 )
AS
BEGIN

  IF @SelectID = 0 
    SELECT @SelectResult = PersonalNr FROM Personal ID = @SelectParam

  IF @SelectID = 1 
    SELECT @SelectResult = PersonalNr FROM Praktikum ID = @SelectParam


   If @SelectResult IS NOT NULL 
     SELECT bla FROM Verkaeufe WHERE PersonalNr = @SelectResult

END

Ich lasse mich gern eines besseren beleheren, aber derzeit bin ich fest davon überzeugt, das die Variablen, die in einem mit EXECUTE ausgeführten SELECT lokal sind, und nicht an den "aufrufenden Prozess" zurückgegeben werden können. Eine Weiterverarbeitung kann man also vergessen.

[keine Ironie oder Überheblichkeit]
Ich würde mich wirklich freuen, wenn jemand diese Behauptung mit einem kleinen Beispiel wiederlegen kann. :zwinker:
Dann kann ich viele meiner SP's um mehrere Hundert Zeilen Code kürzen ...
[/keine Ironie oder Überheblichkeit]

Schöne Grüße an alle,
Jens

:hi:

[shmia]

aus der SQL-Server Hilfe
Transact-SQL unterstützt zwei Methoden für die Erstellung von SQL-Anweisungen zur Laufzeit in Transact-SQL-Skripts, gespeicherten Prozeduren und Triggern:

Verwenden der gespeicherten Systemprozedur sp_executesql zur Ausführung einer Unicode-Zeichenfolge. sp_executesql unterstützt die Parameterersetzung wie bei einer RAISERROR-Anweisung.

Verwenden der EXECUTE-Anweisung zur Ausführung einer Zeichenfolge. Die EXECUTE-Anweisung unterstützt keine Parameterersetzung in der ausgeführten Zeichenfolge.
Also hat man mit sp_executesql schon mal das Problem mit den Parametern abgehakt.

[Jelly]

Das Problem sind nicht die Parametererstzung, sondern dass sowohl Execute und executesql in einem eigenen Prozess ablaufen, und somit keine Werte an den Hauptprozess übergeben.

Ich hab jetzt Folgendes, was funktioniert:

SQL-Code:

set @Code = 'select ct.Code into ##temphka from partner p join commtyp ct on p.HKANotificationCommTyp=ct.ID where p.ID = ' + cast(@PA_ID as varchar(10)) + ' and ct.IsByEMail=1'
execute(@Code)
set @Code = (select Code from ##temphka)
drop table ##temphka

set @MailAddress = isnull((select pc.Number from PartnerComm pc, Partner pa, CommTyp ct
                            where pc.Partner=pa.ID and pc.CommTyp=ct.ID and ct.Code=@Code and pa.ID=@PA_ID),'') 

print @MailAddress

Ich bin mir aber irgendnie nicht ganz im Klaren, was das mit dem #3 auf sich hat. Sind das etwa temporäre Tabellen, die global gültig sind. Dann träten aber da Probleme auf, wenn die Prozedur parallel ausgeführt wird, oder?

Gibts ne Möglichkeit über T-SQL eine GUID zu generieren, dann hätt ich noch ne sichere Lösung.