Stored Proc: Problem mit Variable als Parameter

[divNull]

Hallo,
ich habe ein allgemeines Verständnisproblem mit MySQL-Variablen

Ich deklariere eine globale Variable und initialisiere sie mit einem String.

SET @M03 := 'Name1';

Wenn ich dann mit

SELECT @M03;

abfrage, erhalte ich als Lösungswert
@M03
----
NULL

Ich hätte aber 'Name1' erwartet. Verstehe ich nicht!

Hintergrund ist eine kleine Procedure, in der ich eine Variable als Parameter übergeben möchte. Ich erhalte auch hier nur leere Mengen

DROP PROCEDURE IF EXISTS `Test01`;
DELIMITER //
CREATE PROCEDURE `Test01`(M VARCHAR(15))
BEGIN
  SELECT * FROM tabelle WHERE Name = M;
END //
DELIMITER ;

SET @M03 := 'Name1';
CALL Test01(@M03);

Ergebnis:
Name
------
leere Menge.

Wenn ich den Parameter als konstanten Wert als Parameter übergebe klappt's. Ich erhalte den erwarteten Wert

CALL Test01('Name1');

Ergebnis:
Name
------
'Name1'

Könnt Ihr mir weiterhelfen?

[Falk Prüfer]

Hallo,

also die Korrekte Syntax für den SET-Befehl wäre:

[highlight=sql]
SET @M03 = 'Name1';
[/highlight]

Hast du es mal damit probiert?

Gruss Falk

[divNull]

Hallo Falk,
ja, das hab' ich auch schon probiert, genauso erfolglos. Im MySQL-Handbuch 5.1 unter 9.3 stehen aber beide Möglichkeiten ":=" und "=".

Bei SET kann entweder = oder := als Zuweisungsoperator verwendet werden.

Das muss an irgendwas anderem liegen.

[Falk Prüfer]

Hallo,

also ich kann das nicht nachvollziehen! Bei mir ergibt ein
[highlight=sql]
SET @M03 = 'Name1';
SELECT @M03 ;
[/highlight]
das gewünschte Ergebnis mit:

@M03
Name1

Das hast du beachtet?

User-defined variables are connection-specific

Gruß Falk

[hwoess]

Ich mach nix mit MySql aber das hier sieht mir von den Angaben her etwas zusammengebastelt aus. Was passiert denn, wenn du in der stored proc statt dem
SELECT * FROM tabelle WHERE Name = M;
einfach nur
SELECT M;
schreibst?

bye,
Helmut

[raiguen]

Ich mach nix mit MySql aber das hier sieht mir von den Angaben her etwas zusammengebastelt aus.

Wenn du nix mit MySql machst, wieso behauptest du dann, dass es zusammengebastelt aussieht!??...
Das Statement für die SP ist syntaktisch korrekt (soweit ich das sehen kann und getestet habe). Einzig die Übergabe einer lokalen Variable an die SP macht in sofern Schwierigkeiten, als dass das Ergebnis nicht wie erwartet ist!

statt dem
SELECT * FROM tabelle WHERE Name = M;
einfach nur
SELECT M;

Ist ja wohl nicht Ernst gemeint oder????
In der SP sollen alle Datensätze ausgegeben werden, deren Name dem Wert des übergebenen Parameters M entsprechen. Und NICHT den Inhalt der Parametervariablen!

Also, bei mir funktioniert das einwandfrei; d.h. der zugewiesene Varaiblenwert in @M03 wird eineandfrei an die SP weitergegeben und die SP spukt auch das erwartete Ergebenis aus.

[divNull]

Hallo Leute,
vielen Dank für euere Kommentare.
Natürlich ist das Beispiel auf das Wesentliche abgespeckt. Es macht ja keinen Sinn hier fett Code reinzustecken, wenn man genau weiß wo das Problem liegt. Soviel zum "Basteln".

@Falk: verstehe nicht, was du mit

User-defined variables are connection-specific

meinst. Hab' ich da was Wichtiges übersehen?

Ich habe mittlerweile einiges herumprobiert, unter anderem nochmals genau eure Hinweise probiert. Ich komme einfach nicht drauf:
Er zeigt nur den Spaltennamen an, meine Einträge mit 'Name1' findet er nicht oder will sie vielleicht nicht anzeigen.

Ich hatte zunächst Meldungen über 'Typemismatch' wegen unterschiedlicher Spracheinstellungen in den Tabellen. Der Standard ist ja latin1_swedish. Das habe ich mit

ALTER DATABASE datenbank COLLATE latin1_german1_ci;

umgestellt. Zudem habe ich nochmals per Hand bei jeder Tabelle einzeln auf latin1_german1_ci eingestellt. Danach hatte ich keine Fehlermeldung mehr aber leider hat er dennoch keine Einträge gefunden, obwohl die definitiv da sind.

@raiguen: Dass die Konstruktion bei dir funktioniert ist schon 'mal ein sehr guter Hinweis.
Kann es sein, dass es vielleicht Einschränkungen für mich als Benutzer in der Datenbank geben kann. Z.B. ich darf keine eigenen Variablen erstellen, weil ich nicht die Rechte in der Datenbank dazu habe?
Wenn ja, wie und wo müßte ich mir diese Rechte dann besorgen?

