bases de datos de acceso de lectura alojadas en bibliotecas de sharepoint: funciona en el escritorio, falla en el servicio

Un usuario Pregunto ✅

NSRjecross

Me di cuenta de que había necrosado un hilo antiguo con una respuesta anterior cuando sospecho que debería haber creado uno nuevo, ya que sospecho que se trata de un error en alguna parte en lugar de buscar una solución alternativa como el póster anterior. ¿También esto pertenece mejor en el foro de servicio?

Tengo un problema al leer las bases de datos de acceso alojadas en bibliotecas de Sharepoint de los informes publicados en el servicio PBI. (Estamos ejecutando un SKU premium para nuestro servicio powerBI si eso es parte de la ecuación)

Puedo acceder y extraer los datos correctamente del archivo de la base de datos de acceso alojado de Sharepoint desde el escritorio de Powerbi.

Publico el archivo y verifico la configuración… no se seleccionó ninguna puerta de enlace local, las credenciales de autenticación oauth2 están configuradas en el conjunto de datos. Pero si intenta actualizar, obtiene lo que parece ser el antiguo error de falta de MDAC:

Algo salió mal
Hubo un error al procesar los datos en el conjunto de datos.
Vuelva a intentarlo más tarde o póngase en contacto con el soporte. Si se pone en contacto con el soporte, proporcione estos detalles.
Error de fuente de datos: Microsoft Access: el proveedor ‘Microsoft.ACE.OLEDB.12.0’ no está registrado en la máquina local. Es posible que se requiera la versión de 64 bits del proveedor OLEDB de Access Database Engine 2010 Access Database Engine para leer este tipo de archivo. Para descargar el software de cliente, visite el siguiente sitio: https://go.microsoft.com/fwlink/?LinkID=285987.. La interfaz IDbCommand generó la excepción. Tabla: Acceso de lectura.
URI de clúster: WABI-AUSTRALIA-SOUTHEAST-redirect.analysis.windows.net
ID de actividad: 40da91fc-d0d8-4835-a577-6200e6620fd6
ID de solicitud: df900c67-2458-e2ee-aafa-7e549274896e
Hora: 2020-07-08 08:11:19Z»

Cuando tuvimos este mismo error para acceder y leer archivos de Excel de nuestros sistemas de archivos corporativos, solo necesitábamos instalar los componentes del motor de acceso en el host de la puerta de enlace local y resolvió el problema. Excepto que ahora este acceso a archivos no se ejecuta en la puerta de enlace/servidor que controlamos (servicio a sharepoint), por lo que no tenemos un servidor para agregar los componentes de acceso que faltan.

Traté de forzar el servicio para leer a través de la puerta de enlace; sin embargo, no pude forzar una conexión oauth2 a sharepoint en la configuración de la puerta de enlace, por lo que siempre fallaba la autenticación.

Una vez más, el informe funciona bien desde el escritorio de PBI y luego falla cuando se publica.

¿Alguna sugerencia sobre cómo hacer que el informe alojado (conjunto de datos) lea la base de datos?

Gracias

Jennifer

Código M de una base de datos de prueba simplificada e informe (grite si desea los documentos reales, pero son ejemplos triviales):

dejar

