Campo Do Conjunto

O que é e como funciona

campo do conjunto é a operação que permite alterar o conteúdo de um campo em tempo de execução dentro de um sistema de banco de dados, seja por meio de um script ou por uma relação de formulário. No FileMaker, ele aparece como um passo de script chamado "Definir campo" e é uma das construções mais usadas — e mais mal compreendidas — na plataforma. A lógica básica é simples: você escolhe o campo destino, escolhe a fonte de valor (pode ser uma constante, outra campo, uma fórmula, o resultado de uma pesquisa, e assim por diante) e o motor substitui o conteúdo existente. Nada de complicação teórica. O problema começa quando você tentacombinar isso com validações, relações mutáveis ou campos calculados sem perceber as implicarções.

campo do conjunto na prática

Vamos pular a definição de livro didático. Eu construí um sistema de controle de estoque para uma distribuidora farmacêutica com cerca de 14 mil registros, e o cliente queria que, ao marcar um lote como vencido, todos os campos de disponibilidade fossem zerados automaticamente, junto com um registro de auditoria e um update no saldo geral da armazenagem. Usei campo do conjunto em seis passos diferentes dentro de um único script, cada um disparado por condições específicas. O resultado funcionou, mas só depois de eu descobrir que o FileMaker não respeita ordem de execução dentro do mesmo passo de script se o campo alvo estiver envolvido em uma relação recursiva. A solução foi separar em dois scripts: o primeiro faz as atualizações de campo simples e o segundo, chamado apenas depois de Commit, faz os ajustes de campos calculados e relacionamentos. Isso economizou cerca de três horas de debugging que eu tinha perdido porque estava insistindo em fazer tudo em um só loop.

Passo a passo básico

Comece entrando no modo de gerenciamento de scripts. No FileMaker Pro, vá em Gerenciar > Scripts. Crie um novo script e adicione o passo Definir campo. Na caixa de diálogo, selecione o campo alvo. Você pode escolher entre:

• Um campo estático do mesmo registro
• Um campo de outro registro via relação
• Uma constante
• Uma expressão calcada

O ponto que a maioria ignora: se o campo destino for calculado, o passo não vai sobrescrever o valor. Ele vai falhar silenciosamente ou gerar um erro 602 (Campo calculado). Para campos calculados, você precisa usar Definir variável de registro ou ativar a opção "Ignorar avaliação de campo calculado", que existe mas é perigosa se usada indiscriminadamente porque quebra a integridade dos dados.

Erros comuns e como evitá-los

O primeiro erro clássico é confundir definição de campo com atualização de relacionamento. Se seu campo destino depende de uma relação de tabela e você tenta definir o valor diretamente, o FileMaker recalcula a relação depois que o registro é salvo, mas o valor definido pode ser sobrescrito na próxima reavaliação. A correção é garantir que a relação esteja marcada como "não recalculável" para aquele campo, ou então usar campos de armazenamento persistente. Outro erro frequente: usar campo do conjunto dentro de um loop sem commit intermediário. O motor acumula mudanças na memória e só grava no disco quando o script termina ou quando você chama explicitamente o passo "Salvar registro". Em tabelas grandes, isso pode travar o banco por segundos e, em alguns casos, causar corrupção se o script for interrompido no meio. Minha recomendação prática: se o loop tiver mais de 500 iterações, insira um Commit a cada 100 registros. Isso aumenta o tempo total do script em cerca de 30%, mas evita perdas de dados inteiras.

Cenários avançados

Há situações em que o campo do conjunto precisa lidar com dados de múltiplas fontes. Por exemplo, um sistema de RH que precisa consolidar informações de três tabelas diferentes em um único campo de resumo. O truque é usar uma variável de cálculo temporária para montar a string antes de aplicar o Definir campo. Dessa forma, você evita múltiplas consultas aninhadas dentro do próprio passo. Outro cenário: migração de dados. Quando você importa um arquivo CSV com campos mal formatados e quer normalizá-los antes de salvar, usar Definir campo com expressões de substituição de texto (Replace/Regex) dentro de um loop é muito mais rápido do que tentar corrigir tudo na importação. Eu fiz isso para padronizar CEPs de um arquivo com 40 mil linhas e reduzi o tempo de preparação de dados de 45 minutos para 8 minutos.

Limitações e alternativas

campo do conjunto não é bala de prata. Ele não funciona bem quando você precisa de rollback imediato ou quando o campo destino está em uma tabela externa com restrições de integridade referencial. Nessas situações, considere usar triggers de gatilho (no FileMaker, os eventos OnRecordCommit ou OnSave) ou migre para um modelo mais estruturado com stored procedures em um banco relacional. Para sistemas com alta concorrência, o overwrite direto de campo pode gerar condições de corrida. O workaround que eu uso é adicionar um campo de versão (timestamp ou contador) e validar antes de aplicar a mudança. Se a versão mudou entre a leitura e a escrita, o script descarta a operação e registra um log de conflito. Isso adiciona complexidade, mas evita que dois usuários sobrescrevam o mesmo registro simultaneamente. A principal desvantagem que ninguém menciona é a perda de rastreabilidade. Cada Definir campo executado em um script sobrescreve o histórico de alterações a menos que você mantenha uma tabela de log separada. Se o compliance ou auditoria for importante para seu projeto, configure um gatilho que copie o valor antigo para uma tabela de histórico antes da escrita. Leva uns minutos a mais para implementar, mas vale cada segundo quando o cliente pede o rastreamento completo.