[Falk Prüfer]

...@Falk: verstehe nicht, was du mit meinst. Hab' ich da was Wichtiges übersehen?

UDVs sind IMMER an eine Session gebunden. Wenn die Client-Verbindung beendet wird, werden alle UDVs gelöscht. Das bedeutet auch: wenn du in einer Web-Umgebung (z.B. PHPMyAdmin) zuerst das SET übers SQL-Fenster ausführst und danach das Select, dann sind das ZWEI getrennte Sessions und die UDV wird nicht von einer zur anderen übertragen!
Meine Frage zielte also dahin, wie du deine Abfragen ausführst - ob also sichergestellt ist, dass sie in ein und derselben Session stattfinden.

...Kann es sein, dass es vielleicht Einschränkungen für mich als Benutzer in der Datenbank geben kann. Z.B. ich darf keine eigenen Variablen erstellen, weil ich nicht die Rechte in der Datenbank dazu habe?
Wenn ja, wie und wo müßte ich mir diese Rechte dann besorgen?

Normalerweise unterliegen UDVs keiner Rechtebeschränkung. Auch würde MySQL dann einen entsprechenden Fehler melden und nicht die Anfrage stillschweigend ignorieren.

Gruß Falk

[Falk Prüfer]

Wenn du nix mit MySql machst, wieso behauptest du dann, dass es zusammengebastelt aussieht!??...
Ist ja wohl nicht Ernst gemeint oder????
In der SP sollen alle Datensätze ausgegeben werden, deren Name dem Wert des übergebenen Parameters M entsprechen. Und NICHT den Inhalt der Parametervariablen!

@raiguen: Warum musst du hier so rummotzen!?
Was spricht dagegen eine Alternative auszuprobieren, um den Fehler einzugrenzen?
hwoess hat vorgeschlagen:

...Was passiert denn, wenn du in der stored proc statt dem
SELECT * FROM tabelle WHERE Name = M;
einfach nur
SELECT M;
schreibst?

Die Betonung liegt hier auf dem "Was passiert denn"! Um zu testen ob die Ursache nicht wie angenommen in der Variablenübergabe liegt, sondern vlt. an Zeichensatz- oder Datenproblemen, ist dass ein völlig legitimes und empfehlenswertes Vorgehen!

Also bevor du hier anfängst andere anzumaulen, Gehirn einschalten, richtig lesen und mal ein wenig nachdenken!

Gruß Falk

[divNull]

Hallo @Falk,
danke für den Hinweis. Du könntest richtig liegen.

Ich benutze kein PHPMyAdmin. Mein SQL-Code läuft im MySQL-Browser.
Ich klicke dort "Stück" für "Stück" des SQL-Codes an. Der Browser färbt den geraden aktiven Teil jeweils "weiß".
Der Ablauf entspricht aber meinem Beispiel.

Ist der MySQL-Browser eventuell für die von mir dargestellte Variablenübernahme gar nicht geeignet?

[Falk Prüfer]

...Ist der MySQL-Browser eventuell für die von mir dargestellte Variablenübernahme gar nicht geeignet?

Das kommt darauf an wie dieser die Statements ausführt. Wenn er bei jedem Statement eine neue Session startet (was bei einer Webbrowserbasierten Lösung der normale Weg wäre), dann sind Sessionvariable nicht möglich.

Gruß Falk

[divNull]

Hallo @Falk,

ich meinte nicht Web-Browser. Ich habe bei meiner Beschreibung ein kleines "Wörtchen" vergessen.
Es muß MySQL-Query Browser heißen. Das ist ein Tool, das man bei MySQL runterladen kann. Ich finde dieses Tool recht praktisch, zum Ausprobieren kleinerer SQL's.

Mittlerweile habe ich im Internet gekramt. Es scheint tatsächlich an diesem Tool zu liegen, dass keine Variablen als Parameter übernommen werden.

Hier ein Link eines weiteren MySQL-Users, der genau das gleiche Problem hat wie ich:
http://forums.mysql.com/read.php?108,293726,293726

Schlauerweise hat sich MySQL im Handbuch für dieses Tool bei der Beschreibung beim Einsatz von Parametern in SP genau hier zurückgehalten. Es gibt nur ein Beispiel ohne Paramter

Gibt' s noch eine weitere Möglichkeit den SQL-Code zu testen? Ich versuch zunächst 'mal mein Minibeispiel in der DOS-Umgebung zu starten.

Danke.

[divNull]

So habe jetzt im DOS-Fenster mit der Konsole mysql gestartet und das Beispiel per Hand eingegeben

Ergebnis: Der Variablen-Paramter in der SP wird nun ordnungsgemäß übergeben. Die SP führt die Abfrage korrekt aus.

Problem gelöst.

Das bedeutet der MySQL-Query-Browser ist nur bedingt einsatzfähig.
In welcher Entwicklungsumgebung arbeitet ihr?

[Christian Marquardt]

http://dev.mysql.com/downloads/workbench/

>>SQL Development (replacing MySQL Query Browser)

[raiguen]

Ich habe gute Erfahrungen mit HeidiSQL gemacht bzw arbeite fast ausschliesslich damit: Webseite.