Fuente = SharePoint.Files(«https://nsrltd.sharepoint.com/sites/DataManagement», [ApiVersion = 15]),

#»Filas filtradas» = Table.SelectRows(Source, each ([Extension] = «.accdb»)),

#»Gateway_test accdb_https://nsrltd sharepoint com/sites/DataManagement/Shared Documents/» = #»Filas filtradas»{[Name=»Gateway_test.accdb»,#»Folder Path»=»https://nsrltd.sharepoint.com/sites/DataManagement/Shared Documents/»]}[Content],

#»Acceso importado» = Access.Database(#»Gateway_test accdb_https://nsrltd sharepoint com/sites/DataManagement/Shared Documents/»),

_LookInHere = #»Acceso importado»{[Schema=»»,Item=»LookInHere»]}[Data]

en

_MiraAquí

lbendlin

En lugar de Sharepoint.Files, pruebe Sharepoint.Contents

En lugar de API 15, pruebe API 14

ver si hace alguna diferencia.

NSRjecross

En respuesta a lbendlin

Gracias por las sugerencias @lbendlin

Todavía da el mismo error con ambos cambios.

No creo que el error esté en «leer sharepoint», sino cuando hace el
Acceso.Base de datos()

por ejemplo, esta consulta se actualiza correctamente desde el servicio:

dejar
Fuente = SharePoint.Contents(«https://nsrltd.sharepoint.com/sites/DataManagement», [ApiVersion = 14]),
Documentos = Fuente{[Name=»Documents»]}[Content]
en
Documentos

Incluso puedo leer un Excel a través del servicio con:

dejar
Fuente = SharePoint.Contents(«https://nsrltd.sharepoint.com/sites/DataManagement», [ApiVersion = 14]),
Documentos = Fuente{[Name=»Documents»]}[Content],
#»Tables_demo xlsx» = Documentos{[Name=»Tables_demo.xlsx»]}[Content],
#»Excel importado» = Excel.Workbook(#»Tables_demo xlsx»),
RawData_Sheet = #»Excel importado»{[Item=»RawData»,Kind=»Sheet»]}[Data]
en
RawData_Sheet

Pero falla al acceder a las bases de datos (actualizar desde el servicio … funciona bien en el escritorio)

Editar: intenté reducir un poco más la consulta fallida

dejar
Fuente = SharePoint.Contents(«https://nsrltd.sharepoint.com/sites/DataManagement», [ApiVersion = 14]),
Documentos = Fuente{[Name=»Documents»]}[Content],
#»Gateway_test accdb» = Documentos{[Name=»Gateway_test.accdb»]}[Content],
#»Acceso importado» = Access.Database(#»Gateway_test accdb»)
en
#»Acceso importado»

Esto también falla en el servicio pero funciona en el escritorio de PBI. (solo abre la base de datos y enumera las tablas en lugar de intentar leer filas de una tabla).

lbendlin

En respuesta a NSRjecross

Ah, me perdí por completo el punto de que todavía estás usando Access. (¿Por qué sin embargo?)

Recuerde que Access crea un archivo .ldb (semáforo de bloqueo) al abrir la base de datos. Eso no es algo que el servicio pueda hacer en un punto compartido.

NSRjecross

En respuesta a lbendlin

Hola @lbendlin…

Los usuarios reciben datos en formato de acceso (volcado de base de datos complejo desde el sistema remoto).

Nuevamente, Desktop Power BI puede abrir el archivo, por lo que asumiría que Sharepoint autorizado por las credenciales oauth2 debería hacer lo mismo para cualquier conexión (que pueda establecer la conexión a la base de datos). Hemos tenido un problema similar en el pasado con bases de datos de acceso alojadas en un sistema de archivos local. Para aquellos que necesitábamos instalar los componentes del motor de acceso en el servidor donde se ejecutaba la puerta de enlace local. En este caso, no utiliza una puerta de enlace que podamos controlar (nube a nube) y no podemos forzar un acceso a través de nuestra puerta de enlace, ya que las fuentes de la puerta de enlace no admiten la autenticación oauth2 que parece requerir Sharepoint. (Puedo crear una conexión de puerta de enlace local, pero sin oauth2, siempre falla la autenticación en la conexión. Si le digo que ignore la prueba de conexión e intente mapear de todos modos, falla cuando intenta conectarse más tarde).

En el hilo que necrosé accidentalmente, el póster tenía el mismo problema, pero se solucionó exportando a una lista de puntos compartidos (nuestros datos son demasiado grandes/complejos para eso y son utilizados por otros procesos comerciales en ese formato)

Si Access.Database() no es compatible con el contenido de Sharepoint, deberíamos documentarlo (o mejor, arreglarlo). Pasa la referencia de la carpeta a las funciones, por lo que, tal vez un protocolo faltante, o dada nuestra experiencia con la versión hsoted del sistema de archivos, posiblemente pasa la responsabilidad de la conexión al servidor de origen (host de Sharepoint) que no tiene el MDAC/ módulos accessengine disponibles).

¿Nadie más usa este tipo de conexión? Esperaba que solo me faltara un paso o algo (funciona para el escritorio, pero para el servicio también debe agregar el paso xyz).

Nuestro grupo de TI está presionando a todos los equipos para que muevan todos los archivos a las bibliotecas de Sharepoint para un mejor control y seguimiento de versiones, de ahí el requisito.

Gracias por el tiempo y la atención. ¡Y cualquier otra sugerencia que alguien esté dispuesto a compartir!

Jen

lbendlin

En respuesta a NSRjecross

¿Existe alguna posibilidad en su realidad de volcar Access y pasar a una base de datos empresarial como el servidor SQL?

NSRjecross

En respuesta a lbendlin


@lbendlin escribió:

¿Existe alguna posibilidad en su realidad de volcar Access y pasar a una base de datos empresarial como el servidor SQL?


*sonrisa* tenemos muchas instancias de sql (una gran empresa minera) y nos conectamos a ellas de muchas maneras interesantes.

También utilizamos listas y bibliotecas de Sharepoint, Automatic, Azure y varios sistemas de almacenamiento de datos en la nube.

Pero este (y otros) se comparten con nosotros como bases de datos de acceso. Y funciona desde el escritorio de PBI. Y el servicio PBI al sistema de archivos a través de puertas de enlace locales, siempre que el servidor de la puerta de enlace esté configurado con la instalación del motor de acceso. Podría usar SSIS en una instancia de SQL, pero ese es otro proceso para mantener, y cada vez que esto es solo un problema con la forma en que codifiqué el acceso a la base de datos (solo a través de la GUI, sin profundizar en los documentos de M lang aún)

Me sorprende que esto no haya sido un problema anterior: parece haber un gran impulso de Microsoft para usar bibliotecas de Sharepoint para todos los requisitos de alojamiento de archivos.

lbendlin

En respuesta a NSRjecross

@NSRjecross «el servidor de puerta de enlace» me hizo reír. Para la continuidad del negocio, siempre empleo clústeres de puerta de enlace con miembros distribuidos geográficamente (no solo un grupo de máquinas virtuales en el mismo host físico). Pero esto viene con sus propios problemas, como en tu caso. No solo necesita el motor de acceso en todos los miembros del clúster, sino que también debe ser la versión de 64 bits. Se puede tener diversión sin fin configurando eso, no del todo diferente a los gatos de pastoreo.

NSRjecross

En respuesta a lbendlin

Aunque en este caso, si pudiera forzar la conexión a través de una de nuestras puertas de enlace locales, entonces podría asegurarme de que las bibliotecas estuvieran instaladas. Me pregunto cuál es más fácil de arreglar: oauth2 para la puerta de enlace o Access.database() para sharepoint [contents]

Sin embargo, no he intentado ejecutarlo fuera de la capacidad premium. Lo intentaré el lunes.

¿Cualquier otra sugerencia? ¿Alguien tiene este arreglo realmente funcionando?

Jen

Arrear gatos es fácil con un abrelatas. No estoy seguro de qué alimentar a O365 (aparentemente, el efectivo y las almas no son suficientes)

NSRjecross

En respuesta a NSRjecross

Actualización: a partir de esta mañana, parece que se agregó la autenticación OAuth2 a la puerta de enlace local para los conectores de Sharepoint. (Pero debe actualizar el software de la puerta de enlace antes de poder definir una conexión usándolo).

Esto al menos nos permitirá enrutar la consulta más allá de algún lugar donde hayamos instalado los módulos necesarios.

También descubrí que puede examinar la cadena de conexión utilizada para consultar la base de datos de acceso a través de la interfaz xmla (provider=microsoft.powerbi.olddb en caso de que alguien esté interesado)

Acercándome creo

Jennifer

chaz2jerry

En respuesta a NSRjecross

@NSRjecross Estoy saltando a este hilo desde el anterior donde tú y yo comentamos.

FYI mi solución actual no está usando Sharepoint. Tengo que poner el archivo AccessDB en Network Drive y usar la puerta de enlace para conectarle el flujo de datos.

Cuando intenté poner AccessDB en Sharepoint y conectarme usando el flujo de datos, se agotó el tiempo de espera. Cuando intenté usar el conjunto de datos del servicio PBI para actualizar (después de conectar AccessDB en Sharepoint desde el escritorio y publicarlo), fallé con el mismo error que usted señaló (OAuth2 y necesita actualización de la puerta de enlace). Actualizaré la puerta de enlace y veré qué sucede.

NSRjecross

En respuesta a chaz2jerry

Nuestro equipo de TI actualizó la puerta de enlace; sin embargo, ahora aparece un error:

No puede conectarse: Encontramos un error al intentar conectarnos a . Detalles: «Actualice su puerta de enlace de datos local (o clúster de puerta de enlace) para admitir esta función».

Aunque tenemos el último software de puerta de enlace de las descargas de MS. (3000.45.7)

El error se activa tan pronto como configuro la autenticación Oauth2 e intento ingresar las credenciales.

Error completo:

No se puede conectar: ​​encontramos un error al intentar conectarnos a . Detalles: «Actualice su puerta de enlace de datos local (o clúster de puerta de enlace) para admitir esta función».Ocultar detalles

ID de actividad: 40da91fc-d0d8-4835-a577-6200e6620fd6
Solicitar identificación: 8d118612-be86-457a-cec4-26f4db543de6
URI de clúster: https://wabi-australia-sureste-redirect.analysis.windows.net/
Código de estado: 400
Código de error: DMTS_PowerBIDataMovementGatewayNotSupportedError
Hora: lun 13 de julio de 2020 16:15:00 GMT+0800 (hora estándar occidental de Australia)
Versión de servicio: 13.0.13860.51
Versión del cliente: 2007.1.01830-tren

Por lo tanto, obligar al servicio a enviar la solicitud a través de nuestros servidores no será una opción.

Volver a «¿por qué no funciona el servicio cuando funciona el escritorio»? (Nos preocuparemos de que la opción de enrutar las solicitudes de Sharepoint a través de las instalaciones falle más adelante. De todos modos, actualizar las fuentes en la nube a través de las instalaciones es algo extraño).

chaz2jerry

En respuesta a NSRjecross

@NSRjecross Sí, me encuentro con el mismo error. Supongo que el mensaje de error «actualizar puerta de enlace» es un mensaje genérico general y no está diseñado para este escenario específico. En este momento, mi única opción de trabajo es usar Network Drive en lugar de Sharepoint.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *