Gerenciando a segurança dos dados com o Section Access

O Section Access é usado para controlar a segurança de um aplicativo. Basicamente, ele é uma parte do script de carregamento de dados em que você adiciona uma tabela de segurança para definir quem consegue ver o quê. O Qlik Cloud usa essas informações para reduzir os dados ao escopo apropriado quando o usuário abre o aplicativo, ou seja, alguns dados no aplicativo são ocultados do usuário com base em sua identidade. O Section Access está estreitamente integrado aos dados no aplicativo e depende dele para controlar o acesso. Essa forma de redução dinâmica de dados pode estar voltada para linhas de tabela, colunas de tabela ou uma combinação de ambas. Para mais informações, consulte Confiança e segurança na Qlik.

Seções no script de carregamento

O controle de acesso a dados é gerenciado por meio de uma ou mais tabelas de segurança carregadas da mesma maneira que os dados normalmente são carregados. Isso possibilita armazenar essas tabelas em um banco de dados padrão ou em uma planilha. As instruções de script que gerenciam as tabelas de segurança são fornecidas em uma seção de autorização, que no script é iniciada pela instrução Section Access.

Todos os nomes e valores de campos listados no Acesso à Seção são sempre convertidos em letras maiúsculas. Como resultado, todos os campos que fazem parte de uma redução de dados devem ser convertidos para letras maiúsculas para corresponder ao que está indicado no comando de Acesso à Seção, mesmo que estejam localizados fora do comando de Acesso à Função. Você pode converter todos os nomes de campo que contêm letras minúsculas no banco de dados para maiúsculas usando a função Upper antes de ler o campo pelo comando LOAD ou SELECT.

Para obter mais informações, consulte Upper – função de script e gráfico.

Se uma seção de autorização for definida no script, a parte do script que carrega os dados do aplicativo deverá ser colocada em uma seção diferente, iniciada pela instrução Section Application.

Exemplo:

Section Access; Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ];Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@EXAMPLE.COM, * USER, USER2@EXAMPLE.COM, 1 USER, USER3@EXAMPLE.COM, 2 ADMIN, USER4@EXAMPLE.COM, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Observe que, depois de fazer alterações no script de carregamento, você sempre deve carregar os dados para que as alterações tenham efeito.

Campos do sistema do Section Access

Os níveis de acesso são atribuídos a usuários em uma ou mais tabelas de segurança carregadas na parte Section Access do script. Essas tabelas devem conter pelo menos dois campos do sistema: ACCESS, que é o campo que define o nível de acesso, e USERID ou USER.EMAIL. Outros campos opcionais do sistema podem ser adicionados dependendo do caso de uso. O conjunto completo de campos do sistema do section access está descrito abaixo.

ACCESS

Define o tipo de acesso que o usuário correspondente deve ter.

O acesso a aplicativos do Qlik Sense pode ser autorizado para usuários especificados. Na tabela de segurança, é possível atribuir os níveis de acesso ADMIN ou USER aos usuários. Um usuário com privilégios ADMIN tem acesso a todos os dados no aplicativo, a menos que limitado pela tabela de segurança. Um usuário com privilégios USER só pode acessar dados conforme definido na tabela de segurança. Se nenhum nível de acesso for atribuído, o usuário não poderá abrir o aplicativo.

USERID

Contém um caractere correspondente a um nome de usuário Qlik Cloud. O Qlik Cloud obterá as informações de logon do sujeito IdP e as comparará com o valor nesse campo. Para conhecer uma maneira alternativa de verificar a identidade do usuário usando o endereço de e-mail, consulte USER.EMAIL. Para ambientes com várias nuvens, o sujeito IdP pode ser mapeado em relação à sua identidade interna do Windows. Ao usar o Qlik Account, o requerente não pode ser mapeado em relação à identidade interna do Windows. O sujeito IdP do usuário pode ser visualizado na seção Usuários e grupos do centro de atividades de Administração.

Um caractere curinga (*) é interpretado como todos os usuários, sujeito a outras condições especificadas na tabela de segurança. Por exemplo, na tabela de segurança a seguir, os usuários que estão em Qlik Sense Tenant Admins podem ver todos os valores REDUCTION listados.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik SENSE TENANT ADMINS, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];

