1с ключевое слово запроса написано не канонически

Обновлено: 03.07.2024

The text was updated successfully, but these errors were encountered:

Stepa86 commented Feb 13, 2019

Канон в модулях:

Если
Тогда
Иначе
ИначеЕсли
КонецЕсли
Для
Каждого
Цикл
КонецЦикла
Выполнить
По
Прервать
Продолжить
Из
Новый
Перейти
Перем
Пока
Попытка
Исключение
КонецПопытки
ВызватьИсключение
Процедура
КонецПроцедуры
Функция
КонецФункции
Возврат
ДобавитьОбработчик
УдалитьОбработчик
И
ИЛИ
НЕ
Или
Не
каждого

Канон в запросе:

ВЫБРАТЬ
КАК
ПО
ПОМЕСТИТЬ
АВТОУПОРЯДОЧИВАНИЕ
ИЕРАРХИЯ
ВЫБОР
ТОГДА
КОГДА
ЕСЛИ
КОНЕЦ
ИНАЧЕ
МЕЖДУ
В
В ИЕРАРХИИ
ПОДОБНО
ИМЕЮЩИЕ
УПОРЯДОЧИТЬ
ГДЕ
ИЗ
ИСТИНА
ЛОЖЬ
ПЕРВЫЕ
РАЗРЕШЕННЫЕ
ИТОГИ
ПОЛНОЕ
СОЕДИНЕНИЕ
ЛЕВОЕ
ПРАВОЕ
ВНУТРЕННЕЕ
РАЗЛИЧНЫЕ
УБЫВ
ВОЗР
СГРУППИРОВАТЬ ПО
ОБЩИЕ
НЕ
И
ИЛИ
ЕСТЬ NULL
ОБЪЕДИНИТЬ

nixel2007 commented Feb 13, 2019

В запросах вроде нет разночтений - должно быть капсом)

а вот в модулях "исторически" стандарт и мнение большинства кодеров различаются.

Stepa86 commented Feb 13, 2019

Это копипаст из АПК. Там видно, что Для Каждого и Для каждого - допустимо, как и ИЛИ или Или . А вот капсом писать уже не по стандарту

В стандарте сказано, "как в документации или Синтакс-помощнике".
Беда в том, что автодополнение в конфигураторе не совпадает с тем, что написано в помощнике. Видим, поэтому, АПК и поддерживает разные варианты для логических операций и для "каждого".
Я, кстати, обычно пользуюсь автодополнением, поэтому "Или" и "Каждого".

Собственно, я набросал черновик проверки, так что надо как-то найти общий знаменатель:

Оформление текстов запросов

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1. Все ключевые слова языка запросов пишутся заглавными буквами.

Методическая рекомендация (полезный совет)

2. Рекомендуется указывать и необязательные конструкции запроса, прежде всего - явно назначать псевдонимы полям, в целях повышения наглядности текста запроса и "устойчивости" использующего его кода. Например, если в алгоритме используется запрос с полем, объявленным как

при изменении имени реквизита нужно будет также изменить и код, осуществляющий обращение по имени свойства Валюта к выборке из результата запроса. Если же поле будет объявлено как

Касса.Валюта КАК Валюта

то изменение имени реквизита приведет только к изменению текста запроса.

2а. Особенно внимательно следует относиться к автоматически присваиваемым псевдонимам для полей – реквизитов других полей, типа ". Касса.Валюта.Наименование. ". В приведенном выше примере поле получит автоматический псевдоним ВалютаНаименование , а не Наименование .

2б. Следует обязательно указывать ключевое слово КАК перед псевдонимом поля источника.

3. Текст запроса должен быть структурирован, не следует писать запрос в одну строку, даже короткий. Текст запроса должен быть нагляден, поскольку это существенно улучшает его понимание другими разработчиками.

4. В запросы, сложные для понимания, в которых используются вложенные запросы, объединения или соединения рекомендуется вставлять комментарии. Комментарии, например, могут объяснять для получения каких данных используется та или иная таблица в соединении или объединении.

При этом необходимо иметь в виду, что при использовании конструктора запросов, все комментарии в запросе удаляются автоматически без предупреждения.

5. При создании объекта Запрос рекомендуется указывать комментарии, для получения какой информации или каких иных целей будет использован данный запрос.

6.1 При программной "сборке" текста запроса рекомендуется комментировать все этапы его сборки.

