Partilhar via

Problemas Comuns

  • Artigo

Power Query

Preservando a classificação

Você pode supor que, se você classificar seus dados, todas as operações downstream preservam a ordem de classificação.

Por exemplo, se você classificar uma tabela de vendas para que a maior venda de cada loja seja mostrada primeiro, você pode esperar que fazer uma operação "Remover duplicatas" retorne apenas a venda principal de cada loja. E esta operação pode, de facto, parecer funcionar. No entanto, esse comportamento não é garantido.

Devido à forma como o Power Query otimiza determinadas operações, incluindo ignorá-las ou descarregá-las para fontes de dados (que podem ter seu próprio comportamento de ordenação exclusivo), não é garantido que a ordem de classificação seja preservada por meio de agregações (como Table.Group), mesclagens (como Table.NestedJoin) ou remoção de duplicados (como Table.Distinct).

Há várias maneiras de contornar isso. Eis algumas sugestões:

  • Execute uma classificação depois de aplicar a operação a jusante. Por exemplo, ao agrupar linhas, classifique a tabela aninhada em cada grupo antes de aplicar outras etapas. Aqui está um exemplo de código M que demonstra essa abordagem: Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}})
  • Armazene os dados em buffer (usando Table.Buffer) antes de aplicar a operação a jusante. Em alguns casos, essa operação faz com que a operação downstream preserve a ordem de classificação em buffer.
  • Use a classificação. Por exemplo, em vez de usar Table.Distincto , você pode ordenar pelas colunas que contêm os valores duplicados, classificar com base em uma coluna de desempate (como ) e, em modified_dateseguida, filtrar para manter apenas as linhas de classificação 1.

Inferência do tipo de dados

Por vezes, o Power Query pode detetar incorretamente o tipo de dados de uma coluna. Isto deve-se ao facto de o Power Query inferir tipos de dados utilizando apenas as primeiras 200 linhas de dados. Se os dados nas primeiras 200 linhas forem de alguma forma diferentes dos dados após a linha 200, o Power Query pode acabar por escolher o tipo errado. (Lembre-se de que um tipo incorreto nem sempre produzirá erros. Às vezes, os valores resultantes são simplesmente incorretos, tornando o problema mais difícil de detetar.)

Por exemplo, imagine uma coluna que contém números inteiros nas primeiras 200 linhas (como todos os zeros), mas contém números decimais após a linha 200. Neste caso, o Power Query infere o tipo de dados da coluna como Número Inteiro (Int64.Type). Essa inferência resulta em que as porções decimais de quaisquer números não inteiros sejam truncadas.

Ou imagine uma coluna que contém valores de data textuais nas primeiras 200 linhas e outros tipos de valores de texto após a linha 200. Neste caso, o Power Query infere o tipo de dados da coluna como Data. Essa inferência faz com que os valores de texto sem data sejam tratados como erros de conversão de tipo.

Como a deteção de tipo funciona nas primeiras 200 linhas, mas a Criação de Perfil de Dados pode operar em todo o conjunto de dados, você pode considerar o uso da funcionalidade Criação de Perfil de Dados para obter uma indicação antecipada no Editor de Consultas sobre Erros (da deteção de tipo ou de qualquer outro número de motivos) além das N linhas superiores.

Conexões fechadas à força pelo host remoto

Ao se conectar a várias APIs, você pode receber o seguinte aviso:

Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

Se você se deparar com esse erro, é mais provável que seja um problema de rede. Geralmente, as primeiras pessoas a verificar são os proprietários da fonte de dados à qual você está tentando se conectar. Se eles não pensam que são eles que fecham a conexão, então é possível que algo ao longo do caminho seja (por exemplo, um servidor proxy, roteadores/gateways intermediários e assim por diante).

Quer isso só se reproduza com quaisquer dados ou apenas com tamanhos de dados maiores, é provável que haja um tempo limite de rede em algum lugar na rota. Se for apenas com dados maiores, os clientes devem consultar o proprietário da fonte de dados para ver se suas APIs suportam paginação, para que possam dividir suas solicitações em partes menores. Caso contrário, devem ser seguidas formas alternativas de extrair dados da API (seguindo as práticas recomendadas da fonte de dados).

Os conjuntos de cifras TLS RSA estão preteridas

A partir de 30 de outubro de 2020, os seguintes conjuntos de cifras estão a ser preteridos dos nossos servidores.

  • "TLS_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_RSA_WITH_AES_256_CBC_SHA256"
  • "TLS_RSA_WITH_AES_128_CBC_SHA256"

A lista a seguir são os pacotes de codificação suportados:

  • "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"

Os conjuntos de cifras são usados para encriptar mensagens para proteger uma ligação de rede entre clientes/servidores e outros servidores. Estamos a remover a lista acima de conjuntos de cifras para cumprir com os nossos protocolos de segurança atuais. A partir de 1 de março de 2021, os clientes só podem usar os nossos conjuntos de cifras padrão.

Estes são os pacotes de codificação aos quais o servidor ao qual se liga tem de suportar para ligar a partir do Power Query Online ou do Power BI.

No Power Query Desktop (Power BI, Excel), não controlamos os seus pacotes de codificação. Se você estiver tentando se conectar à Power Platform (por exemplo, Power Platform Dataflows) ou ao Serviço do Power BI, precisará de um desses pacotes de codificação habilitados em seu sistema operacional. Pode atualizar a versão do Windows ou atualizar o registo do Windows TLS para se certificar de que o ponto final do seu servidor suporta uma destas cifras.

Para verificar se o servidor está em conformidade com o protocolo de segurança, você pode executar um teste usando uma ferramenta de cifra e scanner TLS. Um exemplo pode ser SSLLABS.

Os clientes devem atualizar a versão dos seus servidores antes de 1 de março de 2021. Para obter mais informações sobre a configuração da encomenda de Conjunto de Cifras TLS, consulte Gerir a Transport Layer Security (TLS).

Revogação do certificado

Uma versão futura do Power BI Desktop causa falha de conexões SSL da Área de Trabalho quando qualquer certificado na cadeia SSL está faltando status de revogação de certificado. Esta é uma alteração em relação ao estado atual, onde a revogação só causou falha de conexão no caso em que o certificado foi explicitamente revogado. Outros problemas de certificado podem incluir assinaturas inválidas e expiração de certificado.

Como há configurações nas quais o status de revogação pode ser removido, como com servidores proxy corporativos, forneceremos outra opção para ignorar certificados que não têm informações de revogação. Essa opção permite situações em que as informações de revogação são removidas em certos casos, mas você não quer diminuir totalmente a segurança, para continuar trabalhando.

Não é recomendado, mas os utilizadores podem continuar a poder desativar totalmente as verificações de revogação.

Erro: A avaliação foi cancelada

O Power Query devolve a mensagem "A avaliação foi cancelada" quando a análise em segundo plano está desativada e o utilizador alterna entre consultas ou fecha o Editor de Consultas enquanto uma consulta está em processo de atualização.

Erro: A chave não correspondeu a nenhuma linha na tabela

Há muitas razões pelas quais o Power Query pode retornar um erro de que a chave não correspondeu a nenhuma linha na tabela. Quando esse erro acontece, o mecanismo de mashup não consegue encontrar o nome da tabela que está procurando. As razões pelas quais esse erro pode acontecer incluem:

  • O nome da tabela foi alterado, por exemplo, na própria fonte de dados.
  • A conta usada para acessar a tabela não tem privilégios suficientes para lê-la.
  • Pode haver várias credenciais para uma única fonte de dados, o que não é suportado no Serviço do Power BI ao usar o Personal Cloud Connections. Esse erro pode acontecer, por exemplo, quando a fonte de dados é uma fonte de dados em nuvem e várias contas estão sendo usadas para acessar a fonte de dados ao mesmo tempo com credenciais diferentes. Se a fonte de dados for local, você precisará usar o gateway de dados local.

Limitação: requisito de ingresso no domínio para máquinas de gateway ao usar a autenticação do Windows

Usar a autenticação do Windows com um gateway local requer que a máquina de gateway seja associada ao domínio. Isso se aplica a todas as conexões configuradas com "autenticação do Windows através do gateway*. As contas do Windows usadas para acessar uma fonte de dados podem exigir acesso de leitura aos componentes compartilhados no diretório do Windows e na instalação do gateway.

Limitação: A atualização OAuth2 entre locatários não é suportada no serviço do Power BI

Se você quiser se conectar a uma fonte de dados do serviço do Power BI usando OAuth2, a fonte de dados deve estar no mesmo locatário que o serviço do Power BI. Atualmente, os cenários de conexão multilocatária não são suportados com o OAuth2.

Limitação: o ponto de extremidade de autenticação personalizado do AD FS não é suportado no serviço Power BI

A capacidade de usar um ponto de extremidade de autenticação personalizado dos Serviços de Federação do Ative Directory (AD FS) não é suportada no serviço Power BI. Os usuários podem encontrar o seguinte erro: O serviço de token relatado pelo recurso não é confiável.

Limitação: contas de convidado não são suportadas

Atualmente, não há suporte para o uso de contas de convidado de um locatário para se conectar a dados usando conectores do Power Query.

Expression.Error: A avaliação resultou em um estouro de pilha e não pode continuar

Os erros de estouro de pilha podem ser causados por um bug no seu código M. Por exemplo, a função a seguir produz um estouro de pilha porque ela repetidamente chama de volta para si mesma sem qualquer tipo de condição final. Uma função que se autodenomina assim é conhecida como função "recursiva".

let f = (x) => @f(x + 1) in f(0)

Aqui estão algumas maneiras comuns de resolver um estouro de pilha em seu código M.

  • Certifique-se de que suas funções recursivas realmente terminem quando a condição final esperada for atingida.
  • Substitua a recursão pela iteração (por exemplo, usando funções como List.Transform, List.Generate ou List.Accumulate).

Expression.Error: A avaliação ficou sem memória e não pode continuar

Erros de "falta de memória" (ou OOMs) podem ser causados por fazer muitas operações intensivas de memória em tabelas muito grandes. Por exemplo, o código M a seguir produz um OOM porque tenta carregar um bilhão de linhas na memória de uma só vez.

Table.Buffer(Table.FromList({1..1000000000}, Splitter.SplitByNothing()))

Para resolver erros de falta de memória, otimize as operações que consomem muita memória, como classificações, junções, agrupamentos e distinções, garantindo que elas se dobrem para a origem ou removendo-as completamente sempre que possível. Os tipos, por exemplo, são muitas vezes desnecessários.

Fluxos de Dados

Cancelar atualização do fluxo de dados

Às vezes, você inicia uma atualização de fluxo de dados, mas depois de iniciá-la percebe que queria alterar mais uma coisa antes de atualizar seus dados. Nesse caso, você tem que esperar até que a atualização seja concluída. Não há suporte para interromper uma atualização no meio do caminho, pois o processo já está trabalhando para obter os dados e atualizar as tabelas em seu espaço de trabalho ou ambiente.

Planejamos adicionar suporte para cancelar uma atualização de fluxo de dados no futuro.