StoredProcedures_HaveToDeclare_Eingangsparameter

Huan90

Benutzer
Beiträge
22
Hallo liebe DB-Forum Gemeinde,

ich bin gerade dabei meine ersten StoredProcedures zu schreiben, arbeite mich also gerade erst in das Thema ein...

Nun habe ich bei mehreren SP Probleme, allerdings möchte ich hier nun mit der einfachsten anfangen, vielleicht lerne ich in diesem Threat schon genug, dass ich die Fehlerbehebung bei den komplexeren SPs selber durchführen kann... :)

Folgende Prozedur habe ich erstellt. Diese soll lediglich die "@Linie" entgegennehmen, 2 Update-Befehle ausführen und anschließend den Eingangsparameter (@Linie) wieder zurückgeben.

USE



[Ipvks]

GO

/****** Object: StoredProcedure [dbo].[get_Linie_from_button] Script Date: 26.06.2014 15:42:22 ******/

SET
ANSI_NULLSON

GO
SET
QUOTED_IDENTIFIERON

GO

ALTER
PROCEDURE[dbo].[get_Linie_from_button]

@LinieASint

AS
BEGIN

SETNOCOUNTON;

DECLARE@update_R01LinieasNVARCHAR(MAX);

 

END

SET
@update_R01Linie=('UPDATE R01_Linie set Aktiv = 0 WHERE Aktiv = 1');

EXEC
sp_executesql@update_R01Linie;

SET
@update_R01Linie=('UPDATE R01_Linie set Aktiv = 1 WHERE Aktiv = @Linie');

EXEC
sp_executesql@update_R01Linie;

return
@Linie



Wenn ich die Prozedur nun ausführe (mit @Linie = 3), kommt folgende Fehlermeldung:

Msg 137, Level 15, State 2, Line 1
Must declare the scalar variable "@Linie".
(1 row(s) affected)

1. Ich frage mich nun, wo soll ich die Variable (das Scalar?! :confused:) deklarieren, sie ist doch als Eingangsparameter schon festgelegt... Oder darf ich den Eingangsparameter nicht zurückgeben?

2. Ist (in der letzten Zeile der SP) return @Linie richtig oder muss ich hier select @Linie verwenden?

3. Im 2. Update habe ich das "@Linie" mittlerweile mit in den String geschrieben. Vorher sah der Befehl so aus:

@update_R01Linie=('UPDATE R01_Linie set Aktiv = 1 WHERE Aktiv = ' + @Linie);
Allerdings hat das SQL-ManagementStudio dann immer versucht den Teil:
'UPDATE R01_Linie set Aktiv = 1 WHERE Aktiv = '
in INT zu konvertieren, ich kann mir vorstellen, dass er @Linie dazu addieren wollte???!

Vielen Dank im Voraus, hoffentlich ist der Beitrag nicht zu lang(weilig) geworden.
LG Huan90
 
Werbung:
Sag mal, ich deine Space-Taste kaputt?!

Auch wenn ich nicht restlos verstehe, was du hier vorhast,versuch mal so:

USE [Ipvks]

GO

/****** Object: StoredProcedure [dbo].[get_Linie_from_button] Script Date: 26.06.2014 15:42:22 ******/

SET
ANSI_NULLS ON

GO
SET
QUOTED_IDENTIFIER ON

GO

ALTER PROCEDURE[dbo].[get_Linie_from_button] @Linie AS int
AS
BEGIN

SET NOCOUNT ON
DECLARE @update_R01Linie as NVARCHAR(MAX)

END

SET @update_R01Linie=('UPDATE R01_Linie set Aktiv = 0 WHERE Aktiv = 1');

EXEC sp_executesql @update_R01Linie;

SET @update_R01Linie=('UPDATE R01_Linie set Aktiv = 1 WHERE Aktiv = @Linie');

EXEC sp_executesql @update_R01Linie;

return
@Linie
 
Das von pathomorph sieht gut aus, kein Syntaxproblem. Das fehlende Space verwirrt mich auch, kann es daran liegen?
 
Hallo pathomorph,

meine Space-Taste ist nicht kaputt. Wenn du damit auf folgende Stelle anspielen wolltest: "@LinieASint"...
Das wurd so vom Forum verwurschtelt, natürlich sind im Quellcode dort Leerzeichen enthalten.

Wenn ich das richtig sehe ist der einzige Unterschied zwiwschen unseren Codes folgender:

Huan90:
DECLARE @update_R01Linie as NVARCHAR(MAX);

pathomorph:
DECLARE @update_R01Linie as NVARCHAR(MAX)

Das Weglassen des Semikolons ändert nichts an der Fehlermeldung. Auch wenn ich deinen Code komplett so kopiere, kommt immer noch die Fehlermeldung:


Msg 137, Level 15, State 2, Line 1
Must declare the scalar variable "@Linie".


Was fehlt dir denn noch, damit du mein Vorhaben "restlos" verstehst?
Wie schon gesagt, diese SP soll einen Integerwert entgegennehmen, ein endsprechendes Feld in einer Tabelle updaten und den Eingangsparameter wieder zurückgeben.

LG Huan90
 
Teste mal bitte folgendes:
Code:
USE [Ipvks]
GO

SET
ANSI_NULLS ON
GO

SET
QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE[dbo].[get_Linie_from_button] (@Linie INT)
AS
BEGIN

SET NOCOUNT ON
DECLARE @update_R01Linie NVARCHAR(MAX)

END

SET @update_R01Linie=('UPDATE R01_Linie set Aktiv = 0 WHERE Aktiv = 1')

EXEC sp_executesql @update_R01Linie;

SET @update_R01Linie=('UPDATE R01_Linie set Aktiv = 1 WHERE Aktiv = @Linie')

EXEC sp_executesql @update_R01Linie;

RETURN @Linie
 
Hallo ukulele,

danke auch für deinen Beitrag. Allerdings kommt auch hier die selbe Fehlermeldung.

Ich habe gerade ein weiteres aktues Problem.

Eine weitere Prozedur soll die Eingangsparameter in eine Tabelle einfügen.
Dazu bastel ich mir einen Inser-String zusammen.


SET

@InsertPrauf='INSERT INTO Prauf VALUES (' +

isnull(@werk, 'NULL') + ',' +
.
. --hier stehen noch etliche Parameter...
.

isnull(@prodaufnr, 'NULL') + ')';


EXEC
sp_executesql@InsertPrauf;


Wenn ich die Prozedur ausführe und nur zahlen eintrage
, wird der Insert-Befehl durchgeführt.
Wenn allerdings irgendwo in den "insert values" ein Buchstabe vorkommt, gibt er die Fehlermeldung "invalid columname "BUCHSTABE"" aus. Ich hatte nun vor, vor und hinter die Variablen jeweils einen Anführungsstrich einzufügen. Also etwa so:
+ ''' + isnull(@werk, 'NULL') + '',' +

Das funktioniert so natürlich nicht. Ein weiterer Versuch mit einem doppelten Anführungsstrich war ebenfalls erfolglos:
+ '"' + isnull(@werk, 'NULL') + '",' +

Gibt es noch eine andere möglichkeit, lässt sich das Zeichen irgendwie escapen oder so? Habe leider nichts gescheites dazu gefunden, vermutlich stelle ich Google auch die Falschen Fragen... :/
 
Die komplexere Prozedur funktioniert nun, danke ukulele!
Das Apostroph ist CHAR(39) (36 war das Dollar-Zeichen)...
Hier noch einmal die Liste: http://www.robelle.com/smugbook/ascii.html

Das andere Problem habe ich nun auch lösen können:


USE
[Ipvks]

GO
SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER
ON

GO

ALTER
PROCEDURE[dbo].[get_Linie_from_button] (@Linie INT) AS

BEGIN

SET
NOCOUNT ON

DECLARE
@update_R01LinieNVARCHAR(MAX)

END

SET
@update_R01Linie=('UPDATE R01_Linie set Aktiv = 0 WHERE Aktiv = 1')

EXEC
sp_executesql@update_R01Linie
;

SET
@update_R01Linie=('UPDATE
R01_Linie set Aktiv = 1 WHERE Linie = '+ CONVERT(NVARCHAR(MAX),@Linie))

EXEC
sp_executesql@update_R01Linie;

RETURN
@Linie

Neben dem Fehler in der where-Klausel im 2. Update (Linie= anstatt Aktiv =) konvertiere ich nun den Parameter in NVARCHAR(MAX), außerdem war die Variable vorher im String.

Danke euch für eure Unterstützung!!! Es ist nicht unwarscheinlich, dass wir in Zukunft häufiger voneinander lesen werden.

LG Huan90
 
Werbung:
Ich bin heute auch irgendwie durcheinander, hatte 36 im Kopf und getestet, habe nachgeguckt und gesehen das es 39 ist und 36 hier gepostet. :oops:
 
Zurück
Oben