6.2. Нужно стараться, чтобы каждая часть формируемого запроса могла быть открыта с помощью конструктора запросов

это позволяет осуществить экспресс-проверку корректности синтаксиса запроса
это упрощает разработку и сопровождение кода конфигурации, в том числе сторонними разработчиками

Типичные случаи программной модификации текста запроса

Изменение имени поля выборки или таблицы

"ВЫБРАТЬ
| Номенклатура.Наименование КАК Наименование ,
| Номенклатура. " + ИмяПоляКод + " КАК КодАртикул
|ИЗ
| Справочник.Номенклатура КАК Номенклатура";

ТекстЗапроса =
"ВЫБРАТЬ
| Номенклатура.Наименование КАК Наименование,
| &ИмяПоляКод КАК КодАртикул
|ИЗ
| Справочник.Номенклатура КАК Номенклатура ;

ТекстЗапроса = СтрЗаменить(ТекстЗапроса , "&ИмяПоляКод ", "Номенклатура." + ИмяПоляКод);

или аналогично для имени таблицы

"ВЫБРАТЬ
| ТаблицаСправочника.Наименование КАК Наименование,
| ТаблицаСправочника.Код КАК Код
|ИЗ
| &ТаблицаСправочника КАК ТаблицаСправочника";
ТекстЗапроса = СтрЗаменить(ТекстЗапроса , "&ТаблицаСправочника", "Справочник." + ИмяСправочника);

или еще один вариант для имени таблицы

Конкатенация нескольких текстов запросов в пакет

Если ИспользоватьУпаковки Тогда

ТекстЗапроса = ТекстЗапроса +
"ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник. Номенклатура КАК Номенклатура";

Если ИспользоватьУпаковки Тогда

"ВЫБРАТЬ
| Упаковки.Ссылка КАК Ссылка
|ИЗ
| Справочник.Упаковки КАК Упаковки";

ТекстЗапроса = ТекстЗапроса +
"ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник.Номенклатура КАК Номенклатура";

ТекстыЗапросовПакета = Новый Массив;

ТекстЗапроса =
"ВЫБРАТЬ
| Упаковки.Ссылка КАК Ссылка
|ИЗ
| Справочник.Упаковки КАК Упаковки";

ТекстЗапроса =
"ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник.Номенклатура КАК Номенклатура ";

ТекстыЗапросовПакета.Добавить(ТекстЗапроса);
ТекстЗапроса = СтрСоединить(ТекстыЗапросовПакета, Разделитель);

Проблема: В некоторых случаях результат ограничений доступа к данным в 1С 8.3 может зависеть от плана запроса СУБД. В данной статье рассмотрены возможные ситуации и даны рекомендации, как этого избежать.

Условия возникновения проблемы

Проблема возможной зависимости результата ограничений доступа к данным от плана запроса СУБД может возникнуть при выполнении запроса к базе данных без ключевого слова РАЗРЕШЕННЫЕ, если для текущего пользователя имеются ограничения доступа к данным и при этом запрос содержит одно или несколько сравнений вида:

Причина различий

Возможная разница в поведении объясняется реализацией ограничений доступа к данным без ключевого слова РАЗРЕШЕННЫЕ в 1С Предприятии 8.3.

Запрос без ключевого слова РАЗРЕШЕННЫЕ будет выполнен успешно только в том случае, если в процессе его выполнения не происходит обращений к запрещенным данным. Для этого в выборке данных добавляется специальное сигнальное поле, которое принимает значение Истина для тех записей, в формировании которых участвовали только разрешенные данные, и значение Ложь для всех остальных записей. Если хотя бы в одной записи выборки имеется значение Ложь в сигнальном поле, то выполнение запроса завершается аварийно.

Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>

Такое же сигнальное поле добавляется и к результатам запросов, вложенных в сравнение В/НЕ В. Причем проверка значения сигнальной колонки в этом случае выполняется средствами СУБД. Таким образом, если в процессе выполнения вложенного запроса происходило обращение к запрещенным данным, то выполнение запроса должно завершиться с ошибкой У пользователя недостаточно прав на исполнение операции над базой данных.

Однако при построении плана запроса СУБД может не получать полную выборку <Вложенным запросом>, а получать только те записи, которые фактически необходимы для проверки условия В/НЕ В. В этом случае выполнение запроса может оказаться успешным, даже если при выполнении <Вложенного запроса> как самостоятельного запроса могли произойти обращения к запрещенным данным.

Пример и рекомендации

Рассмотрим простой пример. Пусть на таблицу Справочник.ФизическиеЛица наложены ограничения доступа к данным. В этом случае запрос:

ВЫБРАТЬ

Таблица.ФизЛицо КАК ФизЛица

ИЗ

Справочник.ФизическиеЛица КАК Таблица

будет выполнен с ошибкой из-за попытки обращения к запрещенным данным. Если же этот запрос участвует в сравнении, например:

ВЫБРАТЬ

ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо

ИЗ

Документ.ДоговорНаВыполнениеРаботСФизЛицом КАК ДоговорНаВыполнениеРаботСФизЛицом

ГДЕ

ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо В (

ВЫБРАТЬ

Таблица.ФизЛицо КАК ФизЛица

ИЗ

Справочник.ФизическиеЛица КАК Таблица)

то в зависимости от выбранного СУБД плана запроса запрос может быть выполнен как успешно, так и с ошибкой. Такое поведение запроса не является ошибочным, поскольку обращение к запрещенным данным в процессе выполнения этого запроса может произойти, а может и не произойти. Для получения более предсказуемого результата необходимо построить запрос таким образом, чтобы вложенный запрос гарантированно не выполнял обращений к заведомо ненужным данным. В частности, если предыдущий запрос переписать так:

ВЫБРАТЬ

ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо

ИЗ

Документ.ДоговорНаВыполнениеРаботСФизЛицом КАК ДоговорНаВыполнениеРаботСФизЛицом

ГДЕ

ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо В (

ВЫБРАТЬ

Таблица.ФизЛицо КАК ФизЛица

ИЗ

Справочник.ФизическиеЛица КАК Таблица

ГДЕ

Таблица.ФизЛицо = ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо)

Данный запрос отличается от предыдущего тем, что вложенный запрос не выбирает записей, которые заведомо не требуются для выполнения сравнения В. Поэтому он завершится успешно, если ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо ссылается только на разрешенные записи таблицы Справочник.ФизическиеЛица, и аварийно, если среди ДоговорНаВыполнениеРаботСФизЛицом.Сотрудник.Физлицо имеются ссылки на запрещенные записи.

Почти все объекты метаданных, например справочники, документы, константы и т.п. имеют свои таблицы в базе данных. Запись в таблицу выполняется через объект. Запись и чтение через объект называется объектной моделью. Например:

ОплатаНаСчет = Документы . ОплатаНаСчет . СоздатьДокумент ( ) ;

С помощью объектной модели можно как записывать данные, так и читать. Но для чтения есть множество ограничений. Отборы можно накладывать только на код, наименование или индексированные реквизиты, за один раз можно обратиться только к одному источнику.

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

Язык запросов 1С и SQL

Язык запросов 1С очень сильно похож на язык SQL, если вы уже знакомы с языком SQL, то вам легко будет разобраться в языке запросов 1С.

Рассмотрим основные отличия:

В языке запросов 1С можно только выбирать данные из базы. Грубо говоря из SQL реализована только конструкция SELECT
В 1С в качестве выходного поля нельзя использовать другой запрос, зато можно выбрать табличную часть (будет представлена в виде вложенной таблицы)
Из языка запросов 1С нельзя обращаться к хранимым процедурам (stored procedure) и представлениям (view) СУБД
Зато в языке запросов 1С можно разыменовывать поля, например: Оплата.Контрагент.Наименование
В 1С добавлена конструкция ИТОГИ
Из языка запросов 1С нет доступа к таблицам СУБД. Есть только доступ к таблицам, которые предоставляет платформа 1С. А уже платформа транслирует запрос на языке запросов 1С в запрос на языке SQL.
В языке запросов 1С можно использовать как русский язык, так и английский.

Консоль запросов

При изучении языка запросов мы будем пользоваться консолью запросов, чтобы писать запросы прямо в пользовательском режиме и сразу видеть результат.

Консоль запросов выглядит так:

В поле Текст запроса пишется сам запрос. В поле Результат запроса будет результат выполнения запроса. В верхнем поле указываются параметры запроса, к ним мы вернемся позже.

Мы не будем им пользоваться, чтобы лучше разобраться в языке запросов. Хотя на практике им очень удобно пользоваться. Но выучив язык запросов вы без труда разберетесь с ним сами.

Ссылки на консоль запросов:

Привет мир

Читайте также: