‏‎Metadados

Referenciado por: Dicas Técnicas | Predefinição:Guia de Programação Banco de Dados | Guia para Exportação para Checkout do Totali Commerce | Guia para Manutenção de Estrutura do Totali Commerce | Guia para Manutenção de Functions e Procedures do Totali Commerce | Guia para Manutenção de Packages do Totali Commerce | Guia para Manutenção de Triggers do Totali Commerce | Guia para Manutenção de Views do Totali Commerce | Introdução a Programação de Banco do Totali Commerce | Padrões Gerais para Programação de Banco do Totali Commerce |

Guia de programação para linguagem de banco

Introdução

Padrões Gerais

Estrutura

Exportação para Checkout

Metadados

Views

Functions

Triggers

Packages

O metadados do Totali Commerce existe para que consultores e clientes possam criar relatórios com todos os dados do sistema.
Ele também é útil no momento no desenvolvimento consultar o significado das colunas e das tabelas.

Uma maneira de fazer alterações e consultas nesse metadados é através da ferramenta BI Config.

Criar ou alterar a documentação de um metadados é um processo delicado que envolve muita atenção e responsabilidade.
Um erro, ou uma modificação, pode fazer com que algum relatório importante do cliente pare após migração do sistema.

Importante lembrar que o metadados é totalmente recriado após cada migração.
Então tarefas abertas por consultores em clientes precisam ser feitas rapidamente porque o cliente não poderá migrar o banco de dados até que essas alterações estejam disponíveis.

O metadados no Totali BI é armazenado em uma pasta chamada cache.
Ao modificar o metadados da base pelo BIConfig, ou ao fazer migração, a coluna TT_IDF.VERMET é alterada.
Isso faz com que o Totali BI na abertura do sistema refaça sua pasta cache.

Tutorias

Documentar Nova Tabela

Para documentar uma nova tabela no metadados é necessário seguir os seguintes passos. Informar um código inexistente e clicar no botão novo.

Botão novo

Código

Montar apelido da tabela de acordo com o nome físico.
Na nomenclatura padrão de tabela basta pegar o sufixo.

Ex.:
Para TT_PRO a descrição é PRO.
Para TL_PRO a descrição é LPRO.
Para TD_PRO a descrição é DPRO.
Para TR_PRO a descrição é RPRO.
Para TV_PRO a descrição é VPRO.

No caso de um tabela com nome fora do padrão (ex.: TT_PROXPRA), utilizar uma abreviatura que tenha relação com o nome das duas tabelas ou relação com o negócio que a tabela representa.

Ex.:
Para TT_PROXPRA a descrição é PXP.

Select para trazer outros exemplos:

select cast(path as varchar(20)) as "Tabela", codtab as "Código" from tt_arq where length(path) > 6 order by path

Guia Dados

Na guia dados, os campos devem ser preenchidos levando em consideração as seguintes regras e definições.

Descrição da Tabela

Descrição sucinta do conteúdo da tabela.

Nome Físico da Tabela

Nome da tabela ou view no banco de dados.
Ex.: TT_PRO.

Global

Marcar quando houver necessidade de apresentar a tabela no combo inicial do Totali BI.
Por padrão, as tabelas de domínio [TDs] não são globais.
Deve-se questionar se o consultor precisará fazer um relatório a partir dessa tabela.

Tabelas disponíveis no Totali BI

Filtro Básico

É uma condição colocada na view que o Totali BI respeitará quando utilizar a tabela em qualquer relatório.
Exemplo na documentação Pedidos de Reposição (TT_PED):

PDR.CODFOR = 0

Unicidades

Nota: após pesquisa não foi possível encontrar um exemplo prático do Totali BI utilizando os campos definidos na unicidade.

Porém, é possível verificar no código fonte do Totali BI que essas expressões são utilizadas em quebras de linha.

Ao documentar unicidades, informar as combinações de colunas que tornam o registro da query único na visão de quem fará o relatório.

Colunas que compõe chave primária. No caso de clientes, FILCLI e CODCLI.

CLI.FILCLI,CLI.CODCLI

Colunas que compõe unique constraints No caso de clientes, poderíamos imaginar uma unique constraint com o CPF/CNPJ.

CLI.NUMDOC

Colunas que identificam unicidade do registro na visão de regra de negócio. No caso de clientes o nome completo poderia ser um bom exemplo.

CLI.NOMCLI,CLI.ULTNOM

