20.09.2014

Existe uma diretiva "Permitido" na linguagem de consulta. Destina-se a ser usado pela estrutura para filtrar registros aos quais o usuário não tem direitos ao definir um limite de nível de registro de banco de dados.

Parece que nas consultas é melhor sempre usar esta diretiva. Vou argumentar que este não é o caso. Além disso, vou argumentar que, se possível, você deve evitar usá-lo, é por isso.

Digamos que fazemos um relatório sobre acordos mútuos de indivíduos. O usuário tem direitos para uma organização e há mais de uma organização no banco de dados e a restrição de nível de registro está habilitada no banco de dados. Além disso, o banco de dados possui um registro "Acordos Mútuos" com as dimensões "Organização" e "Pessoa Física". Se houver uma solicitação no sistema

"Escolher

Organização,

Individual

e será executado em nome de um usuário com permissão para uma organização, então a consulta falhará se houver registros de outras organizações neste cadastro. Ocorrerá um erro e a descrição do erro será "O usuário não possui direitos suficientes para concluir a solicitação!" e isso é verdade, a plataforma não trapaceia, pois não possui direitos sobre os registros de outras organizações neste registro.

O que fazer neste caso, use a diretiva "Permitido"? Não vale a pena em minha opinião. Basta definir a seleção por organização e o usuário poderá gerar um relatório. A consulta de um relatório com composição de dados ficará assim

"Escolher

Organização,

Individual

(Escolher

Organização

Individual)

Do Registro de Acumulação. Liquidações Mútuas

(Onde

Organização

Individual)

Se o usuário executar uma consulta na tabela sem seleção, então o relatório não será gerado, e o usuário não reconhecerá os dados para outras organizações, e se definir a seleção para sua organização, gerará os dados corretos.

Você pode perguntar novamente - "Por que você não deveria usar a diretiva Permitido", isso impõe imediatamente uma seleção, salva o usuário de mensagens de que ele não precisa!

A resposta a esta pergunta será a seguinte - como neste caso o usuário saberá que todos os dados necessários foram incluídos no relatório. Suponha que, anteriormente, esse usuário trabalhasse com plenos direitos e cometesse um erro e escolhesse um indivíduo de outra organização no documento. Também pode haver uma situação, os dados estavam sendo carregados - e uma subdivisão de outra organização foi registrada nos documentos da organização (no ZUP, também são impostas restrições ao proprietário). Nesse caso, a diretiva "Permitido" cortará os dados proibidos sem nenhuma mensagem ao usuário, e ele não saberá que nem tudo que deveria constar no relatório foi incluído.

Portanto, não é necessário inserir esta diretriz em massa em solicitações de configurações típicas, considerando isso um erro. É altamente desencorajado fazer isso em solicitações de relatórios regulamentados. Além disso, não faça isso em outros relatórios e documentos em que a precisão das informações seja necessária.

Mas como ainda evitar o erro de "cair" o programa com falta de direitos?

Sim, é muito simples, você precisa usar o comando "Try", veja um exemplo:

Tentar

Request.Execute();

Exceção

Report(ErroDescrição());

Fim da Tentativa;

Nos laudos que utilizam ACS, o código do programa para execução do laudo deve ser escrito manualmente, também por tentativa.

Como resultado, o usuário não receberá dados incorretos e receberá uma mensagem de erro sã.

Você pode se familiarizar com as nuances da configuração do RLS em divisões separadas em nosso artigo.

). O uso desta palavra-chave evita um erro ao obter registros para os quais o usuário não possui direitos.

Problema: Em alguns casos, o resultado das restrições de acesso a dados em 1C 8.3 pode depender do plano de consulta do DBMS. Este artigo discute possíveis situações e dá recomendações sobre como evitá-lo.

O problema da possível dependência do resultado das restrições de acesso a dados no plano de consulta do DBMS pode surgir quando uma consulta ao banco de dados é executada sem a palavra-chave PERMITIDO se houver restrições de acesso a dados para o usuário atual e a consulta contiver uma ou mais comparações do formulário:

• <Выражение над полями>(DENTRO|NÃO DENTRO) (<Вложенный запрос>)
• (<Выражение над полями 1>, …, <Выражение над полями N>) (DENTRO|NÃO ENTRA) (<Вложенный запрос>)

Se neste caso < > (consulta em uma consulta) usa tabelas de banco de dados que estão sujeitas a restrições de acesso, então é possível que a consulta seja executada com sucesso em alguns SGBDs e uma mensagem seja emitida em outros, desde que os dados nas infobases sejam completamente idênticos .

Obtenha 267 videoaulas 1C gratuitamente:

Motivo das diferenças

A possível diferença de comportamento se deve à implementação de restrições de acesso a dados sem a palavra-chave PERMITIDO em 1C Empresa 8.3.

Consulta sem uma palavra-chave PERMITIDO será executado com sucesso somente se durante sua execução não houver acessos a dados proibidos. Para fazer isso, um campo de sinal especial é adicionado a ele, que leva o valor Verdadeiro para aqueles registros em cuja formação participaram apenas dados permitidos, e o valor Mentira para todas as outras entradas. Se pelo menos um registro da seleção contiver o valor Mentira no campo de sinal, então a consulta termina de forma anormal.

O mesmo campo de sinal é adicionado aos resultados das consultas aninhadas na comparação. EM/NÃO EM. Além disso, a verificação do valor da coluna de sinal neste caso é realizada por meio do DBMS. Assim, se no processo de execução de uma consulta aninhada foram acessados ​​dados proibidos, a execução da consulta deve terminar com um erro O usuário não tem direitos suficientes para executar uma operação no banco de dados.

No entanto, ao construir um plano de consulta, o SGBD pode não receber a seleção completa <Вложенным запросом> , e obter apenas os registros que são realmente necessários para verificar a condição EM/NÃO EM. Nesse caso, a consulta pode ser bem-sucedida mesmo se <Вложенного запроса> o acesso a dados proibidos pode ocorrer como uma solicitação independente.

Vamos considerar um exemplo simples. Deixe na mesa Diretório.Indivíduos restrições de acesso a dados. Neste caso, o pedido é:

Tabela.Individual AS Individual

será executado com um erro devido a uma tentativa de acesso a dados proibidos. Se esta consulta estiver envolvida na comparação, por exemplo:

Tabela.Individual AS Individual

Diretório.Tabela AS de Pessoas Físicas)

então, dependendo do plano de consulta selecionado pelo SGBD, a consulta pode ser executada com sucesso ou com erro. Este comportamento da requisição não é errôneo, pois o acesso a dados proibidos durante a execução desta requisição pode ou não ocorrer. Para obter um resultado mais previsível, é necessário construir uma consulta de forma que a consulta aninhada tenha a garantia de não realizar acessos a dados obviamente desnecessários. Em particular, se a consulta anterior for reescrita assim:

Contrato de Execução de Trabalho com Pessoa Física. Empregado. Pessoa Física

Documento. Contrato para a Execução do Trabalho com um Indivíduo COMO um Acordo para a Execução do Trabalho com um Indivíduo

