Необходимо объявить скалярную переменную
являются ли оба глобальных входных параметра для хранимой процедуры, и поскольку я компилирую SQL-запрос внутри хранимой процедуры с помощью T-SQL, то с помощью Exec(@sqlstatement) в конце хранимой процедуры, чтобы показать результат, он дает мне эту ошибку, когда я пытаюсь использовать @RowFrom или @RowTo внутри @sqlstatement переменной, которая выполняется.. в противном случае он отлично работает.. пожалуйста помочь.
кроме того, я попытался включить следуя в @sqlstatement переменной:
но @RowTo по-прежнему не пропускает его значение @Rt и выдает ошибку.
4 ответов:
вы не можете объединить int в строку. Вместо:
вам нужно:
чтобы проиллюстрировать, что происходит здесь. Допустим, @RowTo = 5.
чтобы построить это в строку (даже если в конечном итоге это будет число), мне нужно преобразовать его. Но, как вы можете видеть, число по-прежнему рассматривается как число, когда оно выполняется. Ответ 25, верно?
в вашем случае вам действительно не нужно повторно объявлять @Rt так далее. внутри строки @sql вам просто нужно сказать:
хотя было бы лучше иметь правильную параметризацию, например
просто FYI, я знаю, что это старый пост, но в зависимости от настроек сортировки базы данных вы можете получить эту ошибку в таком заявлении,
если, например, вы опечатка S в
извините, что отклонил ответы, уже опубликованные здесь, но это фактический экземпляр сообщения об ошибке.
обратите внимание также, что ошибка не будет отображать капитал S в сообщении, я не уверен, почему, но я думаю, что это потому, что элемент
слева от знака равенства.
просто добавляя то, что исправлено для меня, где опечатка является подозреваемым согласно это блог MSDN.
при разбиении строк SQL на несколько строк проверьте, что вы запятая, отделяющая вашу строку SQL от ваших параметров (и не пытаетесь их объединить!) и не пропуская пробелы в конце каждой строки. Не ракетостроение, но надеюсь, что я спасу кого-то от головной боли.
например:
чувствительность к регистру также вызовет эту проблему.
@MyVariable и @myvariable-это одни и те же переменные в SQL Server Man. Студия так и будет работать. Однако эти переменные приведут к тому, что «необходимо объявить скалярную переменную» @MyVariable » в Visual Studio (C#) из-за различий в чувствительности к регистру.
System.Data.SqlClient.SqlException: "Неправильный синтаксис около конструкции "nvarchar". Необходимо объявить скалярную переменную "@Статус"." [закрыт]
Закрыт. Этот вопрос не по теме. Ответы на него в данный момент не принимаются.
Вопрос вызван проблемой, которая больше не воспроизводится, или опечаткой. Хотя похожие вопросы могут быть уместны на этом сайте, решение для этого вопроса вряд ли поможет будущим посетителям. Обычно можно избежать подобных вопросов написанием и исследованием минимальной программы для воспроизведения проблемы до публикации вопроса.
Закрыт 10 месяцев назад .
При выполнении запроса возникает ошибка:
Неправильный синтаксис около конструкции "nvarchar". Необходимо объявить скалярную переменную "@Статус".
- Embedded spaces or special characters are not allowed.
В именах параметров не разрешены пробелы.
Уберём из них пробелы и квадратные скобки.
Попутно исправим другие ошибки и недочёты: имя соединения (у вас оно почему-то названо connectionString ), опасность потери ресурсов (используем using для устранения этого), использование устаревшего и опасного метода AddWithValue (заменим его на Add с указанием точного типа).
Кроме того, время_входаTextBox используется дважды. Будьте внимательны!
Благодаря использованию using соединение будет гарантировано закрыто, даже в случае возникновения исключения. Вызывать метод Close() не нужно.
Я не знаю, какие именно типы используются у вас в таблице, поэтому сами укажите правильные типы SqlDbType . При необходимости примените int.Parse и тому подобные методы. А лучше используйте NumericUpDown для ввода чисел вместо TextBox .
Почему не стоит использовать метод AddWithValue :
Can we stop using AddWithValue() already?
AddWithValue is evil!
AddWithValue is Evil
Достаточно прочитать любую из этих статей.
Microsoft SQL Server
переменные
Когда вы создаете обычную таблицу, вы используете синтаксис CREATE TABLE Name (Columns) . При создании переменной таблицы используется DECLARE @Name TABLE (Columns) .
Чтобы ссылаться на переменную таблицы внутри SELECT , SQL Server требует, чтобы вы указали переменную таблицы как псевдоним, иначе вы получите сообщение об ошибке:
Должен объявить скалярную переменную «@TableVariableName».
Обновление переменной с помощью SET
Используя SET , вы можете обновлять только одну переменную за раз.
Обновление переменных с помощью SELECT
Используя SELECT , вы можете обновлять сразу несколько переменных.
При использовании SELECT для обновления переменной из столбца таблицы, если имеется несколько значений, она будет использовать последнее значение. (Применяются правила нормального порядка — если сортировка не задана, заказ не гарантируется).
Если в запросе нет строк, значение переменной не изменится:
Объявлять сразу несколько переменных с начальными значениями
Операторы вспомогательного присваивания
Поддерживаемые составные операторы:
+= Добавить и назначить
-= Вычесть и назначить
*= Умножить и назначить
/= Разделить и назначить
%= Modulo и назначить
&= Побитовое И и назначить
^= Побитовое XOR и назначить
|= Побитовое ИЛИ и назначить
Обновление переменных путем выбора из таблицы
В зависимости от структуры ваших данных вы можете создавать переменные, которые обновляются динамически.
В большинстве случаев вы захотите убедиться, что ваш запрос возвращает только одно значение при использовании этого метода.
Должен объявить скалярную переменную
Необходимо объявить скалярную переменную «@value1».
Я генерирую SQL динамически, и я хочу получить значение в переменной. Что я должен делать?
4 ответа
Причина, по которой вы получаете DECLARE Ошибка в вашем динамическом операторе заключается в том, что динамические операторы обрабатываются отдельными пакетами, что сводится к области видимости. Хотя может быть более формальное определение областей, доступных в SQL Server, я считаю, что достаточно иметь в виду следующие три, упорядоченные от самой высокой доступности до самой низкой доступности:
Глобальный:
Объекты, доступные для всего сервера, такие как временные таблицы, созданные с двойным знаком хеш / фунт ( ##GLOBALTABLE Однако вы хотели бы позвонить #). Будьте очень осторожны с глобальными объектами, так же, как с любым приложением, SQL Server или другим способом; Эти типы вещей, как правило, лучше всего избегать вообще. По сути, я говорю о том, чтобы помнить об этом как об отдельном напоминании, чтобы не вмешиваться.
Сессия:
Объекты, ссылки на которые привязаны к определенному спиду. На мой взгляд, единственный тип объекта сеанса, о котором я могу думать, это обычная временная таблица, определенная как #Table. Нахождение в области действия сеанса по сути означает, что после пакета (завершается GO ), ссылки на этот объект будут продолжать разрешаться успешно. Они технически доступны для других сессий, но это было бы неким подвигом сделать так программно, так как они получают своего рода рандомизированные имена в базе данных tempdb, и доступ к ним в любом случае является проблемой в заднице.
При открытии нового сеанса (соединение с отдельным spid) второй пакет выше не будет выполнен, так как этот сеанс не сможет решить #t_Test имя объекта
Пакет:
Нормальные переменные, такие как ваш @value1 а также @value2 , предназначены только для партии, в которой они заявлены. В отличие от #Temp таблицы, как только ваш блок запроса достигает GO эти переменные перестают быть доступными для сеанса. Это уровень области, который генерирует вашу ошибку.
Хорошо, и что?
Что происходит здесь с вашим динамическим утверждением, что EXECUTE() Команда эффективно оценивает как отдельный пакет, не прерывая пакет, из которого вы его выполнили. EXECUTE() это хорошо и все, но с момента введения sp_executesql() Я использую первое только в самых простых случаях (явно, когда в моих высказываниях совсем мало «динамических» элементов, в первую очередь, чтобы «обмануть» иным образом неаккомодирующий DDL CREATE заявления, чтобы бежать в середине других партий). Aaron Bertrand, приведенный выше, аналогичен и по производительности будет аналогичен приведенному ниже, используя функцию оптимизатора при оценке динамических операторов, но я подумал, что стоит остановиться на @param Ну, параметр.