O USERID e o NTNAME usam as mesmas informações de autenticação e, portanto, não é necessário verificar ambos na mesma linha na tabela de segurança. A diferença entre os dois campos é que NTNAME também verifica grupos.

NTNAME

NTNAME é um campo herdado do QlikView, e é recomendado usar USERID se o QlikView não estiver usando a mesma tabela de segurança.

Um campo que deve conter uma sequência de caracteres correspondente à versão NetBIOS de um nome de usuário ou grupo de domínio do Windows NT. Se um sistema de autenticação diferente for usado, ele deverá conter o nome de um usuário autenticado.

O Qlik Cloud buscará as informações de logon da declaração subject do provedor de identidade e as comparará com o valor nesse campo.

USER.EMAIL

Contém uma sequência de caracteres correspondente a um endereço de e-mail de usuário. O Qlik Cloud obterá essas informações do provedor de identidade e as comparará com o valor nesse campo.

GROUP

Contém um caractere correspondente a um grupo no Qlik Cloud. O Qlik Cloud obterá as informações da declaração “groups” do provedor de identidade e as comparará com o valor nesse campo.

Essa funcionalidade não está disponível no Qlik Sense Business Qlik Cloud Analytics Standard ou ao usar o Qlik Identity Provider (IdP).

OMIT

Contém o nome do campo que deve ser omitido para esse usuário específico. Os caracteres curinga podem ser usados e o campo pode ficar vazio.

É recomendado que você não aplique OMIT em campos de chave. Os campos chave que são omitidos estão visíveis no visualizador do modelo de dados, mas o conteúdo não está disponível, o que pode ser confuso para o usuário. Além disso, a aplicação de OMIT em campos que são usados em uma visualização pode resultar em uma visualização incompleta para usuários que não têm acesso aos campos omitidos.

Gerenciando o acesso do usuário a um aplicativo

Um usuário com USERID AD_DOMAIN\C não seria capaz de abrir o aplicativo porque esse ID de usuário não está listado na tabela de segurança.

O Section Access, em sua forma mais simples, pode ser usado para impedir que usuários específicos acessem um aplicativo. Os usuários têm acesso negado a um aplicativo por meio de exclusão. Em outras palavras, se o endereço de e-mail de um usuário específico não estiver listado na tabela de segurança, ele não poderá acessar o aplicativo. A única exceção a essa regra é se um curinga (*) for atribuído ao campo USER.EMAIL em uma das linhas da tabela de segurança. Um curinga, nesse caso, significa que todos os usuários autenticados podem acessar o aplicativo. Aqui está um exemplo de uma tabela de segurança com uma lista de IDs de usuário:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL ADMIN, USER1@EXAMPLE.COM USER, USER2@EXAMPLE.COM USER, USER3@EXAMPLE.COM ]; Section Application;

Um usuário com USER.EMAIL USER4@example.com não seria capaz de abrir o aplicativo, pois o endereço de e-mail do usuário não está listado na tabela de segurança.

Gerenciando o acesso dos usuários a dados específicos em um aplicativo

A redução dinâmica de dados limita o acesso a linhas e colunas nas tabelas de dados de um aplicativo do Qlik Sense depois que um usuário recebeu autorização para acessar esse aplicativo.

Gerenciando o acesso a dados em nível de linha

Restrinja o acesso a dados em nível de linha adicionando uma coluna de redução de dados à tabela de segurança na seção de acesso do script de carregamento. Registros (linhas) específicos podem ser ocultos dos usuários por meio da vinculação dos dados do Section Access aos dados reais. A seleção dos dados a serem exibidos ou excluídos é controlada pela presença de um ou mais campos de redução com nomes comuns nas partes Section Access e Section Application do script. Após o login do usuário, o Qlik Sense corresponde às seleções em campos de redução no Section Access a quaisquer campos no Application Section com exatamente os mesmos nomes de campo (que devem ser escritos em maiúsculas). Feitas as seleções, o Qlik Sense oculta permanentemente do usuário todos os dados excluídos por essas seleções. Se um curinga (*) for usado como um valor de campo na coluna de redução de dados, ele será interpretado como permitindo que o usuário acesse os registros associados a todos os campos de redução selecionados na tabela de segurança.

Quando o Qlik Sense está comparando o campo de redução no Section Access aos campos no modelo de dados, os seguintes comportamentos são esperados:

