Entendendo SX2, SX3 e SIX
Se você trabalha com Protheus, já deve ter ouvido falar em SX2, SX3 e SIX — aquelas “siglas misteriosas” do dicionário de dados. Elas parecem complicadas à primeira vista, mas, na prática, são apenas maneiras do sistema guardar informações sobre tabelas, campos e índices. Neste artigo eu vou explicar, com calma e exemplos do dia a dia, o que cada uma representa, como se relacionam e por que é importante conhecê-las antes de mexer na estrutura do seu ambiente.
O que é um dicionário de dados (de um jeito simples)
Pense no dicionário de dados como a ficha técnica de cada tabela do sistema. Num caderno de receitas, além da lista de ingredientes, você teria notas como “quantidade”, “tipo” (salgado/doce) e “tempo de preparo” — no Protheus, o dicionário guarda esse tipo de informação sobre cada campo e cada tabela.
- Quem usa: desenvolvedores, consultores, DBAs e até analistas de negócio que precisam entender a estrutura.
- Para que serve: validar integrações, criar relatórios, gerar telas, evitar erros ao gravar/ler dados.
- Risco de ignorar: alterações feitas só no arquivo físico (DBF/SQL) sem atualizar o dicionário podem causar falhas no ERP.
Visão geral: SX2, SX3 e SIX — cada um na sua função
As três siglas aparecem nos ambientes Protheus para registrar metadados essenciais:
- SX2 — geralmente armazenaria a definição dos campos: nome lógico, tipo, tamanho, máscara, se é obrigatório, descrição e propriedades de interface.
- SX3 — relacionada à definição das tabelas/arquivos: nome físico, alias, chave primária, ordem dos campos, e descrições maiores sobre o arquivo como um todo.
- SIX — guarda informações sobre os índices: nome do índice, campos que o compõem, ordem (asc/desc), tipo (único, composto) e se é usado como chave primária.
Observação importante: dependendo da versão do Protheus e do banco de dados subjacente, a forma física dessas informações e o nome exato das tabelas de dicionário podem variar. Mas conceitualmente, SX2 → campos, SX3 → arquivos/tabelas, SIX → índices.
SX2 detalhado: a ficha de cada campo
Imagine que a tabela de clientes tem um campo chamado CODCLI. O SX2 é onde existe a “ficha” desse CODCLI: tipo (inteiro, caractere), tamanho, se aceita nulos, descrição curta, máscara de edição (por exemplo, CNPJ/CPF), valores válidos, e até qual máscara exibir na tela.
Por que isso é útil? Porque quando o Protheus precisa montar uma tela, validar um formulário ou gerar um layout de importação, ele consulta essas informações para saber como tratar o dado.
- Exemplo prático: você cria um campo novo para armazenar “número de delivery” — se não cadastrar esse campo no SX2, o Protheus pode aceitar o dado fisicamente, mas telas, relatórios e rotinas que dependem do dicionário não vão reconhecer o campo.
- Validação: o SX2 pode marcar um campo como obrigatório, evitando que processos gravem registros incompletos.
- Migração: quando se importa um layout de dados, o importador usa o SX2 para converter tipos e tamanhos.
Quando for editar o SX2, fique atento a:
- Tipo e tamanho — alterar sem checar pode truncar dados.
- Máscaras e descrições — ajudam usuários e integradores.
- Dependências em código (advpl) — alterações podem quebrar rotinas que assumem o formato antigo.
SX3 detalhado: a identidade da tabela
Enquanto o SX2 descreve o “quem” (os campos), o SX3 descreve o “o quê” — a própria tabela ou arquivo. Pense nele como a capa do caderno: o nome, como ele se relaciona com outros cadernos e qual é a chave que identifica cada página.
Entre as informações típicas do SX3 estão:
- Nome físico do arquivo/tabela e seus alias.
- Layout lógico: qual é a chave primária e se existem chaves alternativas.
- Comentários ou descrições maiores sobre o propósito daquela tabela.
- Indicação de tabelas relacionadas (quando aplicável).
Exemplo do dia a dia: ao abrir uma rotina que lista produtos, o sistema precisa saber qual tabela consultar e qual campo usar como chave (por exemplo, CODPRO). Essa referência vem do SX3.
Dica: antes de renomear ou recriar tabelas no banco, sempre atualize o SX3 para manter o ERP consistente. Ferramentas de sincronização do Protheus podem comparar o SX3 com o banco e apontar divergências.
SIX (índices): como o sistema encontra as informações rápido
Índices são como índices de um livro: ajudam o Protheus a achar linhas rapidamente sem ler o livro inteiro. O SIX contém a “receita” de cada índice — quais campos participam, em que ordem e que tipo de ordenação usar.
Por que isso importa? Porque índices mal configurados podem deixar consultas lentas ou fazer com que certas buscas ou ordenações não funcionem.
- Índice primário: normalmente garante unicidade e identifica um registro (por exemplo, um índice sobre CODCLI).
- Índices secundários: ajudam buscas frequentes, como pesquisar por CPF ou por código de referência.
- Índice composto: quando uma busca é feita por mais de um campo (ex: cidade + bairro).
Exemplo prático: se o seu relatório busca todos os pedidos por data e vendedor, um índice composto (data, vendedor) vai acelerar muito essa consulta — o SIX é que registra essa combinação para o Protheus saber qual índice usar.
Como SX2, SX3 e SIX se relacionam na prática
Esses três elementos conversam entre si o tempo todo:
- O SX3 "fala" para o sistema qual tabela está sendo usada e qual é a chave primária;
- O SX2 descreve cada campo dessa tabela para que o sistema saiba como tratá-lo;
- O SIX informa quais campos formam índices, permitindo buscas e ordenações rápidas.
Quando você cria um campo novo (ex.: TELEFONE2) para a tabela de clientes:
- Adicione a definição do campo no SX2 (tipo, tamanho, máscara);
- Atualize o SX3 se a nova coluna faz parte da estrutura lógica que precisa ser conhecida (por exemplo, se for chave alternativa);
- Crie um índice no SIX se for necessário buscar frequentemente por esse campo.
Não fazer alguma dessas etapas é o que causa problemas clássicos: tela que não mostra o campo, rotina que não grava, relatório que não reconhece os dados.
Casos práticos: tarefas comuns e como os dicionários impactam
A seguir alguns exemplos práticos que você, consultor ou desenvolvedor, provavelmente vai encontrar:
1) Acrescentar um campo novo à tabela de clientes
- SX2: definir o novo campo (NOME: TELEFONE2, TIPO: caractere, TAMANHO: 15, MASCARA: (00) 00000-0000, OBRIGATÓRIO: não).
- SX3: normalmente não precisa mudar se a tabela física já recebeu a coluna, mas se o campo fizer parte de alguma chave lógica, atualize.
- SIX: só criar índice se for pesquisar muito por TELEFONE2.
- Resultado: telas que usam dicionário passam a exibir e validar o novo campo corretamente.
2) Tornar um campo obrigatório
- Altere apenas no SX2 para marcar o campo como obrigatório (se a rotina respeitar o dicionário, ela vai bloquear gravação sem o dado).
- Verifique rotinas customizadas — algumas podem ignorar o dicionário e validar manualmente.
3) Otimizar uma consulta lenta
- Identifique a consulta que é lenta (ex.: busca por data e vendedor).
- Verifique se existe um índice adequado no SIX; se não, crie um índice composto (DATA, VENDEDOR).
- Atualize o SX3/SX2 se necessário, e teste impacto em gravações (mais índices = gravações levemente mais lentas).
Ferramentas e formas seguras de consultar/editar o dicionário
Editar diretamente as tabelas do banco pode ser tentador, mas perigoso. Use ferramentas oficiais ou telas do próprio Protheus sempre que possível.
- Telas de administração do Protheus: permitem visualizar o dicionário e aplicar alterações com consistência.
- Ferramentas de deploy/migração: sincronizam estrutura do banco com o dicionário e aplicam scripts com segurança.
- Backup antes de qualquer alteração: um must-have. Se algo der errado, você precisa restaurar o estado anterior.
Dica prática: sempre faça alterações primeiro em ambiente de homologação. Teste telas, relatórios, integrações e rotinas batch antes de promover para produção.
Boas práticas e armadilhas comuns
Algumas regras simples reduzem bastante os problemas:
- Documente cada alteração no dicionário (o que foi feito, por que e por quem).
- Use nomes lógicos e consistentes para campos e índices — facilita manutenção.
- Acompanhe dependências: se uma rotina usa um campo, a alteração desse campo exige revisão do código.
- Evite remover índices sem análise; isso pode degradar performance.
- Não confie só na tabela física; sempre sincronize com SX2/SX3/SIX.
Armadilhas comuns:
- Alterar tamanho de campo sem checar conteúdos existentes (truncamento).
- Criar muitos índices "para ver se melhora" — índices demais prejudicam gravação.
- Editar diretamente em produção sem testes.
Como diagnosticar problemas relacionados ao dicionário
Quando algo quebra, o fluxo de investigação costuma ser parecido:
- Identifique o erro (ex.: tela que não mostra campo, rotina que dá erro de tipo, busca lenta).
- Verifique se o campo existe fisicamente na tabela (banco) e se está no SX2.
- Cheque o SX3 para confirmar a chave e alias da tabela;
- Analise os índices no SIX para ver se há índice adequado ou conflitos;
- Reproduza em homologação e teste alterações com backup completo.
Exemplo real: uma importação falhando porque um campo numérico foi definido como caractere no SX2 (ou vice-versa). A solução passa por corrigir o tipo no SX2 e, se necessário, converter os dados na tabela.
Migração entre ambientes e versões: o que ficar de olho
Ao migrar Protheus entre ambientes (dev → hom → prod) ou atualizar versão, o dicionário merece atenção:
- Verifique scripts de atualização que alteram dicionário — alguns updates da TOTVS já vêm com mudanças no SX2/SX3/SIX;
- Use ferramentas de comparação entre dicionários para identificar diferenças;
- Planeje janela de testes para que integrações e rotinas se ajustem às mudanças.
Importante: a mesma tabela pode ter pequenas diferenças no dicionário entre versões — algumas rotinas novas podem depender de campos/índices que não existiam antes.
Casos de troubleshooting avançado
Aqui vão três cenários e como agir:
1) Tela não exibe campo novo
- Verifique se o campo foi registrado no SX2 com o mesmo nome lógico que o campo físico;
- Cheque se a rotina que monta a tela lê o dicionário (algumas rotinas legacy usam layouts estáticos);
- Se a rotina é custom, atualize o código ou mapa de campos para considerar o novo campo.
2) Consulta que antes era rápida ficou lenta após inclusão de campo
- Analise o plano de execução (se estiver em SQL) e verifique se existe índice para os filtros;
- Crie ou ajuste índice no SIX somente se testes mostrarem ganho;
- Considere reorganizar índices ou compactar tabelas em bancos que exigem manutenção física.
3) Erro de gravação por tipo incompatível
- Compare o tipo/tamanho do campo na tabela física com o registrado no SX2;
- Corrija a discrepância no SX2 ou converta os dados no banco para o tipo esperado;
- Teste gravação em ambiente seguro antes de aplicar em produção.
Checklist rápido antes de alterar SX2/SX3/SIX
- Tenho backup completo do banco e dicionário?
- Testei em homologação e revirei rotinas dependentes?
- Documentei o motivo da alteração e quem aprova?
- Analisei impacto em performance (mais índices = gravação mais lenta)?
- Tenho rollback plan (script que desfaz a mudança)?
Conclusão: Por que conhecer SX2, SX3 e SIX faz diferença
Entender SX2, SX3 e SIX é mais do que decorar siglas — é compreender como o Protheus estrutura e encontra informação. Quando você conhece essa arquitetura, evita problemas comuns, consegue otimizar consultas e integrações e garante que mudanças sejam feitas com segurança.
Se você está começando, não tenha medo de perguntar ao responsável pelo ambiente ou ao time de infraestrutura antes de tocar no dicionário. E se for desenvolver, sempre teste em homologação, documente cada passo e faça backup. Pequenos cuidados hoje evitam dores de cabeça enormes amanhã.
Quer um resumo rápido? SX2 = campos; SX3 = tabelas/arquivo; SIX = índices. O resto é prática: saber onde cada peça encaixa e agir com processo e cuidado.
