Необходимо объявить скалярную переменную
оба являются глобальными входными параметрами для хранимой процедуры, и поскольку я компилирую SQL-запрос внутри хранимой процедуры с помощью T-SQL, затем использую Exec(@sqlstatement) в конце хранимой процедуры, чтобы показать результат, это выдает мне эту ошибку, когда я пытаюсь использовать @RowFrom or @RowTo внутри @sqlstatement переменная, которая выполняется .. в остальном работает нормально .. помогите пожалуйста.
Кроме того, я попытался включить в @sqlstatement переменная:
но @RowTo все еще не передает свое значение @Rt и выдает ошибку.
Я не буду добавлять ответ, потому что он не относится конкретно к этому вопросу, но в качестве первого результата в Google для этой ошибки стоит отметить, что использование GO вызывает новую ветвь, в которой объявленные переменные не видны за оператором. — IronSean
9 ответы
Вы не можете объединить int со строкой. Вместо того:
Чтобы проиллюстрировать, что здесь происходит. Допустим, @RowTo = 5.
Чтобы превратить это в строку (даже если в конечном итоге это будет число), мне нужно преобразовать его. Но, как видите, число по-прежнему обрабатывается как число при выполнении. Ответ 25, не так ли?
В вашем случае вам действительно не нужно повторно объявлять @Rt и т. Д. Внутри строки @sql, вам просто нужно сказать:
Хотя было бы лучше иметь правильную параметризацию, например
ответ дан 12 мая ’20, 21:05
Спасибо, а что делает N? — законопроект
Это гарантирует, что ваш @sql переменная интерпретируется правильно как NVARCHAR — требование при использовании sp_executesql . — Аарон Бертран
Ну, они должны быть Int, потому что они используются как «Где RowNum Between @RowFrom и @RowTo». Параметр @ RowFrom / @ RowTo имеет тип int, а также Declared .. — законопроект
Да понял. Вы строите строку SQL и находитесь на двух уровнях области видимости. На верхнем уровне вы создаете строку — вся эта конкатенация должна быть со строковыми значениями, независимо от того, являются ли они «5», «foo» или «zuluxxy». Я добавлю пример для иллюстрации. — Аарон Бертран
Вы также можете получить это сообщение об ошибке, если переменная объявлена до GO и ссылка на него после него.
ответ дан 25 мар ’19, в 22:03
К вашему сведению, я знаю, что это старый пост, но в зависимости от настроек COLLATION базы данных вы можете получить эту ошибку в таком заявлении,
если, например, вы напечатали букву S в
извините, что отключаю уже опубликованные здесь ответы, но это реальный экземпляр сообщенной ошибки.
Также обратите внимание, что ошибка не будет отображать заглавную букву S в сообщении, я не уверен, почему, но я думаю, что это потому, что
находится слева от знака равенства.
ответ дан 01 апр.
Просто добавляю то, что исправило для меня, где неправильное написание является подозреваемым в соответствии с этот блог MSDN.
При разделении строк SQL на несколько строк убедитесь, что вы отделяете строку SQL от параметров запятой (и не пытаетесь их объединить!) И не пропускаете пробелов в конце каждой строки разделения. Не ракетостроение, но надеюсь, что избавлю кого-то от головной боли.
Иногда, если у вас есть оператор GO, написанный после использования переменной, и если вы попытаетесь использовать его после этого, он выдает такую ошибку. Попробуйте удалить инструкцию GO, если она у вас есть.
ответ дан 24 мая ’21, 07:05
Чувствительность к регистру также вызовет эту проблему.
@MyVariable и @myvariable — это одни и те же переменные в SQL Server Man. Студия так и будет работать. Однако использование этих переменных приведет к появлению сообщения «Необходимо объявить скалярную переменную« @MyVariable »в Visual Studio (C #) из-за различий в чувствительности к регистру.
Просто ответ для будущего меня (может быть, это поможет и кому-то другому!). Если вы попытаетесь запустить что-то подобное в редакторе запросов:
И вы получите ошибку:
Необходимо объявить скалярную переменную «@year»
Это потому, что вы пытаетесь запустить кучу кода, который включает И ТО И ДРУГОЕ выполнение хранимой процедуры И запрос под ним (!). Просто выделите тот, который хотите запустить, или удалите / закомментируйте тот, который вам неинтересен.
ответ дан 04 авг.
Если кто-то еще сталкивается с этим вопросом, в то время как никакое решение здесь не заставило мой файл sql работать, вот в чем была моя ошибка:
Я экспортировал содержимое своей базы данных с помощью команды «Создать сценарий» в Microsoft Server Management Studio, а затем выполнял некоторые операции, вставляя сгенерированные данные в другой экземпляр.
Из-за сгенерированного экспорта в sql-файле было несколько операторов «GO».
Чего я не знал, так это того, что переменные, объявленные в верхней части файла, недоступны, пока выполняется инструкция GO. Поэтому мне пришлось удалить операторы GO в моем файле sql и ошибка «Должна объявить скалярную переменную xy» исчезла!
ответ дан 19 окт ’20, 11:10
Скорее всего, это не ответ на саму проблему, но этот вопрос появляется как первый результат при поиске Sql declare scalar variable поэтому я делюсь возможным решением этой ошибки.
В моем случае эта ошибка была вызвана использованием ; после оператора SQL. Просто удалите его, и ошибка исчезнет.
Я предполагаю, что причина та же, что и @IronSean, уже опубликованный в комментарии выше:
Стоит отметить, что использование GO (или в данном случае;) вызывает новую ветку, в которой объявленные переменные не видны за оператором.
Необходимо объявить скалярную переменную
являются ли оба глобальных входных параметра для хранимой процедуры, и поскольку я компилирую 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#) из-за различий в чувствительности к регистру.
Должен объявить скалярную переменную
Необходимо объявить скалярную переменную «@ value1».
Я генерирую SQL динамически и хочу получить значение переменной. Что мне делать?
5 ответов
Причина, по которой вы получаете ошибку DECLARE из своего динамического оператора, заключается в том, что динамические операторы обрабатываются отдельными пакетами, что сводится к вопросу области действия. Хотя может быть более формальное определение областей, доступных в SQL Server, я счел достаточным, как правило, иметь в виду следующие три, упорядоченные от наивысшей доступности до самой низкой доступности:
Объекты, доступные для всего сервера, такие как временные таблицы, созданные с помощью двойного решетки / решетки ( ##GLOBALTABLE , как бы вы ни называли #). Будьте очень осторожны с глобальными объектами, как и с любым приложением, SQL Server или другим; таких вещей лучше вообще избегать. По сути, я говорю, что нужно иметь в виду эту область видимости специально как напоминание о том, что не стоит в нее входить.
Сессия :
Объекты, ссылки на которые привязаны к определенному spid. Вне всяких сомнений, единственный тип объекта сеанса, о котором я могу думать, — это обычная временная таблица, определенная как #Table. Нахождение в области сеанса по существу означает, что после завершения пакета (завершенного GO ) ссылки на этот объект продолжат успешно разрешаться. Эти технически доступны другим сеансам, но программно сделать это было бы неким подвигом, так как они получают в базе данных tempdb своего рода рандомизированные имена, и доступ к ним в любом случае затруднен.
Открывая новый сеанс (соединение с отдельным spid), второй пакет выше завершится ошибкой, так как этот сеанс не сможет разрешить имя объекта #t_Test .
Пакет :
Обычные переменные, такие как ваши @value1 и @value2 , имеют область видимости только для пакета, в котором они объявлены. В отличие от таблиц #Temp , как только ваш блок запроса достигает GO , эти переменные перестают быть доступными для сеанса. Это уровень объема, на котором возникает ваша ошибка.
Хорошо, и что?
Что происходит здесь с вашим динамическим оператором, так это то, что команда EXECUTE() эффективно оценивается как отдельный пакет, не прерывая пакет, из которого вы ее выполнили. EXECUTE() — это хорошо и все такое, но с момента появления sp_executesql() я использую первый только в самых простых случаях (явно, когда в моих утверждениях очень мало «динамических» элементов, в первую очередь для того, чтобы «обмануть» иначе неаккомодирующие операторы DDL CREATE для запуска в середине других пакетов). Ответ @ AaronBertrand, приведенный выше, аналогичен и по производительности будет аналогичен следующему, используя функцию оптимизатора при оценке динамические операторы, но я подумал, что стоит расширить, ну, параметр @param .
Вы также должны передать свой ввод, например, откуда приходит 61, в качестве правильных параметров (но вы не сможете передавать таким образом имена таблиц и столбцов).
Как правильно написать SQL запрос с использованием переменной?
Задача: разделить данные за сегодня и вчера по столбцам. Если использовать этот запрос без переменных то все работает. Анализ синтаксиса в excel пишет «необходимо объявить скалярную переменную @today» хотя я вроде его объявил в начале Используется MSSQL 2016
- Вопрос задан более трёх лет назад
- 658 просмотров
- Вконтакте
У вас в запросе пропущена секция from, т.е. select с полями есть и where с условиями есть, а вот из каких таблиц
это все выбрать нет.
Переменные у вас объявлены правильно и если выполнить первые три строки запроса, то ошибок не будет.
- Вконтакте
То все нормально работает
WebAnalytics1, странно все это, но вот если в вашем запросе правильно расставить алиасы у полей, то все работает, я вот такой запрос проверял:
Для эксперимента вот такие таблицы создал:
create table Orders (ID int, Status varchar(1))
go
create table OrderItems (Created datetime, Date datetime, OrderID int, ProductID int)
go
create table NomenclUS(ID int, CatID int, CatName varchar(20), Name varchar(20))
go