Se um valor de campo no modelo de dados corresponder ao campo de redução no Section Access, o aplicativo será aberto mostrando os dados associados à correspondência para o usuário especificado. Outros dados serão ocultados.
Se o valor do campo de redução não corresponder a nenhum dos valores no modelo de dados, o aplicativo não será aberto para um USUÁRIO normal. No entanto, abrirá sem redução para um usuário marcado como ADMIN.

O uso de vários campos redutores no Section Access não é recomendado, pois permitirá outras combinações de acesso além das pretendidas.

O curinga * na coluna de redução de dados refere-se apenas a todos os valores na tabela de segurança. Se houver valores no Section Application que não estão disponíveis na coluna de redução da tabela de segurança, eles serão reduzidos.

Todos os nomes de campos usados na transferência descrita anteriormente e todos os valores nesses campos devem estar em letras maiúsculas, pois todos os nomes e valores de campo são, por padrão, convertidos em maiúsculas no Section Access.

Exemplo: Redução de dados em nível de linha com base na identidade do usuário

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@EXAMPLE.COM, * USER, USER2@EXAMPLE.COM, 1 USER, USER3@EXAMPLE.COM, 2 USER, USER4@EXAMPLE.COM, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

Neste exemplo, o campo REDUCTION (em maiúsculas) existe no Section Access e no Section Application (todos os valores de campo também estão em maiúsculas). Normalmente, os dois campos seriam totalmente diferentes e separados. Porém, ao usar o Section Access, esses campos são vinculados, e o número de registros exibidos ao usuário é reduzido.

O resultado será:

O usuário USER1@EXAMPLE.COM poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar quando REDUCTION = 1 ou REDUCTION =2.
O usuário USER2@EXAMPLE.COM poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
O usuário USER3@EXAMPLE.COM poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=2.
O usuário USER4@EXAMPLE.COM poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar quando REDUCTION = 1 ou REDUCTION =2.

Gerenciando o acesso a dados em nível de coluna

Restrinja o acesso a dados em nível de coluna adicionando o campo do sistema OMIT à tabela de segurança no script do Section Access. O exemplo a seguir baseia-se no exemplo anterior, em que a redução de dados de linha já está em vigor.

Exemplo: Redução de dados de coluna com base na identidade do usuário

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

O campo OMIT no Section Access define os campos que devem ser ocultos do usuário.

O resultado será:

O usuário USER1@example.com poderá visualizar todos os campos e apenas os registros que outros usuários podem visualizar neste exemplo quando REDUCTION for 1, 2 ou 3.
O usuário USER2@example.com poderá visualizar todos os campos, mas apenas os registros associados a REDUCTION=1.
O usuário USER3@example.com poderá visualizar todos os campos, exceto NUM, e apenas os registros associados a REDUCTION=2.
O usuário USER4@example.com poderá visualizar todos os campos, exceto ALPHA, e apenas os registros associados a REDUCTION=3.

Algumas visualizações têm requisitos mínimos de dados que devem ser atendidos para que possam ser renderizadas. Como resultado, a indicação "Visualização incompleta" pode ser exibida quando um campo em nível de coluna é omitido da visualização de dados de um usuário.

Gerenciando o acesso a grupos de usuários

O Section Access oferece a opção de limitar o escopo dos dados visíveis aos usuários por meio da associação a grupos. Para restringir seus dados usando grupos de usuários, adicione o nome do campo GROUP à tabela de segurança no Section Access e defina valores para o campo GROUP .

Exemplo: Redução de dados com base em grupos de usuários

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, AD_DOMAIN\DEV, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

O resultado será:

Os usuários pertencentes ao grupo ADMIN têm permissão para ver todos os campos e apenas os registros que outros usuários podem ver neste exemplo quando REDUCTION é 1, 2 ou 3.
Os usuários pertencentes ao grupo A podem ver dados associados a REDUCTION=1 em todos os campos.
Os usuários pertencentes ao grupo B podem visualizar dados associados a REDUCTION=2, mas não no campo NUM
Os usuários pertencentes ao grupo C podem visualizar dados associados a REDUCTION=3, mas não no campo ALPHA
Os usuários pertencentes ao grupo GROUP1 podem ver dados associados a REDUCTION=3 em todos os campos
O usuário AD_DOMAIN\DEV tem permissão para visualizar todos os dados em todos os campos.

