Administrar la seguridad de los datos mediante la sección de acceso

La sección de acceso se utiliza para controlar la seguridad de una aplicación. Es básicamente una parte del script de carga de datos donde se agrega una tabla de autorización para definir quién puede ver qué. Qlik Cloud utiliza esta información para reducir los datos al ámbito adecuado cuando el usuario abre la aplicación, es decir, algunos de los datos de la app se ocultan al usuario en función de su identidad. La sección de acceso está estrechamente integrada con los datos de la app y se basa en ellos para controlar el acceso. Esta forma de reducción dinámica de los datos puede apuntar a filas, columnas o a una combinación de ambas. Para más información, vea Confianza y seguridad en Qlik.

Secciones en el script de carga

El control de acceso a los datos se gestiona a través de una o más tablas de seguridad, cargadas de la misma forma en que se cargan normalmente los datos. Esto hace posible almacenar esas tablas en una base de datos estándar o en una hoja de cálculo. Las sentencias de script que gestionan las tablas de seguridad se proporcionan dentro de una sección de autorización, que en el script se inicia mediante la sentencia Section Access.

Todos los nombres de campo y valores de campo enumerados en la sección de acceso siempre se ponen en mayúsculas. Como resultado, todos los campos que formen parte de una reducción de datos deben convertirse a mayúsculas para que coincidan con lo que se indica en la sentencia de la sección de acceso, incluso si están ubicados fuera de la sentencia de la sección de acceso. Puede convertir cualquier nombre de campo de la base de datos que contenga letras minúsculas a mayúsculas utilizando la función Upper antes de que la sentencia LOAD o SELECT lea el campo.

Para más información, vea Upper - función de script y de gráfico.

Si se define una sección de autorización en el script, la parte del script que carga los datos de la app debe colocarse en una sección diferente, iniciada por la sentencia Section Application.

Ejemplo:

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;

Tenga en cuenta que después de realizar cambios en el script de carga, siempre debe volver a cargar los datos para que los cambios surtan efecto.

Campos de sistema de la sección de acceso

Los niveles de acceso se asignan a los usuarios en una o más tablas de autorización cargadas dentro de la parte Section Access del script. Estas tablas deben contener, como mínimo, dos campos de sistema: ACCESS, que es el campo que define el nivel de acceso, y USERID o USER.EMAIL. Se pueden agregar otros campos de sistema opcionales, según sea el caso de uso. A continuación se describen todos los campos de sistema de la sección de acceso.

ACCESS

Define el tipo de acceso que debe tener un usuario específico.

El acceso a las apps de Qlik Sense puede autorizarse a determinados usuarios específicos. En la tabla de autorización, se puede asignar a los usuarios a los niveles de acceso ADMIN o USER. Un usuario con privilegios ADMIN tiene acceso a todos los datos de la app, a menos que esté limitado por la tabla de autorización. Un usuario con privilegios de usuario (USER), solo puede acceder a los datos definidos en la tabla de autorización. Si no se asigna un nivel de acceso válido, el usuario no podrá abrir la app.

USERID

Contiene una cadena que corresponde a un nombre de usuario de Qlik Cloud. Qlik Cloud obtendrá la información de inicio de sesión del sujeto firmante IdP y la comparará con el valor de este campo. Para conocer una forma alternativa de verificar la identidad del usuario mediante la dirección de correo electrónico, consulte USER.EMAIL. Para entornos con múltiples nubes, el sujeto firmante IdP se puede asignar a su identidad interna de Windows. Cuando se usa Qlik Account, el sujeto firmante no se puede asignar a la identidad interna de Windows. El usuario firmante de IdP se puede ver en la sección Usuarios del centro de actividades Administración.

Un carácter comodín de asterisco (*) se interpreta como todos los usuarios, sujeto a condiciones adicionales especificadas en la tabla de autorización. Por ejemplo, en la siguiente tabla de autorización, los usuarios que están incluidos en Qlik Sense Tenant Admins pueden ver todos los valores de REDUCCIÓN enumerados.

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

USERID y NTNAME usan ambos la misma información de autenticación, por lo que no es necesario marcar ambos en la misma fila en la tabla de autorización. La diferencia entre los dos campos es que NTNAME también verifica grupos.

NTNAME

NTNAME es un campo de QlikView heredado y se recomienda utilizar USERID si QlikView no está usando la misma tabla de autorización.

Un campo que debe contener una cadena correspondiente a la versión NetBIOS de un nombre de usuario o grupo de dominio de Windows NT. Si se utilizara un sistema de autenticación diferente, deberá contener el nombre de un usuario autenticado.

Qlik Cloud obtendrá la información de inicio de sesión de la reclamación de subject del proveedor de identidad y la comparará con el valor de este campo.

USER.EMAIL

Contiene una cadena que corresponde a la dirección de correo electrónico de un usuario. Qlik Cloud obtendrá esta información del proveedor de identidad y la comparará con el valor de este campo.

GROUP

Contiene una cadena que corresponde a un grupo de Qlik Cloud. Qlik Cloud obtendrá la información de inicio de sesión de la reclamación “groups” del proveedor de identidad y la comparará con el valor de este campo.

Esta funcionalidad no está disponible en Qlik Sense Business, Analítica Estándar de Qlik Cloud o cuando se usa el proveedor de identidad (IdP) Qlik.

OMIT

Contiene el nombre del campo que se debe omitir para este usuario específico. Se puede hacer uso de comodines y el campo puede dejarse vacío.

Le recomendamos que no aplique OMIT en campos clave. Los campos clave que se omiten están visibles en el visor del modelo de datos, pero el contenido no está disponible, lo que podría ser confuso para el usuario. Además, aplicar OMIT en campos que se utilizan en una visualización puede dar como resultado una visualización incompleta para usuarios que no tengan acceso a los campos omitidos.

Gestionar el acceso de usuarios a una app

Un usuario con USERID AD_DOMAIN\C no podría abrir la app en absoluto porque ese ID de usuario no aparece en la tabla de autorización.

La sección de acceso, en su forma más simple, sirve para restringir el acceso de determinados usuarios a una app. A los usuarios se les niega el acceso a una app mediante un proceso de exclusión. En otras palabras, si una dirección de correo electrónico de usuario no aparece en la tabla de autorización, dicho usuario no podrá acceder a la aplicación. La única excepción a esta regla es si se asigna un asterisco (*) al campo USER EMAIL en una de las filas de la tabla de autorización. El asterisco, en este caso, significa que todos los usuarios autenticados pueden acceder a la app. A continuación se muestra un ejemplo de una tabla de autorización con un listado de los ID de usuario:

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

Un usuario con USER.EMAIL USER4@example.com no podría abrir la app en absoluto, porque esa dirección de correo electrónico de usuario no aparece en la tabla de autorización.

Gestionar el acceso de usuarios a datos específicos de una app

La reducción dinámica de datos limita el acceso a filas y columnas en las tablas de datos dentro de las apps de Qlik Sense después de que un usuario haya sido autorizado para acceder a la app.

Gestionar el acceso a los datos a nivel de fila

Restrinja el acceso a los datos a nivel de fila agregando una columna de reducción de datos a la tabla de autorización en la sección de acceso del script de carga. Determinados registros (filas) pueden ocultarse enlazando los datos de la sección de acceso con los datos reales: La selección de datos que se mostrarán o excluirán se controla mediante uno o más campos de reducción con nombres comunes en las partes Section Access y Section Application de la secuencia de script. Una vez que el usuario haya iniciado sesión, Qlik Sense tratará de contrastar las selecciones de campos de la sección de acceso con los campos de la sección de aplicación que tengan exactamente los mismos nombres de campo (los nombres de los campos deben estar en mayúsculas). Una vez realizadas las selecciones, Qlik Sense oculta permanentemente al usuario todos los datos excluidos por estas selecciones. Si se utiliza un carácter comodín (*) como valor de campo en la columna de reducción de datos, se interpreta como que permite al usuario acceder a los registros asociados con todos los campos de reducción seleccionados en la tabla de seguridad.

Cuando Qlik Sense está comparando el campo de reducción en la sección de acceso con los campos del modelo de datos, se esperan los siguientes comportamientos:

Si un valor de campo en el modelo de datos coincide con el campo de reducción en la sección de acceso, la aplicación se abrirá y mostrará los datos asociados con la coincidencia para el usuario especificado. Otros datos se ocultarán.
Si el valor del campo de reducción no coincide con ninguno de los valores del modelo de datos, la aplicación no se abrirá para un USUARIO normal; pero sí se abrirá sin reducción para un usuario marcado como ADMIN.

No se recomienda utilizar varios campos reductores en la sección de acceso, ya que permitirá otras combinaciones de acceso distintas a las previstas.

El carácter comodín * en la columna de reducción de datos se refiere solo a todos los valores de la tabla de autorización. Si hubiera valores en la sección Section Application que no están disponibles en la columna de reducción de la tabla de seguridad, estos se reducirán.

Todos los nombres de campo empleados en la transferencia descrita anteriormente y todos los valores de campo de estos campos deberán ir en mayúsculas, ya que todos los nombres de campo y los valores de campo se convierten por defecto en mayúsculas en la sección de acceso.

Ejemplo: Reducción de datos a nivel de filas basada en la identidad de usuario

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;

En este ejemplo, el campo REDUCTION (mayúsculas) existe ahora tanto en la sección de acceso como en la sección de aplicación (todos los valores de campos van también en mayúsculas). Por lo general, serían dos campos totalmente diferentes y aparte; pero al utilizar sección de acceso, estos campos se vinculan y se reduce el número de registros que se muestran al usuario.

El resultado será:

El usuario USER1@EXAMPLE.COM puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver cuando REDUCTION = 1 o REDUCTION =2.
El usuario USER2@EXAMPLE.COM puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=1.
El usuario USER3@EXAMPLE.COM puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=2.
El usuario USER4@EXAMPLE.COM puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver cuando REDUCTION = 1 o REDUCTION =2.

Gestionar el acceso a los datos a nivel de columna

Restrinja el acceso a los datos a nivel de columna agregando el campo de sistema OMIT a la tabla de autorización en el script de sección de acceso. El ejemplo siguiente se basa en el ejemplo anterior, en el que la reducción de datos de filas ya está implementada.

Ejemplo: Reducción de datos de columna basada en la identidad del usuario

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;

El campo OMIT, en la sección de acceso define los campos que deberían ocultarse del usuario.

El resultado será:

El usuario USER1@example.com puede ver todos los campos y solo aquellos registros que otros usuarios pueden ver en este ejemplo cuando REDUCTION sea 1, 2 o 3.
El usuario USER2@example.com puede ver todos los campos, pero solo aquellos registros asociados a REDUCTION=1.
El usuario USER3@example.com puede ver todos los campos excepto NUM y solo aquellos registros asociados a REDUCTION=2.
El usuario USER4@example.com puede ver todos los campos excepto ALPHA y solo aquellos registros asociados a REDUCTION=3.

Algunas visualizaciones tienen requisitos mínimos de datos que deben cumplirse para poder reproducirse. Como resultado, es posible que se muestre "Visualización incompleta" cuando se omita un campo de nivel de columna en la vista de datos de un usuario.

Gestionar el acceso a grupos de usuarios

La sección de acceso le ofrece la opción de limitar el alcance de los datos visibles para los usuarios mediante la pertenencia a un grupo. Para restringir sus datos utilizando grupos de usuarios, agregue el nombre del campo GROUP a la tabla de autorización en la sección de acceso y defina valores para el campo GROUP.

Ejemplo: Reducción de datos basada en grupos de usuarios

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;

El resultado será:

Los usuarios que pertenecen al grupo ADMIN tienen permiso para ver todos los campos y solo aquellos registros que otros usuarios pueden ver en este ejemplo cuando REDUCTION sea 1, 2 o 3.
Los usuarios que pertenecen al grupo A pueden ver los datos asociados a REDUCTION=1 en todos los campos.
Los usuarios que pertenecen al grupo B pueden ver los datos asociados a REDUCTION=2, pero no en el campo NUM
Los usuarios que pertenecen al grupo C pueden ver los datos asociados a REDUCTION=3, pero no en el campo ALPHA
Los usuarios que pertenecen al grupo GROUP1 pueden ver los datos asociados a REDUCTION=3 en todos los campos
El usuario AD_DOMAIN\DEV puede ver todos los datos de todos los campos.

Qlik Cloud compara el usuario con UserID y resolverá el usuario comparándolo con los grupos de la tabla. Si el usuario pertenece a un grupo al que se le permite el acceso, o el usuario coincide, puede acceder a la app.

Recargar datos en Qlik Cloud

Para recargar una app sin reducción de datos en Qlik Cloud, se recomienda utilizar el campo de sistema USER.EMAIL en la tabla de autorización. El valor del campo USER.EMAIL debe ser la dirección de correo electrónico de los usuarios que pueden editar y cargar la app. Esto se aplica a apps tanto en espacios compartidos como administrados. Por ejemplo:

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

En este ejemplo, el usuario con la dirección de correo electrónico test@example.com es ADMIN y puede recargar la app.

Si está utilizando grupos, el siguiente ejemplo funcionaría igualmente para ambos Qlik Sense y Qlik Cloud:

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

También puede asignar el USERID en la tabla de autorización al subject claim del proveedor de identidad, como se muestra en el siguiente ejemplo. Esta configuración se sugiere para migrar de Qlik Sense a Qlik Cloud y hacia entornos multicloud. Para más información sobre cómo asignar USERID a subject claim, consulte Gestionar el acceso de los usuarios en un entorno con varias nubes

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

Gestionar el acceso de los usuarios en un entorno con varias nubes

Un entorno multicloud de Qlik Sense implica una combinación de mecanismos de autenticación de usuarios. Normalmente con Qlik Sense Enterprise on Windows, el USERID en la tabla de autorización Section Access es verificado por el servicio del proxy. En Qlik Cloud, un proveedor de identidad asume ese rol de autenticación. En consecuencia, la sección de acceso que está configurada para un entorno local como Qlik Sense Enterprise on Windows no funcionará en un entorno en la nube.

Cuando se usa un proveedor de identidad OIDC o SAML (Qlik IdP o IdP personalizado) con Qlik Cloud, se usa subject claim para identificar a los usuarios al iniciar sesión. Con la sección de acceso, el valor del campo USERID en la tabla de autorización se compara con el valor de subject claim. Cuando configure su espacio empresarial inquilino, asegúrese de que el nombre de cuenta SAM esté asignado al subject claim de su proveedor de identidad. De modo que, por ejemplo, si su nombre de cuenta SAM es AD_DOMAIN\Dev, establezca el subject claim como AD_DOMAIN\Dev. Si desea ver el valor del subject claim o la IdP, adjunte /api/v1/diagnose-claims a la URL del espacio empresarial inquilino en el navegador, por ejemplo, su-espacioempresarial.es.qlikcloud.com/api/v1/diagnose-claims. En la respuesta JSON , el subject claim se denomina sub.

Si no puede utilizar el nombre de la cuenta SAM, existe una forma alternativa de autenticar a un usuario. Dado que las direcciones de correo electrónico tienden a permanecer igual en diferentes entornos, puede usar el campo USER.EMAIL en lugar de USERID en la tabla de autorización. Aquí tiene un ejemplo del aspecto que podría tener la tabla de autorización:

ACCESS	USERID	USER.EMAIL	Comentario	COUNTRY
USUARIO	ABC\JOE	*	Acceso local	Estados Unidos
USUARIO	*	JOE.SMITH@EXAMPLE.COM	Acceso en la nube	Estados Unidos
USUARIO	ABC\URSULA	*	Acceso local	Alemania
USUARIO	*	URSULA.SCHULTZ@EXAMPLE.COM	Acceso en la nube	Alemania
USUARIO	ABC\STEFAN	*	Acceso local	Suecia
USUARIO	*	STEFAN.SVENSSON@EXAMPLE.COM	Acceso en la nube	Suecia

Script de autorización:

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 ];

Tenga en cuenta que cada usuario tiene dos registros: uno para acceso local y otro para acceso a la nube. Los caracteres comodín garantizan que solo se utilicen los campos de autenticación relevantes. En este ejemplo, COUNTRY se utiliza como campo de reducción de datos.

Campos de autorización de QlikView

Para compatibilidad con versiones anteriores, Qlik Cloud reconoce los campos de autorización de QlikView. Aunque USERID se interpreta de modo diferente en QlikView y Qlik Cloud, en Qlik Cloud se interpretará de la misma manera que en Qlik Sense: se comparará con el nombre del usuario autenticado.

PASSWORD, NTSID y NTDOMAINSID

Si se utiliza uno de los campos PASSWORD, NTSID y NTDOMAINSID, y este contiene un valor relevante, se deniega el acceso al documento. Si el campo contiene un comodín (*), se puede otorgar acceso, dependiendo de los demás campos en la tabla de autorización.

SERIAL

Si se utiliza el campo SERIAL y contiene un número de licencia, la fila de la sección de acceso denegará el acceso al documento. Si el campo contiene un comodín (*), se puede otorgar acceso, dependiendo de los demás campos en la tabla de autorización.

Además, en Qlik Cloud este campo también se puede utilizar para definir el entorno. Esto significa que si el campo contiene la cadena "QLIKCLOUD’", se podría otorgar acceso dependiendo de los otros campos en la tabla de autorización.

Entornos mixtos

Si planea usar la misma tabla de autorización en ambos, QlikView y Qlik Cloud, tenga en cuenta que:

• USERID tiene diferentes significados en QlikView y Qlik Cloud, y podría, si se utiliza, ocasionar problemas de seguridad. Use NTNAME en su lugar o combínelo con SERIAL tal como se describe a continuación.

• GROUP y los campos que comienzan por "USER.", como por ejemplo "USER.NAME" y "USER.EMAIL", son (o serán) campos de autorización en Qlik Cloud. Si usa estos campos en su sección de acceso, es posible que se le deniegue el acceso a Qlik Cloud.

• PASSWORD, NTSID y NTDOMAINSID no se pueden usar en Qlik Cloud. Se denegará el acceso, a menos que se utilice un comodín.

• SERIAL no se puede utilizar para comprobar el número de licencia en Qlik Cloud. Sin embargo, si este campo contiene la cadena "QLIKCLOUD", es posible que se otorgue acceso. Esto significa que es posible tener una tabla de autorización como la siguiente, donde la línea 1 otorgará acceso a QlikView (pero no a Qlik Cloud), y la línea 2 otorgará acceso a Qlik Cloud (pero no a QlikView).

Tabla de autorización
Línea	SERIAL	USERID	Comentario
1	4600 0123 4567 8901	*	Otorga acceso al número de licencia correcto en QlikView.
2	QLIKCLOUD	JOHN DOE	Otorga acceso al usuario correcto en Qlik Cloud.

Script de autorización:

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

Usar sección de acceso e Insight Advisor Chat

Las apps que utilizan sección de acceso en el script utilizan un usuario de indexación para determinar cuánta información deberá recuperar Insight Advisor Chat de la app. El usuario de indexación deberá ser el usuario con el nivel más alto de acceso a la app en el script con sección de acceso. No obstante, los datos proporcionados a los usuarios finales seguirán estando controlados por las limitaciones de acceso a secciones que imponga la sección de acceso.

Para una demostración visual de cómo utilizar la sección de acceso y Insight Advisor Chat, consulte:

Usar sección de acceso e Insight Advisor Chat

Si tiene información confidencial en los nombres de las apps, los nombres de los campos o los nombres de los elementos maestros, estos podrían quedar expuestos al hacer que las apps que utilizan sección de acceso estén disponibles para Insight Advisor Chat. Las sugerencias de apps en cuanto a consultas incluyen apps en espacios a los que los usuarios tienen acceso. Estos pueden incluir aplicaciones a las que los usuarios no tienen acceso en la sección de acceso de una app. Sin embargo, seleccionar estas apps no hará nada. Al hacer clic en Dimensiones o Medidas para ver los elementos disponibles desde una app que utiliza sección de acceso, los usuarios pueden ver elementos a los que no tienen acceso. Sin embargo, hacer clic en estos elementos no proporcionará ningún dato a los usuarios.

De manera predeterminada, el propietario de la app es el usuario de indexación. Puede cambiar el usuario de indexación en Detalles.

Haga lo siguiente:

En Qlik Cloud, navegue hasta la app.
Haga clic en en la app y seleccione Detalles.
Enr Usuario de indexación, seleccione el usuario de indexación.
Haga clic en Atrás.
Haga clic en en la app y seleccione Recargar.

Usar QVD con sección de acceso

Los archivos QVD se pueden leer como una carga normal o como una carga optimizada. Una carga optimizada es cuando no se realizan transformaciones de datos durante la carga y no hay filtros en una cláusula WHERE.

Las cargas optimizadas no funcionan cuando se utilizan archivos QVD con sección de acceso. Si desea utilizar un archivo QVD para cargar datos en la sección de acceso, debe expandir el archivo QVD. La forma más sencilla de expandir el archivo QVD es realizar un cambio de formato al cargar los datos.

En el ejemplo siguiente, el archivo QVD no se expande, ya que no se aplica formato a los datos.

Ejemplo: Ejemplo que no funciona y sin formato de datos (carga optimizada)

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

En su lugar, puede, por ejemplo, utilizar la función upper() para dar formato a los datos que expandirán el archivo QVD.

Ejemplo: Ejemplo que funciona y con formato de datos

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

También puede agregar una sentencia Where 1=1 a la sentencia LOAD.

Ejemplo: Otro ejemplo que funciona y con formato de datos

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

Directrices y consejos para utilizar sección de acceso

A continuación ofrecemos algunos datos importantes y sugerencias útiles que debe conocer sobre la sección de acceso.

Todos los nombres de campo y valores de campo enumerados en la sección de acceso siempre se convierten a mayúsculas. Como resultado, todos los campos que formen parte de una reducción de datos deben convertirse a mayúsculas para que coincidan con lo que se indica en la sentencia de la sección de acceso, incluso si están ubicados fuera de la sentencia de la sección de acceso. Puede convertir cualquier nombre de campo de la base de datos que contenga letras minúsculas a mayúsculas utilizando la función Upper antes de que la sentencia LOAD o SELECT lea el campo.
Para más información, vea Upper - función de script y de gráfico.
No puede utilizar los nombres de campo de la sección de acceso mostrados como nombres de campo en su modelo de datos.
Las apps deben publicarse antes de que se apliquen los controles de la sección de acceso. La recarga de la aplicación no aplica ningún script de sección de acceso nuevo o modificado.
Una captura de imagen muestra los datos conforme a los derechos de acceso que posea el usuario que toma la captura y esta captura puede después compartirse en una historia. No obstante, cuando los usuarios retornan a una visualización desde una historia para ver los datos en vivo en la app, se ven restringidos por sus propios derechos de acceso.
No asigne colores a los valores de las dimensiones maestras si utiliza sección de acceso o trabaja con datos confidenciales, porque los valores podrían quedar expuestos por la configuración del color.
Para evitar exponer información restringida, elimine todos los archivos adjuntos con la configuración de sección de acceso antes de publicar la app. Los archivos adjuntos se incluyen al publicar la app. Si la app publicada se copia, los archivos adjuntos se incluyen en la copia. Sin embargo, si se han aplicado restricciones de sección de acceso a los archivos de datos adjuntos, la configuración de la sección de acceso no se conserva al copiarse los archivos, por lo que los usuarios de la app copiada podrán ver todos los datos en los archivos adjuntos.
Un carácter comodín (*), se interpreta como todos los valores (incluidos en la lista) de este campo, es decir, un valor que aparece en otros lugares de la tabla. Si se usa en uno de los campos de sistema (USERID, GROUP) de una tabla cargada en la sección de acceso del script, se interpretará como todos los valores posibles (también los no enumerados) de este campo.
Los campos de seguridad se pueden colocar en diferentes tablas.
Al cargar datos de un archivo QVD, la función Upper ralentiza la velocidad de carga.

¿Esta página le ha sido útil?

No dude en indicarnos en qué podemos mejorar si encuentra algún problema en esta página o su contenido, como, por ejemplo, errores tipográficos, pasos que falta o errores técnicos.

Deje aquí sus comentarios