Contrato de Execução de Trabalho com Pessoa.Funcionário.Pessoa Física B (

Tabela.Individual AS Individual

Diretório.Tabela AS de Pessoas Físicas

A linguagem de consulta é um dos mecanismos fundamentais do 1C 8.3 para desenvolvedores. Com a ajuda de consultas, você pode obter rapidamente todos os dados armazenados no banco de dados. Sua sintaxe é muito semelhante ao SQL, mas existem algumas diferenças.

As principais vantagens da linguagem de consulta 1C 8.3 (8.2) sobre SQL:

• desreferenciar campos de referência (transformar um ou mais pontos em atributos de objetos);
• trabalhar com os resultados é muito conveniente;
• a capacidade de criar tabelas virtuais;
• a solicitação pode ser escrita em inglês e em russo;
• a capacidade de bloquear dados para evitar impasses.

Desvantagens da linguagem de consulta em 1C:

• ao contrário do SQL, em 1C as consultas não permitem que você altere os dados;
• falta de stored procedures;
• a impossibilidade de converter uma string em um número.

Considere nosso mini tutorial sobre as construções básicas da linguagem de consulta 1C.

Devido ao fato de que as solicitações em 1C permitem apenas receber dados, qualquer solicitação deve começar com a palavra "SELECT". Após este comando, são indicados os campos dos quais você deseja obter os dados. Se você especificar "*", todos os campos disponíveis serão selecionados. O local de onde os dados serão selecionados (documentos, registros, diretórios, etc.) é indicado após a palavra "DE".

No exemplo abaixo, os nomes de toda a nomenclatura são selecionados do livro de referência "Nomenclatura". Após a palavra “COMO”, são indicados aliases (nomes) para tabelas e campos.

ESCOLHER
Nomenclatura.Nome AS NomeNomenclatura
DE
Diretório Nomenclatura AS Nomenclatura

Ao lado do comando "SELECT", você pode especificar palavras-chave:

• VÁRIOS. A consulta selecionará apenas as linhas que diferem em pelo menos um campo (sem duplicatas).
• Primeiro n, Onde n– o número de linhas desde o início do resultado a ser selecionado. Na maioria das vezes, essa construção é usada em conjunto com a classificação (ORDER BY). Por exemplo, quando você precisa selecionar um determinado número de documentos mais recentes por data.
• PERMITIDO. Esse design permite selecionar no banco de dados apenas os registros que estão disponíveis para o usuário atual. Se esta palavra-chave for usada, o usuário receberá uma mensagem de erro se tentar consultar registros aos quais não tem acesso.

Essas palavras-chave podem ser usadas juntas ou separadamente.

PARA MUDAR

Esta cláusula bloqueia os dados para evitar conflitos. Os dados bloqueados não serão lidos de outra conexão até o final da transação. Nesta cláusula, você pode especificar tabelas específicas que deseja bloquear. Caso contrário, todos serão bloqueados. O design é relevante apenas para o modo de bloqueio automático.

Na maioria das vezes, a cláusula "FOR CHANGE" é usada ao receber saldos. De fato, quando vários usuários trabalham no programa ao mesmo tempo, enquanto um recebe os saldos, o outro pode alterá-los. Nesse caso, o saldo resultante não será mais correto. Se você bloquear os dados com esta proposta, até que o primeiro funcionário receba o saldo correto e faça todas as manipulações necessárias com ele, o segundo funcionário terá que esperar.

ESCOLHER
Liquidações mútuas. Empregado,
Liquidações mútuas Valor Liquidações mútuas Saldo
DE
Registro de Acumulação. Liquidações Mútuas COM Empregados. Saldos AS Liquidações Mútuas
PARA MUDAR

ONDE

A construção é necessária para impor qualquer seleção nos dados descarregados. Em alguns casos de obtenção de dados de registradores, é mais razoável prescrever condições de seleção nos parâmetros das tabelas virtuais. Ao usar "WHERE", todos os registros são obtidos primeiro e só então a seleção é aplicada, o que retarda significativamente a consulta.

O seguinte é um exemplo de solicitação para obter pessoas de contato com uma posição específica. O parâmetro de seleção tem o seguinte formato: &ParameterName (o nome do parâmetro é arbitrário).

SELEÇÃO (CASO)

A construção permite especificar condições diretamente no corpo da solicitação.

No exemplo abaixo, o "AdditionalField" conterá texto dependendo se o documento está postado ou não:

ESCOLHER
AdmissãoT&U.Link,
ESCOLHA
QUANDO
ENTÃO "Documento postado!"
ELSE "Documento não publicado..."
END AS Campo Adicional
DE
Documento.Recibo de MercadoriasServiços como ReciboT&C

JUNTAR

As uniões vinculam duas tabelas por uma determinada condição de vínculo.

JUNÇÃO ESQUERDA/DIREITA

A essência da junção LEFT é que a primeira tabela especificada é tomada completamente e a segunda é anexada a ela pela condição da conexão. Se não houver registros correspondentes à primeira tabela na segunda, então NULL é substituído como seus valores. Simplificando, a tabela principal é a primeira tabela especificada e os dados da segunda tabela (se houver) já estão substituídos por seus dados.

Por exemplo, você precisa obter itens de itens dos documentos “Recebimento de mercadorias e serviços” e preços do registro de informações “Preços de itens”. Nesse caso, se o preço de alguma posição não for encontrado, substitua NULL. Todos os itens do documento serão selecionados independentemente de terem um preço ou não.

ESCOLHER
Recebimento de T&U. Nomenclatura,
Preços.Preço
DE
Documento.Recibo de MercadoriasServiços.Recibo de Mercadorias T&C
JUNÇÃO INTERNA
NO recebimento de perguntas e respostas.Nomenclatura = Preços.Nomenclatura

Na DIREITA, tudo é exatamente o contrário.

CONEXÃO COMPLETA

Este tipo de junção difere dos anteriores porque todos os registros da primeira tabela e da segunda serão retornados como resultado. Se nenhum registro for encontrado na primeira ou na segunda tabela para a condição de link especificada, NULL será retornado.

Ao usar a junção completa no exemplo anterior, todos os itens do documento Recebimento de Mercadorias e Serviços e todos os preços mais recentes do registro de Preços do Item serão selecionados. Os valores dos registros não encontrados, tanto na primeira quanto na segunda tabela, serão NULL.

JUNÇÃO INTERNA

A diferença entre uma junção INNER e uma junção FULL é que, se um registro não for encontrado em pelo menos uma das tabelas, a consulta não o exibirá. Como resultado, serão selecionados apenas os itens do documento Recebimento de Mercadorias e Serviços para os quais existem entradas no cadastro de informações de Preços do Item, se no exemplo anterior substituirmos COMPLETO por INTERNO.

GRUPO POR

O agrupamento em consultas 1C permite recolher as linhas da tabela (agrupamento de campos) de acordo com um determinado recurso comum (agrupamento de campos). Os campos de agrupamento só podem ser exibidos usando funções de agregação.

O resultado da próxima consulta será uma lista de tipos de itens com seus preços máximos.

ESCOLHER
,
MAX(Preço.Preço) AS Preço
DE

GRUPO POR
Preços.Nomenclatura.TipoNomenclatura

RESULTADOS

Ao contrário do agrupamento, ao usar totais, todos os registros são exibidos e as linhas de totais já são adicionadas a eles. O agrupamento exibe apenas registros generalizados.

Os resultados podem ser resumidos para toda a tabela (usando a palavra-chave "GENERAL"), para vários campos, para campos com uma estrutura hierárquica (palavras-chave "HIERARCHY", "ONLY HIERARCHY"). Ao somar, não é necessário usar funções de agregação.

Considere um exemplo semelhante ao exemplo acima usando agrupamento. Nesse caso, o resultado da consulta retornará não apenas campos agrupados, mas também registros detalhados.

ESCOLHER
Preços.Nomenclatura.Tipo de Nomenclatura AS Tipo de Nomenclatura,
Preços. Preço AS Preço
DE
RegisterInformation.PricesNomenclature.SliceLast AS Preços
RESULTADOS
MÁXIMO(Preço)
POR
Tipo de Nomenclatura

TENDO

Esse operador é semelhante ao operador WHERE, mas é usado apenas para funções de agregação. Outros campos que não os utilizados por este operador devem ser agrupados. O operador "WHERE" não é aplicável para funções de agregação.

No exemplo abaixo, os preços máximos do item são selecionados se excederem 1000, agrupados por tipo de item.

ESCOLHER

MAX(Preço.Preço) AS Preço
DE
RegisterInformation.PricesNomenclature.SliceLast AS Preços
GRUPO POR
Preços.Nomenclatura.TipoNomenclatura
TENDO
MAX(Preços.Preço) > 1000

ORDENAR POR

O operador "ORDER BY" classifica o resultado da consulta. Para garantir que os registros sejam gerados em uma ordem consistente, o AUTO-ORDER é usado. Os tipos primitivos são classificados de acordo com as regras usuais. Os tipos de referência são classificados por GUID.

Um exemplo de obtenção de uma lista de funcionários classificados por nome:

ESCOLHER
Empregados.Nome AS Nome
DE
Diretório Funcionários AS Funcionários
ORDENAR POR
Nome
ORDEM AUTOMÁTICA

Outras construções da linguagem de consulta 1C

• UNIR- os resultados de duas consultas em uma.
• UNIR TODOS– semelhante a JOIN, mas sem agrupar linhas idênticas.
• TABELA VAZIA- às vezes usado ao unir consultas para especificar uma tabela aninhada vazia.
• COLOCAR- cria uma tabela temporária para otimizar consultas 1C complexas. Essas solicitações são chamadas de solicitações em lote.

Recursos de linguagem de consulta

• SUBSTRING trunca uma string de uma posição especificada pelo número especificado de caracteres.
• ANO... SEGUNDO permitem que você obtenha o valor selecionado do tipo numérico. O parâmetro de entrada é uma data.
• INÍCIO DO PERÍODO E FIM DO PERÍODO são usados ​​ao trabalhar com datas. O tipo de período (DIA, MÊS, ANO, etc.) é especificado como um parâmetro adicional.
• ADICIONAR permite adicionar ou subtrair da data a hora especificada de um determinado tipo (SEGUNDO, MINUTO, DIA, etc.).
• DIFERENÇA DE DATA determina a diferença entre duas datas, especificando o tipo de valor de saída (DIA, ANO, MÊS, etc.).
• É NULO substitui o valor ausente pela expressão especificada.
• APRESENTAÇÃO e APRESENTAÇÃOLINKS obter a representação de string do campo especificado. Eles são usados ​​para quaisquer valores e apenas valores de referência, respectivamente.
• TIPO, TIPO DE VALOR são usados ​​para determinar o tipo do parâmetro de entrada.
• LINKé um operador de comparação lógica para o tipo de valor de atributo.
• EXPRESSARé usado para converter o valor para o tipo desejado.
• DATA HORA obtém um valor do tipo "Data" a partir de valores numéricos (Ano, Mês, Dia, Hora, Minuto, Segundo).
• SIGNIFICADO em uma solicitação 1C, é usado para especificar valores predefinidos - diretórios, enumerações, planos para tipos de características. Exemplo de uso: " Onde LegalIndividual = Value(Enumeration.LegalIndividual.Individual)«.

Construtor de consultas

Para criar consultas com 1C, existe um mecanismo interno muito conveniente - o designer de consultas. Ele contém as seguintes guias principais:

• "Tabelas e campos" - contém os campos a serem selecionados e suas fontes.
• "Links" - descreve as condições para a construção CONNECTION.
• "Agrupamento" - contém uma descrição das construções de agrupamentos e campos resumidos por eles.
• "Condições" - é responsável pela seleção de dados no pedido.
• "Avançado" - parâmetros de consulta adicionais, como as palavras-chave do comando "SELECT", etc.
• “Joins / Aliases” - as possibilidades de junção de tabelas são indicadas e os aliases são definidos (a construção “COMO”).
• "Pedido" - é responsável por classificar o resultado das consultas.
• "Totais" - semelhante à guia "Agrupamento", mas é usado para a construção de "TOTAIS".

O texto da solicitação em si pode ser visualizado clicando no botão "Solicitar" no canto inferior esquerdo. Neste formulário, pode ser corrigido manualmente ou copiado.

Consola de consulta

Para visualizar rapidamente o resultado de uma consulta no modo "Enterprise" ou para depurar consultas complexas, use . O texto da consulta é escrito nele, os parâmetros são definidos e seu resultado é mostrado.

Você pode baixar o console de consulta no disco ITS ou por .

O objeto de configuração "role" fornece um conjunto de direitos para operações (ações) em objetos de configuração.

Função "Direitos totais".

Esta é apenas uma função (não predefinida) que possui caixas de seleção para todos os tipos de direitos em todos os objetos de configuração.

Sua diferença em relação a outras funções é a presença do direito “Administração”.

Se pelo menos um usuário for criado, o sistema começa a verificar o direito "Administração" - pelo menos um usuário deve tê-lo.

Restringir o acesso no nível do registro

Row Level Security (RLS) - Restrição no nível do registro.

O mecanismo de restrições de acesso a dados permite gerenciar os direitos de acesso não apenas no nível dos objetos de metadados, mas também no nível dos objetos do banco de dados. Os seguintes objetos podem ser usados ​​para restringir o acesso aos dados:

• papéis,
• opções de sessão,
• opções funcionais,
• módulos comuns privilegiados,
• palavra-chave ALLOWED na linguagem de consulta.

O mecanismo é projetado para restringir o acesso aos registros da tabela de objetos de metadados de acordo com condições arbitrárias impostas aos valores dos campos de linha dessas tabelas. Por exemplo, para ver registros apenas para "suas" contrapartes, organizações, etc.

Implementação técnica de restrições de acesso em 1C

1C gera uma solicitação para o DBMS. O cluster de servidor adiciona uma seção WHERE à solicitação, que contém o texto da condição para restringir o acesso por RLS, então esta solicitação é enviada ao DBMS, os dados extraídos são retornados ao cliente 1C.

Este mecanismo funcionará para qualquer solicitação do cliente:

• nos relatórios
• em listas dinâmicas e formulários de lista regulares
• em pedidos aleatórios.

Essa implementação do mecanismo afeta muito o desempenho.

Formas de contornar as restrições de acesso.

Em grandes operações com uso intensivo de recursos (processamento de repostagem de documentos, por exemplo), parte do código pode ser movida para módulos privilegiados.

A) módulo privilegiado é um módulo compartilhado com o sinalizador "Privilegiado" nas propriedades.

