|
Задавайте вопросы, мы ответим
Вы не зашли.
Пишу
UPDATE `dbo`.`dvsys_carddefs`
SET `Alias` = Alias , `Version` = Version , `SysVersion` = SysVersion , `LibraryID` = LibraryID ,
`ControlInfo` = ControlInfo , `Options` = ( Options & 0xFF00FFFF ) | ( `Options` & 0x00FF0000 ) ,
`FetchMode` = FetchMode , `XMLSchema` = XMLSchema , `XSDSchema` = XSDSchema , `Icon` = Icon
WHERE `dbo`.`dvsys_carddefs`.`CardTypeID` = CardTypeID;
и это работает правильно.
Пишу
UPDATE `dbo`.`dvsys_carddefs`
SET `Alias` = Alias , `Version` = Version , `SysVersion` = SysVersion , `LibraryID` = LibraryID ,
`ControlInfo` = ControlInfo , `Options` = ( Options & 0xFF00FFFF ) | ( `Options` & 0x00FF0000 ) ,
`FetchMode` = FetchMode , `XMLSchema` = XMLSchema , `XSDSchema` = XSDSchema , `Icon` = Icon
WHERE `CardTypeID` = CardTypeID;
и этот оператор в процедуре компилируется, но правильно не работает.
Отличие в клаусе WHERE при правильной работе указывается полное имя колонки с таблицей, при неправильной работе ( у меня наблюдается безусловное обновление всех строк) я не указываю для колонки ее таблицу, предполагая, что по умолчанию должна взяться таблица из UPDATE.
Так ли это? Или мое предположение ошибочно и я должен всегда указывать явно прямую принадлежность колонки?
Неактивен
В хранимых процедурах MySQL имена переменных подавляют имена колонок.
Т.е. если Вы пишите WHERE somename = somename, то MySQL в обоих случаях интерпретирует somename как имя переменной (внутри UPDATE tblname SET name1 = name2 name1 всегда интерпретируется как имя колонки, т.к. имя переменной там не может стоять просто синтаксически).
Когда Вы пишите в одном из имён внутри WHERE точку, не заключенную в обратные кавычки (`), это автоматически исключает отнесение этого имени к переменной, поскольку в процедурах имена переменных точек содержать не могут, и имя с точкой однозначно интерпретируется как указание на колонку таблицы.
Вот и получается такой результат.
Т.е. ответ на ваш вопрос: в таких случаях всегда нужно указывать имя колонки вместе с именем таблицы.
Вообще, четно говоря, информация неожиданная, не знал о такой возможности разрешения конфликтов имен; как-то они этот вопрос в документации не осветили..
Неактивен
Спасибо.
Беда в этой ситуации в том, что неработающие операторы спокойно компилируются и исполняются, но не правильно, что вообще то говоря должно отлавливаться на этапе компиляции. Ладно попробуем указывать полностью.
Неактивен
Вообще говоря, процедуры не компилируются в MySQL, а интерпретируются по ходу выполнения. В данном контексте переменная используется с приоритетом по отношению к имени колонки, поэтому формально это не ошибка, получается WHERE 2=2 (вместо обоих операндов подставлено одно и то же значение переменной).
Неактивен
Если быть более внимательным, то написана клауса
WHERE `CardTypeID` = CardTypeID;
а из нее получается WHERE `2`=2 , если я правильно понимаю, а вовсе не WHERE 2=2 ?
Или для движка, который интерпретирует код это все равно?
Так что это ошибка и формально тоже.
И потом мне что-то не верится, что интерпретируется прямо как написано. Явно есть промежуточный код иначе оптимизации не получишь без подготовки.
Неактивен
Обратные кавычки в MySQL не являются обычными кавычками, а используются, чтобы указать, что внутри них строковый идентификатор. Поэтому `имя_переменной` и имя_переменной - одно и то же, за икслючением использования в имени спецсимволов или совпадения имени с ключевым словом (в этих случаях вторая запись будет некорректной). Про промежуточный код ничего не слышал.
Неактивен
