MySQL - Stored Procs - Странность при попытке использовать выходной параметр

0

Честно говоря, я сейчас чувствую себя довольно глупо. Но это просто не работает.

Сценарий
У меня есть хранимая процедура, которая включает выходной параметр. Я пытаюсь выбрать значение INTO этого параметра. Это кажется простым, но оно продолжает давать мне ошибочные результаты. Я проверил множество онлайн-источников, и я уверен, что я стараюсь сделать это правильно.


код

DELIMITER //
CREATE PROCEDURE `spGetId`(
    IN ParamA VARCHAR(32),
    OUT OutputId INT
)
BEGIN
    SELECT `id` INTO OutputId
    FROM `Table`
    WHERE `column_a` = ParamA;
END//

CALL spGetId('foobar', @Bloop)//
SELECT @Bloop//


Результаты
У меня есть две строки в этой таблице, их идентификаторы - "1" и "2" . Результат, который я верну, равен '31', независимо от того, соответствует ли инструкция SELECT чему-либо или нет. Я пробовал много вариантов, в том числе полностью исключая предложение WHERE и получая SELECT, возвращая COUNT (1) в параметр (который дает мне результат "32", несмотря на то, что есть только 2 строки), и я попытался "объявить" переменная @Bloop перед использованием в вызове sproc с помощью SET @Bloop = 0.

Если у вас есть представление о том, почему это происходит, и что я могу сделать, чтобы вернуть правильное значение, я был бы очень обязан. Кроме того, если вы можете показать мне, как достичь того же желаемого результата, используя хранимую функцию вместо этого, с возвращаемым значением, я был бы признателен, что еще больше! Мой желаемый подход заключается в использовании хранимой функции, но у меня были схожие проблемы с этим, после этого я отказался и попытался использовать хранимую процедуру, только чтобы найти, что получаю аналогичные результаты.

Все, что вы можете предложить, было бы полезно!

Edit

CREATE TABLE `Table` (
 `id` int(11) NOT NULL auto_increment,
 `column_a` varchar(32) character set utf8 NOT NULL,
 PRIMARY KEY  (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

mysql> SELECT * FROM Table;
+------+----------+
| id   | column_a |
+------+----------+
|    1 | asdf     |
|    2 | foobar   |
+------+----------+

Когда я вызываю spGetId() с любым аргументом, он возвращает значение "31" (даже если аргумент равен "foobar", который должен возвращать целочисленное значение "2" (или ascii 0x32)). Если я изменяю spGetId(), чтобы вернуть общую таблицу строк таблицы вместо того, чтобы возвращать "2" , он возвращает "32".

  • 0
    Можете ли вы показать вывод "show create table Table " и "select * from Table ", пожалуйста?
  • 0
    Попробуйте show warnings; вызовах show warnings; сразу после того, как вы CALL spGetId('bleep', @Bloop) , для меня это похоже на проблему с преобразованием типов
Показать ещё 2 комментария
Теги:
stored-procedures
stored-functions
output-parameter

2 ответа

0
Лучший ответ

Мне нужно научиться изменять среду тестирования.

Я все еще не уверен, в чем проблема, но похоже, что phpMyAdmin выполнял собственное преобразование типа, и я выполнял все свои тесты через этого конкретного клиента.

Сбрасывая быстрый PHP script из моего собственного и вручную вызывающий sproc (и при дальнейшем тестировании, вызывая также сохраненную функцию) предоставил желаемые результаты.

Итак, извлеченный урок: никогда не доверяйте клиенту. Не помню, чтобы немного переключиться.

1

Ваш сохраненный proc работает. Я думаю, что он возвращает значение ascii символа '1' вместо целочисленного значения.

  • 0
    Это звучит довольно жизнеспособно. Но идентификатор, который он должен возвращать, равен «2», поэтому я не уверен, почему он должен возвращать «1». И если столбец - это int (11), а возвращаемое значение sproc - это int (11), зачем ему возвращать значение ascii? Вы знаете, будет ли там что-нибудь еще?

Ещё вопросы

Сообщество Overcoder
Наверх
Меню