Sua peculiaridade reside no fato de que o código nele contido é executado sem qualquer controle de acesso, inclusive RLS.

B) Também privilegiado modo pode ser ativado para módulos de objeto de documento. Isso é feito nas propriedades do documento, sinalizador

• Modo privilegiado ao segurar
• Modo privilegiado ao desmarcar

C) Método SetPrivilegedMode()

Um comando do sistema que permite fazer parte do código de qualquer módulo privilegiado.

A partir da próxima linha de código, o modo privilegiado de execução estará em vigor.

Atuará até a linha para desabilitar este modo ou até o final do procedimento/função

(Verdadeiro);

// qualquer código aqui será executado sem controle de direitos e RLS

DefinirModo Privilegiado(Mentira ); // ou fim do procedimento/função

O número de ativações do modo privilegiado deve corresponder ao número de desativações. Porém, se o modo privilegiado foi habilitado (uma ou mais vezes) dentro de um procedimento ou função, mas não foi desabilitado, o sistema fará automaticamente o desligamento quantas vezes houver ativações pendentes no procedimento ou função que está sendo abandonada.

Se em um procedimento ou chamada de método de função DefinirModo Privilegiado(Falso) mais do que chamadas de método feitas DefinirModo Privilegiado(verdadeiro) então uma exceção será lançada