O Qlik Cloud compara o usuário com UserID e resolve o usuário em relação aos grupos na tabela. Se o usuário pertencer a um grupo com acesso permitido ou se o usuário corresponder, ele poderá acessar o aplicativo.

Carregando dados no Qlik Cloud

Para carregar um aplicativo sem redução de dados no Qlik Cloud, é recomendável usar o campo do sistema USER.EMAIL na tabela de segurança. O valor do campo USER.EMAIL deve ser o endereço de e-mail de usuários que são capazes de editar e carregar o aplicativo. Isso é válido para aplicativos em espaços compartilhados e gerenciados. Por exemplo:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, TEST@EXAMPLE.COM, * ];

Neste exemplo, o usuário com endereço de e-mail test@example.com é ADMIN e é capaz de carregar o aplicativo.

Se você estiver usando grupos, o exemplo a seguir funcionará igualmente para Qlik Sense e Qlik Cloud:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, DEVELOPERS, * ];

Você também pode mapear o USERID na tabela de segurança para o subject claim do Provedor de Identidade, conforme mostrado no exemplo a seguir. Essa configuração é sugerida para migrar do Qlik Sense para o Qlik Cloud e para ambientes de várias nuvens. Para obter mais informações sobre como mapear o USERID para o subject claim, consulte Gerenciando o acesso do usuário em um ambiente de várias nuvens

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

Gerenciando o acesso do usuário em um ambiente de várias nuvens

Um ambiente de várias nuvens do Qlik Sense envolve uma combinação de mecanismos de autenticação de usuário. Normalmente, com o Qlik Sense Enterprise on Windows, o USERID na tabela de segurança do Section Access é verificado pelo serviço de proxy. No Qlik Cloud, um provedor de identidade assume essa função de autenticação. Consequentemente, o Section Access configurado para um ambiente local, como o Qlik Sense Enterprise on Windows, não funcionará em um ambiente de nuvem.

Ao usar um provedor de identidade OIDC ou SAML (Qlik IdP ou IdP personalizado) com o Qlik Cloud, o subject claim é usado para identificar usuários ao efetuar login. Com o Section Access, o valor do campo USERID na tabela de segurança é comparado ao valor do subject claim. Ao configurar seu locatário, certifique-se de que o nome da conta SAM esteja mapeado para o subject claim do seu provedor de identidade. Assim, por exemplo, se o nome da sua conta SAM for AD_DOMAIN\\Dev, defina o subject claim como AD_DOMAIN\\Dev. Se quiser ver o valor da subject claim do IdP, anexe /api/v1/diagnose-claims à URL do locatário no navegador, por exemplo, your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. Na resposta JSON, o subject claim é chamado sub.

Se você não consegue usar o nome da conta SAM, há uma maneira alternativa de autenticar um usuário. Como os endereços de e-mail tendem a permanecer os mesmos em ambientes diferentes, você pode usar o campo USER.EMAIL em vez de USERID na tabela de segurança. Aqui está um exemplo de tabela de segurança:

ACCESS	USERID	USER.EMAIL	Comentário	COUNTRY
Usuário	ABC\JOE	*	Access-on-prem	Estados Unidos
Usuário	*	JOE.SMITH@EXAMPLE.COM	Access-in-cloud	Estados Unidos
Usuário	ABC\URSULA	*	Access-on-prem	Alemanha
Usuário	*	URSULA.SCHULTZ@EXAMPLE.COM	Access-in-cloud	Alemanha
Usuário	ABC\STEFAN	*	Access-on-prem	Suécia
Usuário	*	STEFAN.SVENSSON@EXAMPLE.COM	Access-in-cloud	Suécia

Script de autorização:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\JOE, *, UNITED STATES USER, *, JOE.SMITH@EXAMPLE.COM, UNITED STATES USER, ABC\URSULA, *, GERMANY USER, *, URSULA.SCHULTZ@EXAMPLE.COM, GERMANY USER, ABC\STEFAN, *, SWEDEN USER, *, STEFAN.SVENSSON@EXAMPLE.COM, SWEDEN ];

