robwhitehouse
Hola comunidad
Me preguntaba si alguien ha encontrado un problema al usar la función DATEDIFF contra una base de datos SQL en el modo DirectQuery al intentar crear una columna calculada. O si estoy haciendo algo simplemente mal.
He estado usando DATEDIFF muy bien en el modo de importación contra hojas de cálculo de Excel y los datos están en el mismo formato. Ahora estoy trabajando para convertir un informe plano de Excel en una conexión SQL en vivo, pero recibo un buen error que indica:
The following exception occurred while the managed IDbCommand interface was being used: 'DATEDIFF_BIG' is not a recognized built-in function name.
Me preguntaba si alguien había visto esto antes y si era un comportamiento esperado en DirectQuery. Por lo general, la aplicación de escritorio es bastante inteligente para advertir sobre cosas que no funcionarán, pero esta no fue una de ellas. También intenté desactivar «permitir medidas sin restricciones», pero tampoco funcionó.
Salud,
Robar
Eric_Zhang
@robwhitehouse
Según tengo entendido, se trata de un error potencial o de un diseño intencional (tal vez solo se considere la compatibilidad con los productos Azure SQL, ya que son calientes y en la nube).
En el modo DirectQuery que se conecta a una fuente de SQL Server, la columna calculada en DAX se «traduce» a Transact-SQL (T-SQL, lenguaje de programación y consulta de SQL Server). El motor de base de datos ejecuta el T-SQL traducido y devuelve el resultado de la consulta idealmente.
En este caso, DATEDIFF en DAX probablemente se traduzca a DATEDIFF_BIG en T-SQL, sin embargo, DATEDIFF_BIG se introdujo en SQL Server 2016 local, Azure SQL Database y Azure SQL Data Warehouse. Entonces, ¿apuesto a una versión más baja de SQL Server local en su escenario? Creo que es por eso que ves la última parte del error «‘DATEDIFF_BIG’ no es un nombre de función integrado reconocido».
Con respecto a la parte anterior «La siguiente excepción …», esa es una excepción típica del lenguaje .NET (C # en PowerBI, supongo) cuando ocurre una interacción problemática entre C # y la base de datos.
Informaré esto internamente y nuestros ingenieros lo evaluarán.
Eric_Zhang
@robwhitehouse
Según tengo entendido, se trata de un error potencial o de un diseño intencional (tal vez solo se considere la compatibilidad con los productos Azure SQL, ya que son calientes y en la nube).
En el modo DirectQuery que se conecta a una fuente de SQL Server, la columna calculada en DAX se «traduce» a Transact-SQL (T-SQL, lenguaje de programación y consulta de SQL Server). El motor de base de datos ejecuta el T-SQL traducido y devuelve el resultado de la consulta idealmente.
En este caso, DATEDIFF en DAX probablemente se traduzca a DATEDIFF_BIG en T-SQL, sin embargo, DATEDIFF_BIG se introdujo en SQL Server 2016 local, Azure SQL Database y Azure SQL Data Warehouse. Entonces, ¿apuesto a una versión más baja de SQL Server local en su escenario? Creo que es por eso que ves la última parte del error «‘DATEDIFF_BIG’ no es un nombre de función integrado reconocido».
Con respecto a la parte anterior «La siguiente excepción …», esa es una excepción típica del lenguaje .NET (C # en PowerBI, supongo) cuando ocurre una interacción problemática entre C # y la base de datos.
Informaré esto internamente y nuestros ingenieros lo evaluarán.
garrek99
En respuesta a Eric_Zhang
Hola Eric
¿Alguna actualización sobre este tema?
TY
robwhitehouse
En respuesta a Eric_Zhang
Oye Eric,
Gracias por la respuesta. Eché un vistazo a los documentos en MSDN y vi que se introdujo en SQL 2016, así que estoy bastante seguro de que ese es el problema, mi fuente de datos es un servidor SQL local más antiguo.
Lo solucionaré por ahora; Sería genial si esto también pudiera funcionar con fuentes de datos más antiguas.
Salud,
Robar
