Já todos passámos por isso: um registo de dados já não existe ou foi alterado, mas ninguém quer saber quem o fez. Isto é particularmente irritante quando já não se sabe quais os valores que estavam anteriormente nos campos. Se existirem, uma cópia de segurança pode ajudar nestes casos, mas o restauro de uma cópia de segurança é normalmente bastante moroso.
É muito mais fácil lidar com estes problemas se a alteração do valor de um campo for diretamente registada (ou "rastreada"). Em versões anteriores da FileMaker, isto podia ser realizado através de diálogos de entrada, por exemplo, clicando no botão [OK] e um Script foi chamado para registar o processo. Com as versões mais recentes da FileMaker, tudo isto é possível graças a Ativação do guião tornou-se muito mais fácil. Este artigo mostra como o fazer com um ficheiro de exemplo correspondente.
As vantagens do registo de eventos
Se os eventos e rotinas de campo forem registados de forma consistente nas bases de dados FileMaker, existem vantagens tangíveis durante a operação. Sempre que é feita uma alteração, o evento é registado num registo que pode ser visto como um registo completo ou ligado a outro registo. Base de dados podem ser exibidos. Por exemplo, todos os eventos relacionados com o cliente podem ser exibidos num layout e pode ser obtida uma síntese de todos os eventos que foram executados em relação ao cliente chamado. O Tabela para o registo de eventos contém informações normalizadas, tais como data, nome do utilizador, tabela ou Chave primária para as alterações de campo, os valores reais do campo antes e depois da alteração efectuada. Isto permite outras funções, como a recuperação (anulação ilimitada em qualquer ordem) de dados alterados - talvez remotamente comparável ao "correio de voz visual para dados" ;-)
Vamos ao trabalho: o que é necessário?
O desenvolvimento de um registo de eventos para uma solução FileMaker existente pode ser realizado com recursos geríveis. Em primeiro lugar, é necessária uma nova tabela que contenha todos os campos relevantes para a gestão de eventos. No ficheiro de exemplo, a tabela chama-se "Registo de eventos".
Cada acontecimento registado corresponde a um registo de dados nesta tabela; a chave primária automática é designada por _pk_Ereignis_ID. A chave de referência a que o evento diz respeito é guardada no campo de chave _fk_Fremdschlüssel. Por exemplo, se um campo numa base de dados de clientes for alterado, este campo é preenchido com a chave primária da base de dados de clientes. A chave que se encontra neste campo é introduzida no campo Chave estrangeira escrito.
Para modificações de campo, esta tabela também contém os campos Conteúdo do campo antes e Conteúdo do campo depoisque contêm o conteúdo do campo antes e depois da alteração efectuada.
Dois guiões são suficientes.
Para registar um evento, são agora necessários dois scripts para além da tabela: Um script é utilizado para a entrada pura na tabela Registo de eventos e deve ser chamado com parâmetros de script, e é necessário outro script para registar as alterações de campo, que é chamado através do acionador de script no respetivo campo.
Introduzir um evento
Vejamos primeiro o script de entrada puro [ts.event log], que aceita os seguintes parâmetros de script:
- Chave estrangeira
- Ficheiro
- Origem (guião/campo, etc.)
- Estado (OK, erro)
- Tabela
- Texto
- Tipo de transação
- Tipo de chave externa
- Conteúdo do campo antes
- Conteúdo do campo após
O script em si é estruturado de forma simples, escreve os valores contidos no parâmetro do script primeiro em variáveis e depois num novo registo de dados na tabela do registo de eventos.
Este script pode ser chamado por qualquer outro script que deva fazer entradas no registo de eventos. Na solução de exemplo, foi também efectuado o registo de eventos de campo, que este script também chama.
Script [ts.record_field_event]
O guião ts.record_field_event é definido para cada campo como um acionador de script [OnObjectEnter] e [OnObjectExit]. Pode aceitar um separador de um controlo de separador como um parâmetro de script opcional se o campo estiver localizado numa área de um controlo de separador. Isto é necessário para que o script possa mudar para o separador correto depois de o registo de dados de registo ter sido criado. Controlo do registo no layout de destino.
O script verifica primeiro se a variável de sistema $$ Campo está preenchido ou vazio. Se esta variável de sistema estiver vazia, o utilizador introduziu um campo e o script preenche a variável de sistema $$ Campo com o nome do campo ativo e $$field_content_before com o conteúdo do campo antes da alteração. O script é então encerrado, uma vez que o script não tem de fazer mais nada ao introduzir um campo.
Se a variável de sistema $$ Campo já estiver preenchido, o utilizador pode ter alterado o conteúdo do campo e estar a sair do campo. O script verifica agora se o conteúdo do campo foi alterado e cria um registo de dados no log de eventos se tiver sido feita uma alteração, chamando o subscrito registo de eventos ts.event. Se o campo estiver num controlo de separador e o nome do separador tiver sido fornecido como um parâmetro de script, o script muda agora para o separador especificado, caso contrário mudaria para o controlo de separador predefinido após a entrada. Finalmente, o script elimina novamente as variáveis 1TP4rider, $$ Campo, $$field_content_before e $$field_content_aftere o jogo pode recomeçar do início, porque a variável de sistema $$field está agora novamente vazia.
Atribuir campos com accionadores de script
Na última etapa, os campos desejados devem agora ser dotados de accionadores de script para que a entrada no registo de eventos possa ocorrer quando um campo é alterado. Devem ser configurados dois accionadores de script para cada campo, cada um dos quais chama o mesmo script:
- WithObjectEnter ["ts.field_event_record"; {parameter: "tab"}]
- WithObjectExit ["ts.field_event_record"; {parameter: "tab"}]
O parâmetro de script "Tab" é opcional e só é especificado se o campo estiver localizado num controlo de separador, como no ficheiro de exemplo. É especificado o nome do separador, que é utilizado no script Inspetor no separador [Posição] do Nome deve ser especificado.
Ficheiro de exemplo para registo de valores de campo
No final deste artigo, pode descarregar um ficheiro de amostra para a FileMaker 12, no qual foi realizado o registo de eventos com gravação de valores de campo. Pode utilizar este ficheiro de exemplo como base para a sua própria base de dados ou para transferir as funções para a sua própria solução FileMaker.
Descarregar ficheiro de amostra para FileMaker 12
Como transferir scripts do ficheiro de amostra para a sua solução
Os scripts podem ser facilmente transferidos de uma solução FileMaker para outra através da área de transferência. Basta abrir a caixa de diálogo Gerir guiõesSelecione o script pretendido com o rato e copie-o para a área de transferência utilizando o menu [Editar - Copiar] ou a combinação de teclas [Ctrl/Cmd-C]. Em seguida, abra a mesma caixa de diálogo na solução de destino e simplesmente cole novamente o script copiado anteriormente usando o comando de menu [Editar - Colar].
Para transferir tabelas do ficheiro de amostra para a sua solução
As tabelas podem ser inseridas numa solução existente de várias formas. A forma mais fácil é importar a tabela utilizando o botão [Importar...] na caixa de diálogo Gerir a base de dados. Todas as tabelas a importar da solução de origem podem então ser selecionadas num diálogo subsequente. Este método é, portanto, particularmente adequado se várias tabelas tiverem de ser importadas ao mesmo tempo. Se apenas uma tabela tiver que ser importada, isso também pode ser feito através da área de transferência como um script. Se uma tabela tiver de ser importada juntamente com os seus dados, isso pode ser feito com o comando [Ficheiro > Importar registos > Ficheiro]. Na caixa de diálogo de importação, a tabela de destino Nova mesa deve ser especificado.
Para transferir listas de valores do ficheiro de exemplo para a sua solução
As listas de valores podem ser facilmente importadas de uma solução FileMaker para outra através da área de transferência. Basta abrir a caixa de diálogo em [Ficheiro/Arquivo > Gerir > Listas de valores], selecionar a lista de valores pretendida e clicar em [Importar]. Lista de valores com o rato e copiar a lista de valores para a área de transferência utilizando o menu [Editar - Copiar] ou a combinação de teclas [Ctrl/Cmd-C]. Em seguida, abra a mesma caixa de diálogo na solução de destino e cole a lista de valores copiada anteriormente usando o comando de menu [Editar - Colar].
Como transferir as suas próprias funções do ficheiro de exemplo para a sua solução
Clique no botão [Importar] na caixa de diálogo [Ficheiro > Gerir > Funções personalizadas...] e, em seguida, selecione o ficheiro de amostra. Selecione as funções personalizadas desejadas na caixa de diálogo seguinte e confirme a caixa de diálogo. Tenha em atenção que esta função só está disponível na FileMaker Pro Advanced, mas não na FileMaker Pro.
Markus Schall tem vindo a desenvolver bases de dados personalizadas, interfaces e aplicações empresariais baseadas na Claris FileMaker desde 1994. É um parceiro da Claris, vencedor do Prémio FMM 2011 e criador do Software ERP gFM-Business. É também autor de livros e fundador da M. Schall Publishers.
Foi muito bom, ajudou-nos imenso. Muito obrigado por tudo!