Atualização transacional da cache de tabelas dinâmicas

A versão 2.384.92 atualiza origens de tabelas dinâmicas locais retangulares, de nomes definidos e de tabelas sem mudar objetos de campos existentes, objetos de itens partilhados ou índices lógicos de membros; todas as vistas de PivotTable que partilham a cache continuam a referir os mesmos membros

Atualização do livro

Workbook.Recalculate;
if Workbook.RefreshPivotCache(Pivot.CacheId) <> 1 then
  raise Exception.Create('Pivot cache refresh failed');

O TXLSXWorkbook.RefreshPivotCache devolve 1 após uma atualização bem sucedida e -1 quando a cache, a origem, o esquema ou os valores de origem não podem ser atualizados; lê os valores atuais das células, por isso recalcule primeiro o livro quando as fórmulas da origem precisarem de avaliação

Uma origem retangular usa uma folha de cálculo local existente e uma linha de cabeçalho; SourceFirstRow, SourceFirstCol, SourceLastRow e SourceLastCol usam coordenadas inclusivas de base um, e a primeira linha fornece os nomes dos campos

Origens de nomes definidos e de tabelas

Quando SourceIsNamedRange=True, o SourceName identifica um nome definido ou um nome de tabela único ou nome de apresentação; a atualização e a materialização resolvem a geometria atual em cada chamada, preservando a identidade da origem guardada na cache

O SourceRangeSheet fornece o contexto de folha de cálculo para um nome definido local; esse âmbito tem precedência sobre um nome de livro com a mesma grafia, e de resto a resolução usa o âmbito do livro sem escolher um nome local não relacionado

Um nome definido tem de conter um único retângulo absoluto explicitamente qualificado por folha de cálculo; nomes de folhas entre aspas e Unicode são suportados, enquanto referências relativas, uniões, alias, fórmulas, referências externas e colisões ambíguas nome/tabela provocam rejeição antes da mutação

Uma tabela tem de manter uma linha de cabeçalho; os registos seguem a extensão atual e excluem uma linha de totais real, enquanto as verificações de colisão protegem a tabela inteira, incluindo os totais; uma tabela só com cabeçalho fornece zero registos

A pertença física de totais segue o totalsRowCount armazenado, cujo valor ausente significa zero; uma indicação de UI de totais por si só não remove uma linha de dados, e a gravação escreve a pertença real explicitamente

Para uma linha de totais escrita por si, forneça metadados válidos de totais de colunas e conteúdo de folha de cálculo através de ColumnTotalsRowLabels, ColumnTotalsRowFunctions e ColumnTotalsRowFormulas; definir TotalsRowShown=True não cria fórmulas de totais nem coage valores de células

As movimentações de folhas de cálculo mantêm o âmbito local de nomes, e as renomeações de folhas de cálculo atualizam referências locais suportadas e o contexto de origem das tabelas dinâmicas, preservando referências externas não relacionadas e o XML opaco de caches importadas; a gravação de nomes definidos remove um sinal de igual inicial opcional da fórmula sem mudar a fórmula em memória

Os cabeçalhos correspondem a campos de bases de dados existentes pelo nome, sem sensibilidade a maiúsculas e minúsculas; reordenar colunas da origem preserva os índices lógicos de campos, enquanto campos de origem duplicados, renomeados, em falta ou extra são rejeitados; cabeçalhos vazios usam o fallback existente FieldN

As células de origem vazias mantêm-se vazias sem serem adicionadas à coleção de células da folha de cálculo; origens só com cabeçalho produzem zero registos mantendo os membros históricos

Membros estáveis e vistas partilhadas

Os itens partilhados existentes mantêm os respetivos índices e identidades de objetos, e novos valores com tipo acrescentam-se ao domínio; reordenar, remover e reintroduzir mais tarde membros da origem preserva itens ocultos, seleções de página, referências de itens base e mapeamentos de grupos explícitos que já identificam esses membros

Todas as vistas que partilham uma cache veem os registos atualizados; os membros históricos ausentes mantêm-se no domínio da cache mas não criam sozinhos linhas agregadas, porque o TXLSPivotTable.Make constrói os resultados a partir dos registos atuais

Os membros históricos mantêm-se independentemente do MissingItemsLimit; este caminho de atualização não purga membros em falta, não impõe um limite de membros retidos nem renumera índices de seleção

Valores numéricos, de data, Boolean, de texto, em branco e erros representáveis mantêm os respetivos tipos através da atualização e da gravação em XLSX; as flags de conteúdo de itens partilhados e os limites representáveis são recalculados a partir do domínio retido e recém-acrescentado

A gravação conclui as listas de membros das vistas atualizadas antes dos itens de subtotais finais, preservando a ordem existente, as flags ocultas e as extensões de layout importadas; as seleções de página mapeiam entre membros lógicos da cache e as posições guardadas em cada vista, pelo que listas de membros reordenadas ainda selecionam o mesmo membro após reabrir

Campos calculados e agrupados

Os campos calculados não consomem colunas da origem; os respetivos nomes, fórmulas e domínios de itens partilhados mantêm-se disponíveis, enquanto cada registo atualizado começa com um marcador vazio para esses campos; o Make avalia fórmulas calculadas suportadas a partir dos valores atuais da origem

Os registos de caches XLSX guardam apenas campos de bases de dados; gravar e reabrir preservam o alinhamento com as colunas da origem mesmo quando os campos calculados ocorrem entre campos de bases de dados

O agrupamento numérico e de datas num campo de origem pode aceitar novos membros; o agrupamento discreto explícito aceita membros existentes reordenados, mas rejeita um novo membro sem mapeamento explícito, preservando toda a cache anterior

A versão 2.384.94 reconstrói campos agrupados derivados fixos suportados a partir de ligações base/pai validadas; a expansão automática de domínios, os membros discretos sem mapeamento e os campos de propriedades de membros provocam rejeição transacional, enquanto as origens externas e OLAP permanecem fora do contrato de origens locais; consulte os limites das caches agrupadas

Atualizações atómicas e atualização por callback

A validação da origem, a leitura, a conversão de tipos, a alocação de registos e a pesquisa de membros terminam em dados de preparação destacados; uma falha deixa intactos os handles vivos de campos e itens, os registos, os metadados, o estado de replay bruto e todas as vistas partilhadas

O sucesso substitui os buffers de registos e de pesquisa, desativa o replay bruto da cache, atualiza o RefreshedDate e define RefreshOnLoad=False; gravar usa a cache com tipo atualizada em vez de repetir a representação bruta anterior

Código autónomo ou suportado pelo Classic pode usar a mesma implementação de preparação através do TXLSPivotCache.RefreshFromSource; o respetivo leitor recebe coordenadas de origem de base um e devolve um Variant, e falhas de validação ou do leitor lançam uma exceção

TlxPivotSourceCellValue = function(ARow, ACol: Integer): Variant of object;

procedure TXLSPivotCache.RefreshFromSource(AValueReader: TlxPivotSourceCellValue);
procedure TXLSPivotCache.RefreshFromSource(AValueReader: TlxPivotSourceCellValue;
  AFirstRow, AFirstCol, ALastRow, ALastCol: Integer);

A sobrecarga de um argumento exige um retângulo local concreto na cache; a sobrecarga de limites explícitos lê um retângulo local resolvido pelo chamador sem mudar a identidade da origem nomeada ou de tabela da cache, e os chamadores continuam responsáveis por resolver essa identidade corretamente

A atualização da cache atualiza os dados da cache; as aplicações podem chamar Make com o respetivo escritor de resultados ou MaterializePivotTable para saída guardada na folha de cálculo; a seleção de Slicer de tabelas dinâmicas não OLAP com tipo está disponível para bindings importados suportados, enquanto o layout nativo completo continua a ser trabalho separado