Função Modo Privilegiado() retorna True se o modo privilegiado ainda estiver habilitado e False se o modo privilegiado estiver completamente desabilitado. Ele não analisa o número de configurações de modo privilegiado em uma função específica.

Todos os procedimentos e funções chamados também serão executados no modo privilegiado.

Também é possível iniciar uma sessão privilegiada. Esta é uma sessão em que o modo privilegiado é definido desde o início do sistema. Ao mesmo tempo, durante a operação, o método Modo Privilegiado() sempre retornará True , e a capacidade de desabilitar o modo privilegiado não é suportada. Somente um usuário com direitos administrativos (o direito Administração) pode iniciar uma sessão privilegiada. A sessão pode ser iniciada usando a opção de linha de comando para ativar o aplicativo cliente UsePrivilegedMode ou o parâmetro de cadeia de conexão da infobase prmod .

A questão surge naturalmente: Por que, então, configurar restrições de acesso, se isso pode ser contornado tão facilmente?

Modo de segurança.

Sim, é possível gravar processamento externo com modo de execução privilegiado e descarregar/corromper dados. Para evitar isso, o sistema possui um método de contexto global

Definir modo de segurança().

O modo de segurança, entre outras coisas, ignora o modo privilegiado.

Ele deve ser definido antes de chamar manipuladores externos programaticamente ou exportar procedimentos e funções de seus módulos.

Lança uma exceção ao executar operações proibidas em tempo de execução.

Além disso, para os usuários, você pode desativar a capacidade de iniciar relatórios externos de forma interativa e processar no nível de configurações de função.

Configuração de restrição de acesso

O RLS só pode ser configurado para direitos:

• leitura (selecione)
• adicionando (inserir)
• mudar (atualizar)
• exclusão (excluir)

Para operações de leitura e exclusão, o objeto no banco de dados deve obedecer à restrição de acesso aos dados.

Para a operação de adição a restrição de acesso aos dados deve corresponder ao objeto que está planejado para ser gravado no banco de dados.

Para a operação de mudança A restrição de acesso aos dados deve corresponder ao objeto antes da alteração (para o objeto a ser lido) e após a alteração (para o objeto a ser gravado).

Para todos os outros direitos, esta opção não está disponível.

Vamos adicionar uma nova restrição para o direito de "leitura" do livro de referência "Nomenclatura". Uma lista de campos para os quais você pode configurar a restrição adicionada será aberta.

Isso significa que se você tentar acessar os campos marcados, a restrição funcionará, e se você tentar acessar os campos não marcados, a restrição não funcionará.

Se você selecionar a bandeira Outros campos”, a restrição será definida para todos os campos da tabela, exceto para os campos para os quais as restrições são definidas explicitamente.

*Recurso: para os direitos de adicionar, alterar, excluir:

• A restrição só pode ser configurada para todos os campos.
• Só pode haver um limite.

Para o direito "Ler", você pode definir várias condições, elas serão combinadas com o operador lógico "AND".

Nas restrições de objetos de banco de dados dos seguintes tipos, nem todos os campos do objeto de dados principal da restrição podem ser usados:

• em registros de acumulação, as restrições de acesso podem conter apenas medições do objeto principal de restrição;
• em registros contábeis em restrições, você pode usar apenas as medições de saldo do objeto principal da restrição

Se, nas condições de acesso limitado aos dados do registro de giro de acumulação, forem usadas medições que não estão incluídas nos totais, ao acessar a tabela de giro virtual, os totais armazenados não são usados ​​e a consulta é executada completamente de acordo para a mesa de movimento.

O mecanismo para impor restrições de acesso.

Qualquer operação nos dados armazenados no banco de dados em 1C:Enterprise resulta no acesso ao banco de dados com alguma solicitação para ler ou modificar os dados. Durante a execução de consultas ao banco de dados, mecanismos internos do 1C:Enterprise impõem restrições de acesso. Em que:

• A lista de direitos é formada(ler, adicionar, atualizar, excluir), uma lista de tabelas de banco de dados e uma lista de campos usados ​​por esta consulta.
• De todas as funções do usuário atual selecionar restrições de acesso aos dados de todos os direitos, tabelas e campos envolvidos na solicitação. Além disso, se qualquer função não contiver restrições de acesso aos dados de qualquer tabela ou campo, isso significa que os valores dos campos obrigatórios de qualquer registro estão disponíveis nesta tabela. Em outras palavras, a ausência de uma restrição de acesso a dados significa que existe uma restrição WHERE True.
• Obtenha valores atuais de todos os parâmetros de sessão e opções funcionais participando das restrições selecionadas.

Obter o valor de um parâmetro de sessão ou opção funcional não exige que o usuário atual tenha o direito de obter esse valor. No entanto, se o valor de algum parâmetro da sessão não tiver sido definido, ocorrerá um erro e a consulta ao banco de dados não será executada.

As restrições derivadas da mesma função são combinadas com uma operação AND.

As restrições recebidas de diferentes funções são combinadas com a operação OR.

As condições construídas são adicionadas às consultas SQL com as quais 1C:Enterprise acessa o SGBD. Ao acessar dados do lado das condições de restrição de acesso, nenhuma verificação de direitos é executada (nem para objetos de metadados, nem para objetos de banco de dados). Além disso, o mecanismo para adicionar condições depende do modo de operação escolhido das restrições “todas” ou “permitidas”.

*Funcionalidade: Se um usuário tiver acesso a várias funções com restrições configuradas no nível de registros para um objeto, nesse caso, as condições de restrições são adicionadas pela operação lógica "OU". Em outras palavras, as permissões do usuário são cumulativas.

Isso leva à seguinte conclusão: não permita que a condição de restringir o acesso a um objeto em funções diferentes seja cruzada, pois neste caso o texto da consulta ficará muito mais complicado e isso afetará o desempenho.

Todo a Pista.

Quando são impostas restrições pelo método “all”, condições e campos são adicionados às consultas SQL para que 1C:Enterprise obtenha informações sobre se os dados proibidos para determinado usuário foram utilizados no processo de execução de uma consulta ao banco de dados ou não . Se dados proibidos tiverem sido usados, a solicitação será interrompida devido a uma violação de acesso.