Observe que cada usuário tem dois registros: um para acesso no local e outro para acesso na nuvem. Os curingas garantem que somente os campos de autenticação relevantes sejam usados. Nesse exemplo, COUNTRY é usado como um campo de redução de dados.

Campos de autorização do QlikView

Para compatibilidade com versões anteriores, o Qlik Cloud reconhece os campos de autorização do QlikView. Apesar de USERID ser interpretado de maneira diferente no QlikView e no Qlik Cloud, no Qlik Cloud, ele será interpretado da mesma forma que no Qlik Sense: ele será comparado com o nome do usuário autenticado.

PASSWORD, NTSID e NTDOMAINSID

Se um dos campos PASSWORD, NTSID e NTDOMAINSID for usado e contiver um valor relevante, o acesso ao documento será negado. Se o campo contiver um curinga (*), o acesso poderá ser concedido dependendo dos outros campos na tabela de autorização.

SERIAL

Se o campo SERIAL for usado e contiver um número de licença, a linha Section Access negará o acesso ao documento. Se o campo contiver um curinga (*), o acesso poderá ser concedido dependendo dos outros campos na tabela de autorização.

Além disso, no Qlik Cloud, esse campo também pode ser usado para definir o ambiente. Isso significa que se o campo contiver a sequência de caracteres ‘QLIKCLOUD’, o acesso poderá ser concedido, dependendo dos outros campos da tabela de autorização.

Ambientes mistos

Se você planeja usar a mesma tabela de segurança no QlikView e no Qlik Cloud, lembre-se do seguinte:

• USERID tem diferentes significados no QlikView e no Qlik Cloud e, se usado, pode causar problemas de segurança. Use NTNAME em vez disso ou combine-o com SERIAL, conforme descrito abaixo.

• GROUP e campos que começam com ‘USER.’, como 'USER.NAME' e 'USER.EMAIL', são (ou serão) campos autorizadores no Qlik Cloud. Se você usar esses campos no Section Access, o acesso poderá ser negado no Qlik Cloud.

• O PASSWORD, NTSID e o NTDOMAINSID não podem ser usados no Qlik Cloud. O acesso será negado, a menos que um caractere curinga seja usado.

• O SERIAL não pode ser usado para verificar o número da licença no Qlik Cloud. No entanto, se esse campo contiver a sequência de caracteres ‘QLIKCLOUD’, o acesso poderá ser concedido. Isso significa que é possível ter uma tabela de segurança como a seguinte, em que a linha 1 concederá acesso no QlikView (mas não no Qlik Cloud), enquanto a linha 2 concederá acesso no Qlik Cloud (mas não no QlikView).

Tabela de segurança
Linha	SERIAL	ID do usuário	Comentário
1	4600 0123 4567 8901	*	Concede acesso ao número de licença correto no QlikView.
2	QLIKCLOUD	JOHN DOE	Concede acesso ao usuário correto no Qlik Cloud.

Script de autorização:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, JOHN DOE, QLIKCLOUD ];

Usando o Section Access e o Insight Advisor Chat

Os aplicativos que usam o Section Access usam um usuário de índice para determinar a quantidade de informações que o Insight Advisor Chat recupera do aplicativo. O usuário de índice deve ser o usuário com o nível mais alto de acesso ao aplicativo no script do Section Access. Porém, os dados fornecidos aos usuários finais ainda são controlados pelas limitações do Section Access.

Para uma demonstração visual de como usar o Section Access e o Insight Advisor Chat, consulte:

Usando o Section Access e o Insight Advisor Chat

Se você tiver informações confidenciais em nomes de aplicativos, nomes de campos ou nomes de itens mestres, estas poderão ficar expostas ao disponibilizar aplicativos que usam o Section Access para o Insight Advisor Chat. As sugestões de aplicativos para consultas incluem aplicativos em espaços aos quais os usuários têm acesso. Isso pode incluir aplicativos aos quais os usuários não têm acesso no Section Access de um aplicativo. Porém, a seleção desses aplicativos não terá nenhum efeito. Ao clicar em Dimensões ou Medidas para visualizar os itens disponíveis de um aplicativo usando o Section Access, os usuários podem ver itens aos quais não têm acesso. Porém, se eles clicarem nesses itens, nenhum dado será fornecido.

