Las fórmulas relacionadas y LookupValue no funcionan: resultados en blanco. Por favor ayuda

Un usuario Pregunto ✅

Anónimo

«Tengo 2 tablas (A, B) que están relacionadas con Many to One. Creé un ID de clave en cada tabla para habilitar la relación. Esa clave es una función concatenada de una fecha y un nombre. Por ejemplo:» Buildingname10 / 21 / 2019 «

En la tabla principal en la que estoy trabajando (A), intenté usar una fórmula de LookUpValue para obtener algunos datos específicos de la tabla B. Recibí el error: se proporcionó una tabla de múltiples valores donde se esperaba un solo valor.

Esa misma fórmula funcionó en otra columna de A para obtener datos de una tabla C. Las tablas A y C están relacionadas uno a uno.

El uso de la función RELACIONADO para intentar obtener los datos de la columna B tampoco funciona. Las columnas de B no se muestran en la fórmula. También creé una cuarta tabla (D) usando FILTER y CALCULATE TABLE, con una relación de muchos a uno con A. Los métodos explicados anteriormente tampoco funcionaron.

¿Alguna idea para solucionar este problema?

YJ

En respuesta a Anónimo

Hola,

Guau, puedo ver un gran esfuerzo especialmente en todas las llaves del edificio.

Hay algunas pequeñas consideraciones a tener en cuenta:

1. su clave table2rev.building no es única. por lo que veo, desea obtener su valor de tipo 1, esos se repiten con los mismos valores debido a la diferencia de columna.

Lookup01.JPG

2. La medida que está utilizando:

2019 Edificio A – Tipo 1 = LOOKUPVALUE (‘Tabla 2 -rev'[Type 1], ‘Fechas futuras'[building A – Type 1 Key], CONCATENAR («Edificio A», ‘Fechas futuras'[Date]))
Normalmente, la columna de resultados debe estar siempre en la misma tabla que la columna de búsqueda, para el valor de búsqueda
3. mi opinión personal es que uno debería estandarizar su formato de fecha si va a concatenarlo: de la mayoría de su ejemplo, lo más cercano que veo es FORMATO (su valor, «D / M / AAAA»). Personalmente, hubiera preferido que DDMMYYYY mantuviera la misma longitud de cadena si de hecho tiene que ver esto como parte de una clave de construcción.
La medida de revoluciones propuesta responde directamente a su pregunta, teniendo en cuenta los 3 puntos anteriores:
REV1_2019 Edificio A – Tipo 1 = LOOKUPVALUE (‘Tabla 2 -rev'[Type 1], ‘Tabla 2 -rev'[building key], CONCATENAR («Edificio A», FORMAT (‘Fechas futuras'[Date], «D / M / AAAA»)), ‘Tabla 2 -rev'[dif], 0)
También formateo de la misma manera en
Table2rev. clave de construcción = CONCATENAR (‘Tabla 2 -rev'[building], FORMAT (‘Tabla 2 -rev'[Date], «D / M / AAAA»))

Lookup02.JPG

(tenga en cuenta que supongo que no hay diferencia en los valores de tipo, cualquiera que sea el valor de dif)

Adjunté el archivo pbix modificado:

PBIX

Lo anterior debería responder a su pregunta sobre por qué el valor de búsqueda no funciona.

En una nota al margen, aunque todavía no entiendo cuál es su intención general. Mi opinión es que su modelo actual podría ser, en mi humilde opinión, muy difícil de mantener. Para una solución más ordenada, se podría considerar tener una tabla de construcción distinta separada, una tabla de calendario y usar calcular y agregar fecha para comparar la fecha del año pasado y obtener valores de tipo 1, 2, 3, etc., sin embargo, esto sería un qns conceptual largo y separado.

mientras tanto espero que aclare las dudas de lookupvalue que tiene.

Saludos

Si desea una solución simple (y potencialmente peligrosa). Simplemente vaya a su modelo de relación y habilite el filtrado en ambas direcciones. Esto debería permitir que los distintos enfoques funcionen, pero puede ser un poco inestable.

Anónimo

En respuesta a artemus

Hola @artemus. Traté de habilitar el filtrado, también aplicar el filtro de secturidad en ambas direcciones.

Todavía tengo resultados en blanco en todos los casos.

YJ

En respuesta a Anónimo

adjunte su archivo y le echaremos un vistazo.

Saludos

Anónimo

En respuesta a YJ

Hola,

Busque el enlace del archivo. El error se encuentra en la tabla «Fechas futuras», Edificio A de 2019: columna Tipo 1

https://drive.google.com/file/d/1F1vm8gcAt-3G_5dilL2esiNoOqNRCfN5/view?usp=sharing

Gracias,

YJ

En respuesta a Anónimo

Hola,

Guau, puedo ver un gran esfuerzo especialmente en todas las llaves del edificio.

Hay algunas pequeñas consideraciones a tener en cuenta:

1. su clave table2rev.building no es única. por lo que veo, desea obtener su valor de tipo 1, esos se repiten con los mismos valores debido a la diferencia de columna.

Lookup01.JPG

2. La medida que está utilizando:

2019 Edificio A – Tipo 1 = LOOKUPVALUE (‘Tabla 2 -rev'[Type 1], ‘Fechas futuras'[building A – Type 1 Key], CONCATENAR («Edificio A», ‘Fechas futuras'[Date]))
Normalmente, la columna de resultados debe estar siempre en la misma tabla que la columna de búsqueda, para el valor de búsqueda
3. mi opinión personal es que uno debería estandarizar su formato de fecha si va a concatenarlo: de la mayoría de su ejemplo, lo más cercano que veo es FORMATO (su valor, «D / M / AAAA»). Personalmente, hubiera preferido que DDMMYYYY mantuviera la misma longitud de cadena si de hecho tiene que ver esto como parte de una clave de construcción.
La medida de revoluciones propuesta responde directamente a su pregunta, teniendo en cuenta los 3 puntos anteriores:
REV1_2019 Edificio A – Tipo 1 = LOOKUPVALUE (‘Tabla 2 -rev'[Type 1], ‘Tabla 2 -rev'[building key], CONCATENAR («Edificio A», FORMAT (‘Fechas futuras'[Date], «D / M / AAAA»)), ‘Tabla 2 -rev'[dif], 0)
También formateo de la misma manera en
Table2rev. clave de construcción = CONCATENAR (‘Tabla 2 -rev'[building], FORMAT (‘Tabla 2 -rev'[Date], «D / M / AAAA»))

Lookup02.JPG

(tenga en cuenta que supongo que no hay diferencia en los valores de tipo, cualquiera que sea el valor de dif)

Adjunté el archivo pbix modificado:

PBIX

Lo anterior debería responder a su pregunta sobre por qué el valor de búsqueda no funciona.

En una nota al margen, aunque todavía no entiendo cuál es su intención general. Mi opinión es que su modelo actual podría ser, en mi humilde opinión, muy difícil de mantener. Para una solución más ordenada, se podría considerar tener una tabla de construcción distinta separada, una tabla de calendario y usar calcular y agregar fecha para comparar la fecha del año pasado y obtener valores de tipo 1, 2, 3, etc., sin embargo, esto sería un qns conceptual largo y separado.

mientras tanto espero que aclare las dudas de lookupvalue que tiene.

Saludos

Anónimo

En respuesta a YJ

Muchas gracias @YJ, opté por crear un calendario y una tabla de construcción como se sugirió. ¡El método funcionó!

YJ

Hola,

para que ambos funcionen, lo ideal es que la búsqueda sea una tabla con valores de búsqueda únicos.

En el caso de lookupvalue, también puede especificar un «resultado alternativo» en el caso de que result_columnName se filtra a un valor cero o un error cuando hay más de un valor distinto:

VALOR DE BÚSQUEDA( , ,[, <search_columnName>, <search_value>]…[, <alternateResult>])

si puede cargar su archivo pbix y sería más fácil ver por qué.

Saludos

SK

Anónimo

En respuesta a YJ

Hola,

Intenté incorporar el resultado alternativo a la fórmula LOOKUPVALUE. El resultado también está en blanco.

La mayoría de las fechas relacionadas con la identificación que creé no son únicas. ¿Algunas ideas?

Generalmente SELECTEDVALUE es la función que desea utilizar aquí. Devolverá EN BLANCO si hay varios valores no idénticos que podría ser.

Anónimo

En respuesta a artemus

Gracias por revisar @artemus. Apliqué SELECTEDVALUE y vuelve en blanco para todas las filas. ¿Alguna otra idea?

Deja un comentario

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