A imposição de restrições de acesso pelo método “todos” é mostrada esquematicamente na figura:

Método "Permitido".

Quando as restrições são impostas usando o método “permitido”, tais condições são adicionadas às consultas SQL para que as entradas proibidas para o usuário atual não afetem o resultado da consulta. Em outras palavras, quando as restrições são impostas no modo “permitido”, os registros proibidos para este usuário são considerados ausentes e não afetam o resultado da operação, que é mostrado esquematicamente na figura:

Restrições de acesso a dados são impostas a objetos de banco de dados quando 1C:Enterprise acessa o banco de dados.

Na versão cliente-servidor do 1C:Enterprise, as restrições são aplicadas no servidor 1C:Enterprise.

No entanto, esta opção (ALLOWED) não funcionará se nos referirmos a uma tabela na consulta para a qual as restrições de acesso não estão configuradas, mas na qual existem links para linhas da tabela com restrições configuradas. Neste caso, o resultado da consulta será "<Объект не найден>…...” em vez do valor do campo de referência.

Se você estiver desenvolvendo um relatório ou processando usando consultas de configuração genéricas ou personalizadas, sempre verifique o sinalizador "Permitido" para o relatório funcionar sob qualquer usuário com qualquer conjunto de direitos.

No caso do objeto ler dados do banco de dados, não é possível definir o sinalizador "Permitido". Portanto, é necessário configurar seleções para leitura de objetos, levando em consideração possíveis restrições de direitos de acesso para o usuário. Não há meios de obter apenas dados permitidos na tecnologia de objetos.

É importante que, se a palavra-chave ALLOWED não for especificada em uma consulta, todos os filtros especificados nessa consulta não entrem em conflito com nenhuma das restrições de leitura dos objetos do banco de dados usados ​​na consulta. Além disso, se tabelas virtuais forem usadas na consulta, os filtros correspondentes devem ser impostos nas próprias tabelas virtuais.

Prática 1. Construtor de consultas em configurações RLS.

Vamos compor o texto da seção "WHERE" na consulta ao diretório. Você pode usar o construtor de consultas.
O construtor é truncado.

Aba "Tabelas"

A tabela principal será a tabela do objeto para o qual a restrição está sendo configurada.

Você também pode selecionar outras tabelas e configurar vários relacionamentos entre elas na guia "Relacionamentos".

Aba Condições

Aqui você pode configurar as condições reais para restringir o acesso.

Vamos adicionar condições para o atributo "Preço" do diretório da lista de ações para o direito de "ler" a todos os campos da tabela.

"Nomenclatura WHERE Nomenclatura. Preço > 500"

Vamos ver como essa regra simples funciona. A tabela de referência contém os seguintes elementos:

Depois de definir a restrição de acesso, a tabela mostrará apenas os elementos que atendem à condição:

Grupos também desapareceram. Altere o texto da restrição

"Nomenclatura WHERE Nomenclatura. Preço > 500

OU Nomenclatura. Este é um Grupo"

Bem, agora aqui está o que você precisa.

Se você remover a exibição do campo "código" nas configurações da lista, todos os elementos do diretório serão exibidos, ou seja, a restrição não funcionou. Se você definir a exibição do campo "Código", a restrição funcionará.

Ao mesmo tempo, apesar de o elemento de pesquisa estar visível no campo da lista, seu formulário não pode ser aberto, porque uma restrição no atributo foi definida. O mesmo em uma solicitação arbitrária: ao tentar obter um atributo "restrito", haverá um erro de acesso.

Se você tentar obter as props "restritas" programaticamente, um erro de acesso também será gerado.

Além disso, será impossível acessar quaisquer campos do objeto por meio de um link, pois quando um link é recebido, o sistema lê o objeto inteiro, e se tiver detalhes “limitados”, o objeto não será lido.

Portanto, ao trabalhar com objetos de banco de dados programaticamente, você precisa ter em mente possíveis restrições no nível do registro e obter todos os dados do objeto necessários com uma consulta e, em seguida, colocá-los em uma estrutura ou executar parte do código em um módulo privilegiado.

Após configurar a restrição de acesso, a exibição da linha na lista de direitos mudou - ficou cinza e apareceu um ícone.

Restrições de configuração de acesso (RLS).

• Nenhuma seção Resumo;
• Você não pode acessar tabelas de registros virtuais;
• Você não pode usar parâmetros explicitamente;
• Subconsultas podem usar qualquer>/span> recursos de linguagem de consulta, exceto para:
  • operador EM HIERARQUIA;
  • oferece RESULTADOS;
  • resultados de consultas aninhadas não deve conter partes tabulares>/span>;
  • mesas virtuais, em particular Saldos e Volumes de Negócios

Prática 2. Nomenclatura com o preço atual.

Faça uma restrição de acesso se precisar exibir um item com o preço atual maior que um determinado valor, por exemplo, 100.

Solução:

Adicionamos uma nova regra de restrição de acesso ao livro de referência "Nomenclatura" para o direito de "leitura".
Selecione "outros campos".
No construtor, adicione uma consulta aninhada. Nela, selecione a tabela de cadastro de informações "Preços dos itens".
Não há guia "pedido" - esse é um recurso do construtor de consultas para criar uma consulta de restrição de acesso.
Na guia “Avançado”, defina “primeiro 999999999”, a guia “pedido” apareceu.
Configure a ordenação pelo campo "Período" em ordem decrescente.
Em seguida, configuramos a conexão da tabela principal com a subconsulta por referência.

Modelos de Restrição de Acesso.

Prática 3. Restrição de "contratantes" por valor em uma constante.

Configure a restrição de acesso para o diretório Contrapartes pelo valor armazenado em Constant.

Além disso, você precisa configurar uma restrição para todos os objetos que usam o diretório "Contractors" nos detalhes.

Solução

Para o livro de referência “Contas”, para o direito “ler”, configuraremos uma restrição adicionando uma consulta aninhada à constante da seção “Condições”. Não se esqueça deste grupo.

Vemos o problema, o diretório Contrapartes é filtrado corretamente e todos os documentos com o atributo “Contraparte” são exibidos, alguns com links “quebrados” no atributo “Contraparte”.

Agora você precisa configurar a restrição de acesso para todos os objetos usando o link para "Contas". Vamos encontrá-los com o serviço "pesquisar links para um objeto".

Vamos copiar e modificar ligeiramente o texto da condição RLS do diretório "Contrapartes". Isso deve ser feito quantas vezes houver objetos encontrados.

Ou use o padrão de restrição de acesso para evitar problemas de duplicação de código.

Os modelos de restrição de acesso são configurados no nível da função e podem ser usados ​​para qualquer objeto dentro da função editada.

Você pode colocar qualquer parte do texto de restrição de acesso no modelo. O modelo é chamado através do símbolo "#". Por exemplo, #TemplateContractor.

Através de # em 1C, as instruções são escritas no pré-processador. No contexto da execução das configurações de restrição de acesso, a plataforma substitui o texto de chamada do modelo pelo texto do modelo.

Vamos mover o texto após a palavra WHERE para o modelo "TemplateContractor", exceto o texto sobre ThisGroup.

Parâmetros em modelos de restrição de acesso.

Vamos continuar resolvendo o problema 2.

O problema agora é que a tabela principal do diretório se chama "contraparte", no documento "Fatura". O campo marcado no diretório é denominado "link", no documento - "Contraparte".