Por padrão, o proprietário do aplicativo é o usuário do índice. Você pode alterar o usuário de índice em Detalhes.

Faça o seguinte:

No Qlik Cloud, navegue até o aplicativo.
Clique em no aplicativo e selecione Detalhes.
Em Usuário do índice, selecione o usuário do índice.
Clique em Voltar.
Clique em no aplicativo e selecione Carregar.

Usando QVDs com Section Access

Arquivos QVD podem ser lidos como um carregamento regular ou como um carregamento otimizado. Um carregamento otimizado ocorre quando nenhuma transformação de dados é feita durante o carregamento e não há filtros em uma cláusula WHERE.

Carregamentos otimizados não funcionam ao usar QVDs com o Section Access. Se quiser usar um arquivo QVD para carregar dados no Section Access, você deverá expandir o arquivo QVD. A maneira mais fácil de expandir o arquivo QVD é fazer uma alteração na formatação ao carregar os dados.

No exemplo a seguir, o arquivo QVD não é expandido, pois nenhuma formatação é feita para os dados.

Exemplo: Exemplo não funcional sem formatação de dados (carga otimizada)

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd);

Em vez disso, você pode, por exemplo, usar a função upper() para formatar os dados que expandirão o arquivo QVD.

Exemplo: Exemplo de trabalho com formatação de dados

section access; LOAD ACCESS, USERID, PASSWORD, upper([GROUP]) as [GROUP] FROM SAccess.qvd (qvd);

Você também pode adicionar uma instrução Where 1=1 à instrução LOAD.

Exemplo: Outro exemplo de trabalho com formatação de dados

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd) where 1=1;

Diretrizes e dicas para usar o Section Access

Veja a seguir alguns fatos importantes e dicas úteis sobre o Section Access.

Todos os nomes e valores de campos listados no Acesso à Seção são sempre convertidos em letras maiúsculas. Como resultado, todos os campos que fazem parte de uma redução de dados devem ser convertidos para letras maiúsculas para corresponder ao que está indicado no comando de Acesso à Seção, mesmo que estejam localizados fora do comando de Acesso à Função. Você pode converter todos os nomes de campo que contêm letras minúsculas no banco de dados para maiúsculas usando a função Upper antes de ler o campo pelo comando LOAD ou SELECT.
Para obter mais informações, consulte Upper – função de script e gráfico.
Não é possível usar os nomes de campo de sistema do Section Access listados como nomes de campo no seu modelo de dados.
Os aplicativos devem ser publicados antes que os controles do Section Access sejam aplicados. Carregar o aplicativo não aplica nenhum script novo ou alterado de Section Access.
Um snapshot mostra os dados de acordo com os direitos de acesso do usuário que obtém o snapshot, e pode ser compartilhado em uma história. No entanto, quando os usuários retornam para uma visualização de uma história para ver os dados em tempo real no aplicativo, eles são limitados por seus próprios direitos de acesso.
Não atribua cores a valores de dimensão mestre ao usar o section access ou trabalhar com dados confidenciais, pois os valores poderão ficar expostos pela configuração de cores.
Para evitar a exposição de dados restritos, remova todos os arquivos anexados com as configurações de section access antes de publicar o aplicativo. Esses arquivos anexados serão incluídos quando o aplicativo for publicado. Se o aplicativo publicado for copiado, os arquivos anexos serão incluídos na cópia. No entanto, se restrições de acesso à seção tiverem sido aplicadas aos arquivos de dados anexos, as configurações de acesso à seção não serão mantidas quando os arquivos forem copiados, portanto os usuários do aplicativo copiado poderão ver todos os dados nos arquivos anexos.
Um curinga (*) é interpretado como todos os valores (listados) do campo na tabela. Se for utilizado em um dos campos do sistema (USERID, GROUP) em uma tabela carregada na seção de acesso do script, ele será interpretado como todos os valores possíveis desse campo (inclusive os não listados).
Campos de segurança podem ser colocados em tabelas diferentes.
Ao carregar dados de um arquivo QVD, a função Upper diminui a velocidade de carregamento.

Esta página ajudou?

Se você encontrar algum problema com esta página ou seu conteúdo - um erro de digitação, uma etapa ausente ou um erro técnico - informe-nos como podemos melhorar!

Deixe seu feedback aqui