QST
Hola a todos,
Tengo un problema con la importación de datos.
Tengo un archivo de base de datos SQLite que tiene una tabla. Esa tabla se compone de tipos INTEGER y DOUBLE. Mi problema es que estoy almacenando Unix Epoch como INTEGER NOT NULL con 13 caracteres (por ejemplo, Valor en esa columna: 1511240400207, que es GMT: martes, 21 de noviembre de 2017, 5:00:00.207 a. m. (@ epochconverter.com) pero en PowerBI, esa columna específica es 2147483647 con 10 caracteres.
He instalado ambos controladores de 32/64 bits de SQLite ODBC @ http://www.ch-werner.de/sqliteodbc/
Todas las demás columnas son correctas.
¿Alguien podría indicarme la dirección correcta?
Gracias
Saludos cordiales
QST
QST
En respuesta a v-yulgu-msft
En primer lugar, gracias por su amable y oportuna respuesta.
Así que estaba tratando de entender y juguetear un poco.
1. Dado que PowerBI importa un número extraño a priori.
La idea era cambiar la forma en que importa. Así que me metí en SQLite Studio tratando de convertir la época de Unix.
Llegado a :
SELECT datetime(Unixepochmillies/1000,'unixepoch') from table1;
y
SELECT datetime(Unixepochmillies/1000,'unixepoch','localtime') from table1;
Parece que tal vez no tengo la opción de incluir los milisegundos en esta consulta, dejándome con los segundos.
El resultado fue que obtuve los mismos valores para la primera consulta sin hora local. Dándome 23.00.00 correcto sin la compensación de zona horaria. Cambiar a Fecha/Hora me dio exactamente los mismos valores y convertir esta consulta a Fecha/Hora/Zona horaria me dio 23.00.00 +7.
Aquí parece que PowerBI solo agrega cuál es mi zona horaria (que de hecho es UTC + 7). Pero uno supondría que calcularía la nueva hora en mi zona horaria, incluidas las +7 horas (6 am del día siguiente).
En la segunda consulta, encontré una discrepancia entre ejecutar el comando en SQLite Studio y PowerBI: en SQLite Studio la salida fue a las 18 h del día anterior y en PowerBi se importó sin procesar a las 6 a.m. asumiendo la diferencia a priori que hace que esta consulta sea correcta ahora. SQLite Studio aquí muestra un cálculo bastante diferente desde las 23 h UTC hasta las 18 h anteriores son 5 horas y no 7 horas.
Además de perder los milisegundos en esta consulta, supongo que ahora está funcionando.
Gracias de nuevo @v-yulgu-msft por apuntar en la dirección correcta.
QST
v-yulgu-msft
Hola @QST,
Compruebe si la zona horaria de SQLite y el escritorio de Power BI coinciden. En el Editor de consultas, cambie una columna de tipo de fecha a «Fecha/Hora/Zona horaria» para ver la zona horaria relativa.
Saludos,
Yuliana Gu
QST
En respuesta a v-yulgu-msft
En primer lugar, gracias por su amable y oportuna respuesta.
Así que estaba tratando de entender y juguetear un poco.
1. Dado que PowerBI importa un número extraño a priori.
La idea era cambiar la forma en que importa. Así que me metí en SQLite Studio tratando de convertir la época de Unix.
Llegado a :
SELECT datetime(Unixepochmillies/1000,'unixepoch') from table1;
y
SELECT datetime(Unixepochmillies/1000,'unixepoch','localtime') from table1;
Parece que tal vez no tengo la opción de incluir los milisegundos en esta consulta, dejándome con los segundos.
El resultado fue que obtuve los mismos valores para la primera consulta sin hora local. Dándome 23.00.00 correcto sin la compensación de zona horaria. Cambiar a Fecha/Hora me dio exactamente los mismos valores y convertir esta consulta a Fecha/Hora/Zona horaria me dio 23.00.00 +7.
Aquí parece que PowerBI solo agrega cuál es mi zona horaria (que de hecho es UTC + 7). Pero uno supondría que calcularía la nueva hora en mi zona horaria, incluidas las +7 horas (6 am del día siguiente).
En la segunda consulta, encontré una discrepancia entre ejecutar el comando en SQLite Studio y PowerBI: en SQLite Studio la salida fue a las 18 h del día anterior y en PowerBi se importó sin procesar a las 6 a.m. asumiendo la diferencia a priori que hace que esta consulta sea correcta ahora. SQLite Studio aquí muestra un cálculo bastante diferente desde las 23 h UTC hasta las 18 h anteriores son 5 horas y no 7 horas.
Además de perder los milisegundos en esta consulta, supongo que ahora está funcionando.
Gracias de nuevo @v-yulgu-msft por apuntar en la dirección correcta.
QST