Altere o nome da tabela principal no texto do modelo para "#CurrentTable"

"#CurrentTable" é um parâmetro predefinido.

E através do ponto indicamos o número do parâmetro de entrada - “.#Parameter(1)

"#Parameter" também é um valor predefinido. Pode conter um número arbitrário de parâmetros de entrada. Eles são referidos pelo número de série.

No texto da restrição de acesso ao diretório, indicamos o seguinte:

Para o documento o seguinte:

“Venda de Mercadorias ONDE #TemplateContractor(“Contractor”)”

Ao chamar o modelo de restrição de acesso, os parâmetros devem ser passados ​​para ele apenas como uma String, ou seja, entre aspas.

Tabela Principal - Nomenclatura

O texto do modelo é:

#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)

O texto do modelo contém uma parte do texto na linguagem de restrição de acesso a dados e pode conter parâmetros destacados com o símbolo "#".

O caractere "#" pode ser seguido por:

• Uma das palavras-chave:
  • Um parâmetro seguido pelo número do parâmetro no modelo entre parênteses;
  • CurrentTable - significa inserir no texto o nome completo da tabela para a qual a restrição está sendo construída;
  • CurrentTableName– denota a inserção no texto do nome completo da tabela (como um valor de string, entre aspas) à qual a instrução é aplicada, na versão atual da linguagem integrada;
  • NomeAtualPermissão– contém o nome do direito para o qual a restrição atual é executada: READ/READ, ADD/INSERT, MODIFY/UPDATE, DELETE/DELETE;
• nome do parâmetro do modelo – significa inserir a restrição do parâmetro do modelo correspondente no texto;
• o símbolo "#" - indica a inserção de um único símbolo "#" no texto.

Uma expressão de restrição de acesso pode conter:

• O padrão de restrição de acesso, que é especificado no formato #TemplateName("Valor do parâmetro do modelo 1", "Valor do parâmetro do modelo 2",...). Cada parâmetro de modelo é colocado entre aspas duplas. Se precisar especificar um caractere de aspas duplas no texto do parâmetro, use duas aspas duplas.
• Function StrContains(Onde estamos procurando, o que estamos procurando). A função foi projetada para procurar uma ocorrência de WhatLooking for na string WhereLooking for. Retorna True se a correspondência for encontrada, False caso contrário.
• O operador + para concatenação de strings.

Para facilitar a edição do texto do modelo, na guia Modelos de restrição no formulário de função, clique no botão Definir texto do modelo. Na caixa de diálogo que se abre, insira o texto do modelo e clique em OK.

Eles não podem ser instalados usando setParameter() ou algo semelhante.

Neste caso, os parâmetros são:

• Opções de Sessão
• Opções Funcionais

A leitura dos parâmetros da sessão em uma solicitação de restrição de acesso ocorre de forma privilegiada, ou seja, sem controle de direitos para operar com eles.

Prática 4. Acesso às “suas” contrapartes

É necessário configurar a restrição de acesso do usuário atual às "suas" contrapartes.

Existe um diretório "Usuários", um diretório "Contrapartes", documentos com o requisito "Contraparte".

O usuário atual deve ver os dados apenas para as contrapartes para as quais uma conexão foi estabelecida com ele.

A comunicação também precisa ser configurada.

Opções possíveis:

Estabelecimento de vínculos usuário + contraparte

• Detalhes no diretório contrapartes
• Cadastro de informações

Possíveis soluções para o problema:

• Armazenar o usuário em uma constante é uma opção ruim, a constante está disponível para todos os usuários.
• Manter uma matriz fixa das contrapartes do usuário atual nos parâmetros da sessão não é uma boa opção, pode haver muitas contrapartes
• Armazene os parâmetros da sessão do usuário atual e solicite uma lista de "suas" contrapartes - uma opção aceitável.
• Outras opções.

Solução.

Vamos criar um novo parâmetro de sessão "CurrentUser" e escrever seu preenchimento no módulo de sessão.

Vamos criar um cadastro de informações "Correspondência de dirigentes e contrapartes"

Vamos criar uma nova função e nela uma nova restrição de acesso para o documento "Fatura de Recebimento".

No texto da consulta, vamos conectar a tabela principal com o cadastro de informações por Contractor = Contractor e Manager = &CurrentUser. Tipo de conexão Interna.

Se possível, é melhor evitar consultas aninhadas em textos de restrição de acesso, pois ela será executada toda vez que os dados deste objeto forem lidos do banco de dados.

Nós verificamos - as restrições funcionam

* Recurso: Se você alterar a lista de contrapartes do usuário no registro, as restrições de acesso entrarão em vigor imediatamente sem reiniciar a sessão do usuário.

Prática 5. Sem mudança de data.

É necessário implementar a restrição de edição de dados antes da data definida para a proibição de alterações.
Os usuários precisam ser limitados.

Vamos criar um cadastro de informações "ChangeBarDateDate" com a dimensão User, recurso RestrictedDate.

Vamos construir a lógica da solução desta forma:

• se o usuário não for especificado, o banimento se aplica a todos os usuários
• se houver restrição para todos os usuários e restrição para um usuário específico, haverá restrição para um usuário específico e para os demais de acordo com o princípio geral.

Obviamente, tal limite pode ser configurado para objetos de banco de dados que possuem uma determinada posição no eixo do tempo. Pode ser

• Documentação
• Registros de informações periódicas

Vamos criar uma nova função "RestrictionsBy ChangeProhibitionDate".

Nela, para o documento “Recebimento de Nota Fiscal” para o “alterar” correto adicionaremos uma nova restrição de acesso.

A configuração é especificada para todos os campos.

O texto de restrição é:

Recebimento Fatura DO Documento Recebimento Fatura AS Fatura Fatura

ChangeProhibitionDates.ProhibitionDate AS ProhibitionDate
DE

INNER JOIN (SELECIONAR
MAXIMUM(ChangeProhibitionDate.User) AS User
DE
Registro de Informações Datas da Proibição de Mudanças AS Datas da Proibição de Mudanças
ONDE
(ChangeProhibitionDates.User = &CurrentUser
ORChangeProhibitionDate.User = VALUE(Reference.users.NullReference))) AS OT_User
BYChangeProhibitedDate.User = OT_User.User) AS Subconsulta
Fatura Invoice.Date > NestedRequest.BanDate

Verificamos - a restrição funciona.

Usando instruções do pré-processador

#Se Condição1 #Então

Solicitar fragmento 1

#ElseIf Condição2 #Então

Solicitar fragmento 2

#De outra forma

Solicitar fragmento 3

#Fim se

Em condições, você pode usar operações lógicas (e. ou, não, etc.) e acessar os parâmetros da sessão.

Esta abordagem no contexto de restrições de acesso ao edifício é conveniente porque, dependendo das condições, um texto de consulta mais curto será compilado. Uma solicitação mais simples carrega menos o sistema.

A desvantagem é que o construtor de consulta não funcionará com esse texto.

*Peculiaridade:

Ao contrário das instruções para o pré-processador 1C:Enterprise em textos de restrição de acesso, preceda o operador Then com uma cerquilha — #Then

Prática 6. Alternar "Usar RLS"

Vamos complementar nosso sistema de restrição com uma opção que habilita/desabilita o uso da restrição no nível do registro.

Para fazer isso, adicione uma constante e um parâmetro de sessão chamado "UseRLS".

Vamos escrever no Módulo de Sessão definindo o valor do parâmetro de sessão a partir do valor da constante.

Adicione o seguinte código a todos os textos de restrição de acesso:

"#Se &UsarRLS #Então….. #EndIf"

Nós verificamos - tudo funciona.

Porém, agora após ativar a bandeira “usar radar”, as alterações não terão efeito imediato. Por que?

Porque o parâmetro da sessão é definido quando a sessão é iniciada.

É possível redefinir o parâmetro da sessão quando um novo valor constante é gravado, mas isso só funcionará para a sessão atual do usuário. Outros usuários precisam ser solicitados a reiniciar o sistema.

Fim da primeira parte.

   

17 regras para compilar um REQUEST ideal para dados de banco de dados 1C

Para formar e executar consultas a tabelas de banco de dados na plataforma 1C, um objeto especial de linguagem de programação é usado. Solicitar. Este objeto é criado chamando a construção Novo pedido. É conveniente usar uma consulta quando você precisa obter uma seleção complexa de dados, agrupados e classificados conforme necessário. Um exemplo clássico de uso de uma consulta é obter um resumo do estado de um registro de acumulação em um ponto específico no tempo. Além disso, o mecanismo de consulta facilita a obtenção de informações em várias seções de tempo.

O texto do pedido é a instrução segundo a qual o pedido deve ser executado. O corpo da solicitação descreve:

• tabelas de infobase usadas como fontes de dados de consulta;
• campos da tabela que precisam ser processados ​​na consulta;
• regras de agrupamento;
• triagem de resultados;
• etc.

A instrução é compilada em uma linguagem especial - a linguagem de consulta e consiste em partes separadas - seções, frases, palavras-chave, funções, operadores aritméticos e lógicos, comentários, constantes e parâmetros.

A linguagem de consulta da plataforma 1C é muito semelhante à sintaxe de outras linguagens SQL, mas há diferenças. As principais vantagens da linguagem de consulta integrada são: desreferenciação de campos, tabelas virtuais, trabalho conveniente com totais, campos não digitados em consultas.

Recomendações para escrever consultas de banco de dados na linguagem de consulta da plataforma 1C:

1) O corpo da solicitação pode conter dados de configuração predefinidos, como:

• valores de enumeração;
• dados predefinidos:
• diretórios;
• planos de tipos de características;
• planos de contas;
• planos para tipos de cálculos;
• links vazios;
• valores de waypoints de processos de negócio.

Além disso, o texto da solicitação pode conter valores de enumeração do sistema que podem ser atribuídos aos campos nas tabelas do banco de dados: AccumulationMotionType, AccountType e AccountingMovementType. As solicitações referem-se a dados de configuração predefinidos e valores de enumeração do sistema usando um literal do tipo de função VALUE. Esse literal melhora a legibilidade da consulta e reduz o número de parâmetros de consulta.

Um exemplo de uso de um literal SIGNIFICADO:

• WHERE Cidade = VALUE(Diretório.Cidades.Moscou)
• WHERE Cidade = VALUE(Referência.Cidades.ReferênciaVazia)
• WHEREItemType = VALUE(Enumeration.ProductTypes.Service)
• WHEREMovementType = VALUE(MovementTypeAccumulation.Income)
• WHERE RoutePoint = VALUE(BusinessProcess.BusinessProcess1.RoutePoint.Action1

2) Usando instruções ORDEM AUTOMÁTICA em uma consulta, o tempo de execução da consulta pode ser muito alto; portanto, se a classificação não for necessária, é melhor não usá-la. Na maioria dos casos, a melhor maneira de aplicar a classificação é com a instrução ORDENAR POR.

A organização automática funciona de acordo com os seguintes princípios:

• Se a cláusula ORDER BY foi especificada na consulta, cada referência à tabela nesta cláusula será substituída pelos campos pelos quais a tabela é classificada por padrão (para diretórios, este é o código ou nome, para documentos, a data do documento). Se o campo de ordenação se referir a um diretório hierárquico, será aplicada a classificação hierárquica por esse diretório.
• Se não houver cláusula ORDER BY na consulta, mas houver cláusula TOTALS, então o resultado da consulta será ordenado pelos campos presentes na cláusula RESULTS após a palavra-chave BY, na mesma sequência e, se os totais forem calculados por os campos - links, depois pelos campos de ordenação por padrão das tabelas que foram referenciadas.
• Se não houver cláusulas ORDER BY e TOTAL na consulta, mas houver uma cláusula GROUP BY, então o resultado da consulta será ordenado pelos campos presentes na frase na mesma sequência e, se o agrupamento foi feito por campos - links e, em seguida, por padrão, classificando as tabelas de campos que foram referenciadas.
• Se a consulta não contiver as cláusulas e ORDER BY, TOTAL e GROUP BY, o resultado será ordenado pelos campos de classificação padrão das tabelas nas quais os dados são selecionados, na ordem em que aparecem na consulta.
• Se a consulta contiver a cláusula TOTAL, cada nível de totais será ordenado separadamente.

3) Para evitar novas consultas ao banco de dados ao exibir o resultado da consulta ao usuário (por exemplo, criar uma consulta ou exibir o resultado da consulta usando um documento de planilha), é útil usar a instrução APRESENTAÇÃOLINKS A que permite obter uma representação de um valor de referência. Exemplo:

Também é possível usar a instrução DESEMPENHO- projetado para obter uma representação de string de um valor de um tipo arbitrário. A diferença entre essas instruções é que no primeiro caso, se as instruções passarem por uma referência, o resultado será uma string, nos demais casos, o resultado será o valor do parâmetro passado. No segundo caso, o resultado da instrução será sempre uma string!

4) Se a consulta contiver um campo com um tipo composto, para esses campos será necessário converter os valores do campo para um tipo específico usando a instrução EXPRESSAR, o que permitirá remover tabelas desnecessárias da conexão esquerda com um campo de tipo de dados composto e acelerar a consulta. Exemplo:

Existe um registo de acumulação de Restos de Bens, em que o campo Registador é do tipo composto. No pedido são seleccionados a Data e Número dos documentos de Entrada de Mercadorias, enquanto que aceder ao detalhe do documento através do campo Registador não resulta em muitas esquerdas ligações da tabela de registo de acumulação com as tabelas de documentos de registo.

Código 1C v 8.x SELECIONAR
EXPRESS(Restos de Mercadorias.Registrar AS Documento.Recibo de Mercadorias).Número AS Número do Recebimento,
EXPRESS(Restos de Mercadorias.Registrar AS Documento.Recibo de Mercadorias).Data AS Data de Recebimento
DE
Registro de Acumulação. Restos de Bens COMO Restos de Bens

Se a conversão for considerada inviável, o resultado da conversão será o valor NULO.

5) Não se esqueça das instruções PERMITIDO, o que significa que a consulta selecionará apenas os registros para os quais o usuário atual tem permissões. Se esta palavra não for especificada, caso a consulta selecione registros para os quais o usuário não possui direitos, a consulta funcionará com um erro.

6) Se a consulta usa uma união, e em algumas partes da união existem tabelas aninhadas (um documento com uma parte tabular), e em algumas não há necessidade de complementar a lista de seleção com campos - tabelas aninhadas vazias. Isso é feito usando a palavra-chave EMPTYTABLE, após o qual os aliases dos campos que compõem a tabela aninhada são indicados entre colchetes. Exemplo:

Código 1C v 8.x // Seleciona os campos Número e Composição
// da tabela virtual Document.Invoice
ESCOLHA Referência.Número, TABELA VAZIA.(Nom, Tov, Qtd) COMO COMPOSIÇÃO
DE Documento.Fatura
UNIR TODOS
SELECT Link.Number, Composição.(LineNumber, Product, Quantity)
FROM Documento.Fatura Documento.Fatura.Composição.*

7) Para evitar linhas duplicadas no resultado da consulta, deve-se utilizar a instrução VÁRIOS, porque é cada vez mais claro, e a instrução GRUPO POR usado para agrupar usando funções de agregação. A propósito, ao usar funções agregadas, a frase GRUPO POR pode não ser especificado, enquanto todos os resultados da consulta serão agrupados em uma única linha. Exemplo:

Código 1C v 8.x // É necessário saber quais as contrapartes
// as mercadorias foram embarcadas no período.
Selecione Vários
Documento.Fatura.Empreiteiro

8) Instrução GRUPO POR permite acessar campos de nível superior, sem agrupar resultados por esses campos, se funções agregadas forem aplicadas aos campos de uma tabela aninhada. Embora esteja escrito na ajuda 1C, ao agrupar os resultados da consulta, as funções agregadas devem ser indicadas na lista de campos de seleção e, além das funções agregadas, apenas os campos pelos quais o agrupamento é realizado podem ser indicados na lista de seleção Campos. Exemplo:

Código 1C v 8.x SELECIONAR
Recebimento de Mercadorias e Serviços. Mercadorias. (SOMA (Quantidade), Nomenclatura),
Recebimento de Mercadorias e Serviços. Link,
Recebimento de Bens e Serviços. Contraparte
DE
Documento. Recebimento de Bens e Serviços AS Recebimento de Bens e Serviços
GRUPO POR
Recebimento de Mercadorias e Serviços. Mercadorias. (Nomenclatura)

9) Instrução É NULO destinado a substituir o valor NULO para outro valor, mas não se esqueça que o segundo parâmetro será convertido para o tipo do primeiro se o tipo do primeiro parâmetro for uma string ou um número.

10) Ao se referir à tabela principal, você pode se referir aos dados da tabela subordinada na condição. Esse recurso é chamado de desreferenciar os campos de uma subtabela.

Exemplo (pesquisa de documentos que contenham determinado produto na seção tabular):

A vantagem dessa consulta sobre a consulta na subtabela Incoming.Goods é que, se houver duplicatas em documentos, o resultado da consulta retornará apenas documentos exclusivos sem usar a palavra-chave DISTINCT.

11) Uma variante interessante do operador B é a verificação da ocorrência de um conjunto ordenado no conjunto de tais conjuntos (Campo1, Campo2, ... , CampoN) B (Campo1, Campo2, ... , CampoN).

Código 1C v 8.x SELECIONAR
Empreiteiros.Link
ONDE
(Contractors.Link, Goods.Link)
(SELECIONE Vendas.Cliente, Vendas.Produto
DO Registro de Acumulação. Vendas AS Vendas)
DE
Diretório. Contrapartes,
Diretório.Produtos

12) Use tabelas de consulta virtuais sempre que possível. Ao criar uma consulta, o sistema fornece uma série de tabelas virtuais como fontes de dados - são tabelas que também são resultado de uma consulta que o sistema gera no momento da execução da seção de código correspondente.

O desenvolvedor pode obter de forma independente os mesmos dados que o sistema lhe fornece como tabelas virtuais, porém, o algoritmo para obtenção desses dados não será otimizado, pois:

Todas as tabelas virtuais são parametrizadas, ou seja, o desenvolvedor tem a oportunidade de definir alguns parâmetros que o sistema usará ao gerar uma solicitação para criar uma tabela virtual. Dependendo de quais parâmetros da mesa virtual são especificados pelo desenvolvedor, o sistema pode gerar VÁRIOS consultas para obter a mesma tabela virtual, e serão otimizadas em função dos parâmetros passados.

Nem sempre é possível para um desenvolvedor obter acesso aos dados aos quais o sistema tem acesso.

13) No modo de operação cliente-servidor, a função SUBSTRING() implementado usando a função SUBSTRING() da instrução SQL correspondente passada para o servidor de banco de dados SQL Server, que calcula o tipo de resultado da função SUBSTRING() de acordo com regras complexas dependendo do tipo e valores de seus parâmetros, bem como dependendo do contexto em que é usado. Na maioria dos casos, essas regras não afetam a execução de uma consulta, mas há casos em que o comprimento máximo da string de resultado calculado pelo SQL Server é essencial para a execução da consulta. É importante ter em mente que em alguns contextos ao usar a função SUBSTRING(), o comprimento máximo de seu resultado pode ser igual ao comprimento máximo de uma string de comprimento limitado, que é de 4000 caracteres no SQL Server. Isso pode levar a uma falha inesperada na execução da consulta:

Microsoft OLE DB Provider para SQL Server: Aviso: o processador de consulta não pôde produzir um plano de consulta do otimizador porque o comprimento total de todas as colunas na cláusula GROUP BY ou ORDER BY excede 8.000 bytes.

HRESULT=80040E14, SQLSTATE=42000, nativo=8618

14) Use com cuidado OU em construção ONDE, já que usar uma condição com OR pode "pesar" significativamente a consulta. O problema pode ser resolvido por design UNIR TODOS. Exemplo:

Código 1C v 8.x SELECIONAR

DE

ONDE
_DemoContractors.Link =Link1
UNIR TODOS
ESCOLHER
_Demo Counterparties.NameFull
DE
Directory._DemoContractors COMO _DemoContractors
ONDE
_DemoContractors.Link =Link2

15) Condição NÃO EM em construção ONDE aumenta o tempo de execução da requisição, pois é uma espécie de NÃO (OR1 OR2 ... ORn), portanto, para tabelas grandes, tente usar LEFT JOIN com condição IS NULL. Exemplo:

Código 1C v 8.x SELECIONAR
_DemoContractors.Link
DE
Directory._DemoContractors COMO _DemoContractors
LEFT JOIN Document._DemoBuyerOrder AS _DemoBuyerOrder
Software _DemoContractors.Link = _BuyerDemoOrder.Contractor
ONDE
_Buyer's DemoOrder.Counterparty IS NULL

16) Ao usar Tabelas temporárias você precisa indexar a condição e juntar campos nessas tabelas, MAS, ao usar índices, a consulta pode ser executada ainda mais lentamente. Portanto, é necessário analisar cada consulta com e sem índice, medir a velocidade de execução da consulta e tomar uma decisão final.

Se você colocar dados em uma tabela temporária inicialmente indexada em alguns campos, não haverá mais um índice nesses campos na tabela temporária.

17) Se você não usa Gerenciador de tabelas temporárias, então não há necessidade de excluir explicitamente a tabela temporária, ela será excluída após a conclusão da execução da consulta em lote, caso contrário, a tabela temporária deverá ser excluída de uma das seguintes maneiras: por comando DESTRUIR na requisição chame o método TemporaryTable Manager.Close().

E além do vídeo de Evgeny Gilev: Erros típicos ao escrever solicitações para 1C: