reboot
Goto Top

PHP - MSSQL - Keine Daten bei gespeicherter Prozedur

Bei dem Aufruf einer gespeicherten Prozedur werden mir keine Daten zurückgeliefert.

Hallo zusammen

Das Problem habe ich bereits längere Zeit, doch langsam beginnt es echt zu nerven.

Wir arbeiten hier mit PHP und MSSQL. Für die Verbindung zwischen PHP und MSSQL habe ich vor einiger Zeit den SQL-Treiber für PHP heruntergeladen und installiert (http://msdn.microsoft.com/de-de/library/cc296170%28v=sql.90%29.aspx)

Nur haben wir seither folgendes Problem. Nehmen wir an, wir haben folgende Prozedur:
ALTER PROCEDURE [dbo].[meineProzedur]
	@parameter INT,
	@parameter2 VARCHAR(30)      
AS
BEGIN	

	DECLARE @count INT
	
	SET @count = (
		SELECT	COUNT(spalte) AS c
		FROM	tabelle
		WHERE	spalte1 = @parameter
	)
		
	IF @count = 0
		BEGIN
			SELECT 'empty' AS response
			RETURN
		END
		
	UPDATE tabelle
	SET spalteXY = @parameter2
	WHERE spalte1 = @parameter

	SELECT 'success' AS response

RETURN

Wenn ich diese im Management Studio ausführe, bekomme ich je nach Wahl der Parameter die Rückgabe "success" oder "empty".
Aber im PHP kommt jeweils nichts zurück! An PHP werden so wie es aussieht kein Resultat/keine Daten gesendet.

Eine kleine Prozedur wie z.B. nur einen Select funktioniert problemlos. Andernfalls bekomme ich bei folgender Prozedur auch keinen Wert zurück:
ALTER PROCEDURE [dbo].[meineProzedur]
	@parameter INT,
	@parameter2 VARCHAR(30)      
AS
BEGIN	
		
	UPDATE tabelle
	SET spalteXY = @parameter2
	WHERE spalte1 = @parameter

	SELECT 'success' AS response

RETURN

Hatte jemand bereits das gleiche Problem? Woran könnte es liegen?
Wäre sehr dankbar um Hilfe.

Ich nutze PHP in der Version: 5.2.9
Und MSSQL 2008


Vielen Dank
Gruss reboot

Content-ID: 183979

Url: https://administrator.de/forum/php-mssql-keine-daten-bei-gespeicherter-prozedur-183979.html

Ausgedruckt am: 22.12.2024 um 12:12 Uhr

ITSchlumpf
ITSchlumpf 23.04.2012 um 16:30:51 Uhr
Goto Top
Hey Reboot,

bin da jetzt kein Profi drinne, aber es kann sein, dass die Statements im PHP ein wenig anderst aussehen müssen.
Funktionieren denn andere Abfragen?


Gruß
Schlumpf
reboot
reboot 23.04.2012 um 16:44:07 Uhr
Goto Top
Hey ITSchlumpf

Ja, da hast du recht... aber das hier oben ist auch T-SQL und nicht PHP. Die gespeicherten Prozeduren werden auf dem SQL-Server gespeichert/geschrieben und von PHP nur aufgerufen.

Ja, andere Abfragen wie z.B. ein ganz normaler Select funktionieren.


Gruss reboot
ITSchlumpf
ITSchlumpf 23.04.2012 um 16:53:01 Uhr
Goto Top
Kannst du vll mal deinen PHP-Code posten, vll ist dort ein fehler drinne.

Gruß
Schlumpf
Biber
Biber 23.04.2012 um 17:40:03 Uhr
Goto Top
Moin reboot,

wenn deine StP Rückgabewerte nach außen liefern soll, dann musst du diese auch angeben.

Falls also "response" nach aussen/zum Aufrufer gelangen soll, dann solltest du eine Variable @response mit dem Schlüsselwert OUTPUT deklariren.

Beispiel:
@response varchar(10) OUTPUT

Befüllen kannst du sie in der StP mit
SELECT @response = 'success' oder ähnliches.

Ich kann auf Anhieb nicht erkennen, was genau den Charme einer Text-Rückgabe 'success' bzw. 'empty' ausmacht.
Meine Mädels hätten wahrscheinlich eher 0 und 1 genommen.

Grüße
Biber
reboot
reboot 24.04.2012 um 08:24:54 Uhr
Goto Top
Hallo ITSchlumpf

Ok. Ich habe den Code nun aus meinen Klassen herausgesucht und eine Test-Datei erstellt, die folgendermassen aussieht.

$info = array (
	'username' => 'xxxx',  
	'password' => 'xxxx',  
	'host' => 'xxxx,  
	'database' => 'xxxx'  
);

$connection = sqlsrv_connect(
	$info['host'],  
	array(
		'UID' => $info['username'],  
		'PWD' => $info['password'],  
		'Database' => $info['database']  
	)
);

$query = "meineProzedur 'parameter'";  
$result = sqlsrv_query($connection, $query);

while ($row = sqlsrv_fetch_array($result, SQLSRV_FETCH_ASSOC))
{
	var_dump($row);
	echo '<hr />';  
}

So wird mir nichts ausgegeben. Wenn ich aber bei der oben geposteten Prozedur folgendes einfüge, bekomme ich "test" in der Spalte "response" zurück.
Es ist sobald ich einen Select, ein Update oder ein Delete durchführe, werden die unteren Selects nicht mehr beachtet/an PHP zurückgegeben...

	...

	SELECT 'test' AS response

	SET @count = ( 
		SELECT	COUNT(spalte) AS c 
		FROM	tabelle 
		WHERE	spalte1 = @parameter 
	) 

	...


Gruss reboot
reboot
reboot 24.04.2012 um 08:30:35 Uhr
Goto Top
Hallo Biber

Danke für den Tipp, aber wenn ich versuche die Variable zu deklarieren kommt bei mir ein Syntaxfehler.

DECLARE @response VARCHAR(30) OUTPUT

Fehler: Falsche Syntax in der Nähe von 'OUTPUT'

Zum Charme meiner Text-Rückgabe.
Klar könnte ich 0 oder 1 verwenden. Aber bei komplexeren Prozeduren gibt es z.B. 4 oder 5 mögliche Rückgaben.
Und da ich kein Fan bin von nicht aussagekräftigen Zahlen nutze ich Strings.
Wenn ich von einer Prozedur "error" oder "no access" zurück bekomme, sagt mir das viel mehr als z.B. "3" oder "4". face-wink


Gruss reboot
ITSchlumpf
ITSchlumpf 24.04.2012 um 10:48:09 Uhr
Goto Top
Moin Reboot,

funktioniert die Abfrage wenn du sie direkt im PHP schreibst und dann ausführst?
Bsp. :

$dbconnect = mssql_connect($SQL_Server, $SQL_User, $SQL_Pw);
mssql_select_db($SQL_db);
$sql = "Select blalbalbla";  
$result = mssql_query($sql);
$row = mssql_fetch_array($result, MSSQL_ASSOC);

Wäre das evtl. eine Möglichkeit?

Gruß
reboot
reboot 24.04.2012 um 13:53:55 Uhr
Goto Top
Tag ITSchlumpf

Nein, das geht leider auch nicht. Kommt auch kein Resultat zurück. Allgemein ist mir jetzt folgendes nochmals klar geworden.

Sobald ein UPDATE, INSERT oder DELETE-Befehl ausgeführt wurde, wird ein sich darunter befindender SELECT nicht mehr an PHP zurückgeliefert.
Als ob ein UPDATE-Befehl etc.. einen RETURN verursachen würde. Was natürlich schwachsinn ist, denn wenn ich das ganze im Management Studio ausführe funktioniert alles tadellos.

Sprich folgendes funktioniert nicht:
1. Update
2. Select

Folgendes funktioniert:
1. Select
2. Update


Gruss reboot
ITSchlumpf
ITSchlumpf 24.04.2012 um 14:24:41 Uhr
Goto Top
Kann es sein, dass er die Verbidung schließt und deswegen den zweiten SQL-Befehl garnicht mehr erhällt?

Ist echt ein komischer Fehler.

Gruß
reboot
reboot 24.04.2012 um 16:03:05 Uhr
Goto Top
Ja, irgendwie so muss es fast sein. Anders kann ich mir das auch nicht erklären.
Aber es darf doch eigentlich nicht sein. Man muss doch das gleiche zurückbekommen, wie wenn man die Prozedur auf dem SQL resp. Management Studio ausführt...


Gruss reboot
ITSchlumpf
ITSchlumpf 24.04.2012 um 16:34:15 Uhr
Goto Top
Und wenn du nach dem Update nochmal ne Verbindung zum Server aufmachst?

Gruß
reboot
reboot 25.04.2012 um 08:28:24 Uhr
Goto Top
Sorry, aber wie stellst du dir das vor?

Ich schliesse die Verbindung sowieso nicht. Die Verbindung bleibt bestehen.


Gruss
ITSchlumpf
ITSchlumpf 25.04.2012 um 08:49:57 Uhr
Goto Top
Morgen,

naja aber aus irgendeinem Grund bekommst du keine Antwort von deinem SQL-Server. Dachte halt, dass die Verbindung aus irgendeinem Grund vll geschlossen wird und du Sie wieder öffnen müsstest.

Hast du schonmal geschaut, ob deine Variablen an den entsprechenden Stellen noch die richtigen Werte haben oder ob sie ihre Werte verlieren?!

Gruß
reboot
reboot 25.04.2012 um 10:09:01 Uhr
Goto Top
Ich hab des Rätels Lösung gefunden!!!
Unglaublich. Nach weiteren Stunden des Suchens.

Also es ist folgendermassen.

Wenn man in der gespeicherten Prozedur (GSP) nur einen SELECT stehen hat wie hier:
SELECT *
FROM tabelle
WHERE spalte = @param

Dann reicht folgender PHP-Code, um alle Werte, die der SELECT zurückliefert zu durchlaufen.
$query = "deine_prozedur 'bla bla'";  
$result = sqlsrv_query($connection, $query);

while ($row = sqlsrv_fetch_array($result, SQLSRV_FETCH_ASSOC))
{
	// mach was mit $row
}

Wenn man nun aber zuerst ein UPDATE, ein NSERT oder ein DELETE Befehl ausführt, muss man das ganze um eine Zeile erweitern.

SQL:
UPDATE tabelle
SET spalte1 = @param1
WHERE spalte2 = @param2

SELECT *
FROM tabelle
WHERE spalte2 = @param2

PHP:
$query = "deine_prozedur 'bla bla'";  
$result = sqlsrv_query($connection, $query);

sqlsrv_next_result($result); /* WICHTIG!!! */
while ($row = sqlsrv_fetch_array($result, SQLSRV_FETCH_ASSOC))
{
	// mach was mit $row
}


Vielen Dank für eure Unterstützung.

Gruss reboot
ITSchlumpf
ITSchlumpf 25.04.2012 um 10:20:57 Uhr
Goto Top
Immer wieder gerne.

So kleine Fehler sind die schlimmsten ^^

Have a nice day ;)

Gruß
Schlumpf