No caso de tabelas com filhas, nas filhas é possível utilizar a coluna ID para representar a chave da tabela pai.
Então pode-se observar uma unicidade na Itens de Venda (TT_IVE):

VEN.ID, IVE.NUMITE

Relacionamentos

Os relacionamentos são muito importantes porque são graças a eles que é possível fazer um relatório envolvendo mais de uma tabela.
Podemos com eles partir dos clientes para trazer suas vendas e depois buscar os itens das vendas.
Poderíamos até trazer os produtos dos itens da venda se quisessemos.

Exemplo de Relacionamento no Totali BI

Para definir o relacionamento podemos fazer tanto na tabela pai quanto na tabela filha, mas nunca nas duas.
Embora, quando pensamos na visão do consultor, faz mais sentido ter o relacionamento da tabela pai para a tabela filha, porque o consultor vai buscar as vendas antes de trazer os itens de venda. No entanto deve-se dar prioridade para o relacionamento das tabelas filhas apontando para a pai.
Ou seja, os relacionamentos devem ficar semelhantes as FKs das tabelas.

A regra de multiplicidade dos relacionamentos do metadados devem ser iguais as da estrutura de dados.
Exceto nos casos de documentação de views ou de tabelas que possuem filtros básicos.

Relacionamento entre VEN e CLI

Multiplicidade

Para facilitar o entendimento da multiplicidade deve-se seguir os passos abaixo, que pega a relação entre venda e cliente como exemplo.

1. Observar que a FK está na TT_VEN e aponta para TT_CLI.

"fk_ven_cli" FOREIGN KEY (filcli, codcli) REFERENCES tt_cli(filcli, codcli)

2. Verificar que as colunas de cliente na venda são obrigatórias.

filcli | character(3) | not null codcli | character(6) | not null

3. Ler primeira a relação de uma venda (por ser o metadados que onde ficará a documentação) com clientes. 1 venda possui obrigatoriamente 1 cliente.

4. Ler a relação de um cliente com vendas. 1 cliente pode possuir uma ou várias vendas.

5. Sobrepor as leituras invertendo a segunda. 1 venda -> 1 cliente. pode possuir uma ou várias vendas -> 1 cliente

6. Trocar "pode possuir" por 0 e "várias" por N e sobrepor as duas preservando a menor e a maior possibilidade. 0N venda -> 1 cliente

Então o relacionamento deveria ser 0N VEN para 1 CLI.

Outro exemplo:
1 cliente possui 0 ou 1 categoria.
1 categoria possui 0 ou N clientes.

CLI 0N CAT 01

Importante:
No metadados oficial veremos que o relacionamento da Venda com a Cliente é N VEN para 1 CLI.
Está assim para que o sistema não traga clientes que não possuem vendas quando a venda estiver presente no relatório.
Isso é considerado uma otimização de desempenho, para tornar os relatórios mais rápidos.
Esse tipo de coisa deve ser feita com extrema cautela.

Proporcionalidade

As regras de proporcionalidade são utilizadas para quando existe um relacionamento de tabela pai com tabela filha.
A proporcionalidade definirá quanto do valor da tabela pai deverá ser utilizada em cada registro da tabela filha.
Isso só funcionará para colunas totalizáveis na tabela pai.

Exemplo:
No metadados da VEN (pai) existe um relacionamento com a IVE (filha).
Nesse relacionamento encontramos a seguinte expressão:

(case when VEN.VLRNOT = 0 then 0 else IVE.VLRMOV / VEN.VLRNOT end)

Isso quer dizer para cada coluna totalizável da tabela pai, o Totali BI multiplicará pelo resultado da expressão da proporcionalidade.
O case serve para impedir erro de "division by zero".

Regras

Basta documentar a relação das colunas da FK no padrão Oracle.
Ou seja, colando (+) ao lado das colunas de destino quando relacionamento não for obrigatório.

Exemplos:

Origem VEN e destino CLI CLI.FILCLI = VEN.FILCLI and CLI.CODCLI = VEN.CODCLI

Origem VEN e destino ECOB ECOB.FILCLI(+) = VEN.FILCLI AND ECOB.CODCLI(+) = VEN.CODCLI AND ECOB.CODFIL(+) = VEN.FILCOB AND ECOB.NUMEND(+) = VEN.ENDCOB

Filtros

O campo filtro da guia regras é parecido com o campo filtro básico.
A única diferença é que ele é aplicado apenas quando o relatório tiver a relação entre as tabelas.

Verifique metadados da VTEC para um exemplo.

Guia Colunas

Grupos

Para melhor visualização dos campos pelo consultor, estes podem ser agrupados na tela do Totali BI.
Essa organização se dá através da definição de qual grupo esses campos se encontram.

Exemplo de grupos no Totali BI

Definição dos grupos no BI Config

Nota:o grupo "--" é apresentado com o label Dados no Totali BI

Colunas

Deve-se documentar cada coluna da tabela no grid de colunas de acordo com as seguintes regras.

• Código: Grupo na qual a coluna será apresentada.
• Número: Serve para ordenar as colunas.
• Nome: Identificação da coluna no Totali BI. Quando estiver em branco, a coluna não poderá ser utilizada para criar relatório.
• Tipo: Tipo do dado da coluna.
• Tamanho: Tamanho do dado da coluna.
• Decimal: Número de casas decimais da coluna.
• Totalizável: Indica que a coluna pode ser totalizada no grid de resultados.
• Dado: Informar de acordo com o que a coluna vai armazenar.
• Filtro: Define como usuário poderá filtrar o dado.
• Nome Lógico: É a identificação da coluna para utilização em fórmulas e relacionamentos.
• Expressão: É uma coluna ou expressão que será utilizada na query quando o relatório fizer uso da coluna.
• Descrição: Longa descrição da coluna. Usada nos hints para ajudar a identificar as colunas.

Campo Tipo nas Colunas

Inteiro > 8: Usar para campos numéricos sem precisão, com 8 dígitos ou mais.

Inteiro > 4: Usar para campos numéricos sem precisão, com 4 dígitos ou mais.

Inteiro > 2: Usar para campos numéricos sem precisão, com até 3 dígitos.

Caractere: Usar para campos alfanuméricos.

Real: Usar para campos numéricos com precisão.

Lógico: Usar para campos alfanuméricos que tenham "T" ou "F".

Data: Usar para campos de data que não armazenem hora.

Data + Hora: Usar para campos de data e hora.

Memo: Usar para campos sem limite de tamanho.

Varchar II(4000): para colunas VARCHAR(4000). Ao documentarmos esse tipo de coluna no Commerce, devemos utilizar no campo expressão a função RTF2TXT. Normalmente, o uso desse tipo de dado está associado com campos de observação, e componentes de tela RichText. Por isso, é necessário o tratamento.

Campo Filtro nas Colunas

Deve-se definir de que forma o usuário poderá filtrar a coluna no Totali BI.
Isso se dá através de uma dessas opções da coluna filtro.

Domínio: Monta um combo com os itens definidos em domínio.
Usado quando a coluna for uma lista enumerada de valores.

Intervalo: permite informar valores de-até no filtro.
Usado para campos numéricos e de data.

Único: exige que o dado seja exatamente o colocado no filtro.
Usado para chaves e campos únicos.

LookUp: Não utilizar

LookUp com código significativo: Não utilizar

Alfanumérico: permite que se escolha filtro "inicia com" e "contendo".
Usado para alfanuméricos (texto).

Yes/No (lógico): permite que se escolha Sim ou Não. Usada para campos lógicos.
Usado para campos lógicos (verdadeiro ou falso).

Lista variável: monta um combo dinâmico de acordo com as regras definidas na guia domínio.
A regra utiliza é semelhante a dos relacionamentos.
Usado para montar combos dinâmicos com tabelas com poucos registros (TDs e tabelas com no máximo 200 registros).

Quando a coluna na origem permitir nulo, deve-se documentar o relacionamento da lista variável com LEFT OUTER JOIN.

Usar a indicação (+) e marcar o checkbox "Outer Join".

Quando a coluna na origem for NOT NULL, deve-se documentar como INNER.

Sem a indicação e com o checkbox desmarcado.

Ao definir uma lista variável, o BI faz um cache com os dados que serão utilizados nas consultas.
Por isso, quando fazemos a lista da Tabela A, por exemplo, precisamos definir Campo (expressão apresentada na consulta) de maneira igual ao de documentações que já utilizam a Tabela A.

Exemplo:
Se utilizarmos DCCC.DESCCC como expressão para uma lista variável de DCCC.
Sempre que fizermos uma lista variável DCCC precisaremos utilizar DESCCC.

Esse select ajuda a buscar e validar as listas variáveis em uma base:

SELECT codtab, nomcpo, deslis, codlis FROM tt_lay WHERE arqlis = 'DCCC' -- Tabela da Lista Variável AND tipfil = 'V' ORDER BY codtab

A melhor prática para documentar uma lista variável é criar uma nova coluna virtual, seguindo os passos abaixo:

1. Documentar a coluna TIPCCC sem nome para que não apareça no relatório (ou documentar como um código).
2. Documentar uma coluna virtual chamada DESCCC.
3. Essa coluna virtual deve ter atributos semelhante à DESCCC (Tam. 30 e Alfanumérica) da DCCC, porém com o filtro Lista Variável.
4. E por ser campo obrigatório, documentar DESCCC como sendo a expressão da coluna.

Estrela: Não utilizar

Exemplos de Colunas

Alguns exemplos de como documentar por tipo de coluna.

Filial:

Tipo	Tamanho	Decimal	Totalizável	Dado	Filtro	Expressão
Caractere	3	0	Não	Alfanumérico	Lista Variável	COLUNA

Arquivo: DFIL Regra: DFIL.CODFIL = VEN.CODFIL Outer Join: Falso Campo: DFIL.NOMFIL

Sequenciador:

Tipo	Tamanho	Decimal	Totalizável	Dado	Filtro	Expressão
Caractere	10	0	Não	Num. com espaços a esq.	Intervalo	COLUNA

Valor com ponto flutuante:

Tipo	Tamanho	Decimal	Totalizável	Dado	Filtro	Expressão
Real	12	2	Sim	Numérico a esquerda	Intervalo	COLUNA

Data e hora:

Tipo	Tamanho	Decimal	Totalizável	Dado	Filtro	Expressão
Data + Hora	7	0	Não	Data e hora	Intervalo	COLUNA

Boolean:

Tipo	Tamanho	Decimal	Totalizável	Dado	Filtro	Expressão
Lógico	1	0	Não		Yes/No (lógico)	COLUNA

Domínio:

Tipo	Tamanho	Decimal	Totalizável	Dado	Filtro	Expressão
Caractere	1	0	Não	Alfanumérico	Domínio	COLUNA

Parâmetros nas Expressões

É possível obrigar que o usuário do Totali BI passe parâmetros para a fórmula de uma determinada expressão.
É possível verificar exemplo disso na documentação dos Recebimentos (TT_REC).

No BI Config para cada expressão que utiliza parâmetros é necessário criar um grupo.
Os parâmetros precisam estar no mesmo grupo que a expressão que os utilizará.
É necessário que eles tenham ":" na frente do nome lógico.

Parâmetros no BI Config

No Totali BI, quando usuário selecionar o campo que utiliza parâmetros, estes se tornarão obrigatórios.

Parâmetros no Totali BI

Limitação do Campo Expressão

A coluna expressão possui um tamanho máximo de 255 caracteres quando não totalizar e 243 quando Totalizar.
Essa diferença se deve ao BI colocar um COALESCE na coluna assim limitando com 243.

Alias de Tabelas em Expressões

Temos que ter cuidado com os alias das expressões. Elas não devem coincidir com códigos de tabelas. Em um eventual relacionamento da tabela atual com a outra, o select poderá ficar comprometido.

Certo:

(SELECT F.PRESIM FROM TT_PXF F WHERE ...)

Errado:

(SELECT PXF.PRESIM FROM TT_PXF PXF WHERE ...)

Guia Relacionamentos

Essa guia serve para apresentar as colunas de banco de dados que compõe os relacionamento entre as tabelas [FKs].

Atualizar Tabela

Quando está faltando documentar alguma nova coluna podemos utilizar o botão Atualizar.
Ele cria documentação das colunas que existem no banco de dados mas não existem no metadados automaticamente.
É necessário apenas complementar o cadastro após utilizar o botão.

Botão atualizar

O padrão é documentarmos todas as colunas de todas as tabelas.
Se houver necessidade de esconder do usuário alguma coluna por ser de uso interno, deve-se documentá-la sem a descrição abreviada ("Nome").

Técnicas

Pesquisar Tabelas

Antes de documentar nova tabela no metadados é necessário conferir se ela já existe, ou se existe alguma outra tabela documentada com o código que se deseja registrar.
Utilizar o botão Buscar na barra de botões superior da tela principal do BI Config.

Botão Buscar

Pesquisa de Tabela no BI Config

Duplicar Tabela

É possível duplicar uma documentação do metadados utilizando o botão Duplicar.

Botão duplicar

Esse recurso pode ser usado quando queremos documentar uma tabela que é muito parecida com alguma outra.
Ou quando precisamos ter duas tabelas semelhantes no metadados.

A necessidade de ter tabelas duplicadas existe porque o BI não permite que se referencie a mesma tabela duas vezes em um relatório.
Então para fazer um relatório de Fatura e Remessa é necessário ter duas documentações da TT_VEN.

Gerar Script da Tabela

Para compor o script de migração devemos extrair no metadados o arquivo MD*.sql através do botão Script.

Botão script

Esse arquivo deve ser armazenado na pasta metadados dos fontes:

T:\totalicommerce\<versão>\ansi\metadados\

Teste de metadados completo

Depois que o arquivo MD*.sql estiver alterado execute o arquivo T:\<versão>\ansi\metadados\CRIASQL.BAT.
Observe que esse CRIASQL.BAT está no mesmo diretório do arquivo MD modificado.
Esse ação criará o arquivo METADADOS.SQL.
Esse arquivo deverá ser executado tanto no Oracle quanto no PostgreSQL.
Esse arquivo está pronto para ser executado, portanto, NÃO PODE ser alterado pelo TTConvert.
Por ser um arquivo único tanto pra Oracle como para PostgreSQL o banco de dados poderá apresentar alguns erros ao aplicar.
Abrir novamente o BIConfig para verificar se a alteração realizada continua lá.

Teste de tabela do metadados em Oracle

É possível testar somente a tabela modificada utilizando o script ATUALIZA_TABELA.SQL da pasta do metadados.
Executá-lo no SQLPLUS.
Ele solicitará:

1. Apelido da tabela (CODTAB da TT_ARQ. Ex.: VEN)
2. Versão do Commerce (versão da pasta onde estão os arquivos de metadados. Ex.: 5.0i)
3. Sufixo do arquivo (Nome do arquivo sem MD e sem extensão. Ex.: VEN)

Aplicar conteúdo do arquivo de metadados

Também pode-se utilizar o script abaixo para aplicar o conteúdo de um ou mais arquivos de metadados [MD*.sql].

Exemplo para recriar o metadados da CLI.

/*-- SEQ 5447 --*/ /*-- IGNORE ERRO --*/ ALTER TABLE tt_arq DROP constraint fk_arq_arq;   /*-- SEQ 5448 --*/ /*-- IGNORE ERRO --*/ ALTER TABLE tt_lay DROP constraint fk_lay_arq_origem;   /*-- SEQ 5449 --*/ /*-- IGNORE ERRO --*/ ALTER TABLE tt_lay DROP constraint fk_lay_arq_arqlis;   /*-- SEQ 5450 --*/ /*-- IGNORE ERRO --*/ ALTER TABLE tt_sql DROP constraint fk_sql_arq_codori;   /*-- SEQ 5451 --*/ /*-- IGNORE ERRO --*/ ALTER TABLE tt_sql DROP constraint fk_sql_arq_coddes;   /*-- SEQ 5452 --*/ /*-- IGNORE ERRO --*/ ALTER TABLE tp_lay DROP constraint fk_play_arq;   DELETE FROM TT_DOM WHERE CODARQ IN ('CLI');   DELETE FROM TT_LAY WHERE CODTAB IN ('CLI');   DELETE FROM TT_GRU WHERE CODTAB IN ('CLI');   DELETE FROM TT_ARQ WHERE CODTAB IN ('CLI');   DELETE FROM TT_SQL WHERE CODORI IN ('CLI');   -- Executar o MDCLI.sql   /*-- SEQ 8754 --*/ ALTER TABLE tt_arq ADD CONSTRAINT fk_arq_arq FOREIGN KEY (codfis) REFERENCES tt_arq(codtab);   /*-- SEQ 8755 --*/ ALTER TABLE tt_lay ADD CONSTRAINT fk_lay_arq_origem FOREIGN KEY (origem) REFERENCES tt_arq(codtab);   /*-- SEQ 8756 --*/ ALTER TABLE tt_lay ADD CONSTRAINT fk_lay_arq_arqlis FOREIGN KEY (arqlis) REFERENCES tt_arq(codtab);   /*-- SEQ 8757 --*/ ALTER TABLE tt_sql ADD CONSTRAINT fk_sql_arq_coddes FOREIGN KEY (coddes) REFERENCES tt_arq(codtab) ON DELETE CASCADE;   /*-- SEQ 8758 --*/ ALTER TABLE tt_sql ADD CONSTRAINT fk_sql_arq_codori FOREIGN KEY (codori) REFERENCES tt_arq(codtab) ON DELETE CASCADE;   /*-- SEQ 8759 --*/ ALTER TABLE tp_lay ADD CONSTRAINT fk_play_arq FOREIGN KEY (codtab) REFERENCES tt_arq(codtab);   UPDATE tt_idf SET vermet = vermet+0.01;

Como Lidar com Erros na Aplicação do Metadados

Se ao gerar o metadados ocorrer algum erro, é possível remover o comentário da linha que faz um echo do nome da tabela no bat que cria o arquivo metadados.sql [MSGSQL.bat].
Com isso, ao aplicar o metadados.sql é possível saber exatamente em que tabela está ocorrendo o problema.

Validar Metadados

1. Aplicar MDCFG em Oracle utilizando ATUALIZA_TABELA.SQL. Deve aplicar sem erros.

2. Aplicar MDCFG em PostgreSQL utilizando METADADOS.SQL. Esse arquivo é através da execução do CRIASQL.BAT que se encontra na pasta do metadados. Aplicar e verificar se apenas ocorre erro ao executar CARGAPERSONALIZADO na sintaxe de Oracle.

3. Entrar no BIConfig e validar metadados em Oracle.

• Verificar se o grupo escolhido para coluna é o mais coerente.
• Verificar se "Nome" equivale ao definido em "Descrição Abrev.".
• Verificar se "Descrição" equivale ao definido em "Descrição Completa".
• Verificar dados da coluna:
  • Tipo
  • Tamanho
  • Decimal
  • Totalizável
  • Dado
  • Filtro

4. Verificar se relações com tabelas "TD_" foram documentar apenas como Lista Variáveis. E verificar se as listas variáveis estão corretas.

5. Verificar se demais relações foram documentadas como relacionamento.

6. Se uma das colunas documentadas for uma Lista Variável, verificar se a documentação atende aos seguintes critérios:

• Preferência por utilizar uma coluna virtual.
• A coluna Campo (expressão apresentada no relatório) deve ser a mesma em todas as Listas Variáveis com àquela tabela.

Os selects abaixo ajudam nessa verificação:

<span class="kw1">SELECT</span> codtab<span class="sy0">,</span> nomcpo<span class="sy0">,</span> deslis <span class="kw1">FROM</span> tt_lay <span class="kw1">WHERE</span> arqlis <span class="sy0">=</span> <span class="st0">'USU'</span> <span class="co1">-- Trocar a tabela</span> <span class="kw1">AND</span> tipfil <span class="sy0">=</span> <span class="st0">'V'</span> <span class="kw1">ORDER</span> <span class="kw1">BY</span> codtab

<span class="kw1">SELECT</span> arqlis<span class="sy0">,</span> <span class="kw2">COUNT</span><span class="br0">(</span><span class="sy0">*</span><span class="br0">)</span> <span class="kw1">FROM</span> <span class="br0">(</span> <span class="kw1">SELECT</span> arqlis<span class="sy0">,</span> deslis <span class="kw1">FROM</span> tt_lay <span class="kw1">WHERE</span> tipfil <span class="sy0">=</span> <span class="st0">'V'</span> <span class="kw1">GROUP</span> <span class="kw1">BY</span> arqlis<span class="sy0">,</span> deslis <span class="br0">)</span> tab <span class="kw1">GROUP</span> <span class="kw1">BY</span> arqlis <span class="kw1">HAVING</span> <span class="kw2">COUNT</span><span class="br0">(</span><span class="sy0">*</span><span class="br0">)</span> <span class="sy0">></span> <span class="nu0">1</span> <span class="kw1">ORDER</span> <span class="kw1">BY</span> arqlis

Mostra a expressão utilizada para uma determinada tabela.

Deve retornar sempre vazio.

Descontinuar coluna

Em determinadas situações, uma coluna deixa de ser utilizada ou a forma como está documentada não é a mais indicada. Para manter a compatibilidade com clientes que usam essas colunas em relatórios, principalmente na forma de filtros, devemos mantê-las documentadas. Nesse caso temos que descontinuá-las, utilizando o seguinte padrão:

• Adicionar um sustenido (#) no início da descrição abreviada
• Adicionar a expressão "(descontinuado)" ao final da descrição completa

Dicionário de Dados

TT_ARQ

Onde são armazenadas as tabelas.

TT_SQL

Onde são armazenados os relacionamentos.

TT_GRU

Onde são armazenados os grupos de campos.

TT_LAY

Onde são armazenadas as colunas.

TT_DOM

Onde são armazenados os domínios das colunas que são lista variável.