Como indiquei em sua outra pergunta , acho que uma revisão de processo e segurança está em ordem aqui. É um banco de dados auditado, então ninguém (especialmente provedores de serviços terceirizados) devem criar tabelas em seu banco de dados sem seu conhecimento .

O problema que você tem é que, além da nova tabela que está sendo criada, você também precisará ter outra tabela criada para armazenar os registros auditados/alterados, que terá uma estrutura idêntica à tabela original com possivelmente uma hora/data e coluna do usuário. Se um provedor de terceiros estiver criando esta tabela, eles não saberão criar a tabela de auditoria, portanto, mesmo que você pudesse gerar seus gatilhos dinamicamente, eles não funcionariam.

É impossível criar uma única tabela que mantenha todos os registros de alterações para todas as outras tabelas em seu banco de dados porque a estrutura entre as tabelas inevitavelmente difere.

Portanto:faça todas as solicitações de alteração (por exemplo, os provedores desejam criar o TableX, eles enviam uma solicitação de alteração (incluindo o script SQL) explicando o motivo da alteração) para você e/ou sua equipe.

Você executa o SQL em uma cópia de teste de seu banco de dados e usa a mesma estrutura para criar outra tabela para conter os registros modificados.

Você então cria e testa os gatilhos necessários, gera um novo script SQL para criar as duas tabelas e seus gatilhos e executa isso em seu banco de dados ativo. Você dá ao seu provedor permissões para usar a nova tabela e eles vão embora.

Todos estão felizes. Sim, pode demorar um pouco mais, e sim, você terá mais trabalho a fazer, mas é muito menos trabalho do que o necessário para tentar analisar os logs de consulta para recriar registros que já foram alterados/ excluído, ou analise o log binário e mantenha-se atualizado com todas as alterações e modifique seu código quando o formato do arquivo de log for alterado etc etc.