RThomas's questions

Estou configurando uma auditoria de banco de dados. Eu gostaria de capturar qualquer alteração DML emitida pelo usuário do banco de dados que não seja a conta de serviço relacionada ao aplicativo.

Resumindo, isso serve para provar aos nossos auditores externos que nenhum usuário está adulterando dados fora do aplicativo.

Este script a seguir configura uma auditoria DML que é global para todos os princípios.

CREATE DATABASE AUDIT SPECIFICATION [OurDatabaseAuditSpec]
FOR SERVER AUDIT [OurAudit]
ADD (DELETE ON OBJECT::[dbo].[SensitiveData] BY [public]),
ADD (INSERT ON OBJECT::[dbo].[SensitiveData] BY [public]),
ADD (UPDATE ON OBJECT::[dbo].[SensitiveData] BY [public])
WITH (STATE = ON)
GO

Como faço para modificar essa especificação de auditoria para capturar tudo, EXCETO o que está sendo feito pela conta de serviço do aplicativo?

Estou limitado a especificar cada princípio individualmente ou posso especificar uma exceção? Lendo o BOL, parece que só posso listar os princípios a serem auditados - não os princípios a serem ignorados.

Descobri esta semana, da maneira mais difícil, que as opções NORECOVERYde restauração do banco de dados KEEP_CDCsão mutuamente exclusivas . Então, isso levanta a questão. Como você faz uma restauração de banco de dados, mantendo o CDC intacto, com backups completos e de log?

Fazendo pesquisas no MSDN, etc. Não consigo encontrar nenhuma documentação sobre como restaurar um banco de dados KEEP_CDCusando qualquer outra opção além de uma única restauração completa do banco de dados com RECOVERYespecificação.

Consegui encontrar uma tentativa que fez os logs completos e subseqüentes sem a keep_cdcopção de esperar até o log final. Só então a tabela foi colocada online com a opção RECOVERYe KEEP_CDC. O resultado foi um esquema CDC corrompido , conforme demonstrado aqui.

Se a intenção é KEEP_CDCrestaurar, você está realmente limitado apenas a um backup completo ou existe um mecanismo semelhante à tentativa acima para mantê-lo intacto durante restaurações de vários arquivos em um servidor diferente do original?

Nossos desenvolvedores têm usado um cursor em um procedimento armazenado para excluir o histórico de senhas antigas. O número de registros a serem excluídos está sendo passado por variável.

DECLARE hist_cursor CURSOR LOCAL FOR
    SELECT history_nr   FROM usr_pwd_hist   WHERE usr_id = @usr_id
    ORDER BY    history_nr ASC

OPEN hist_cursor

WHILE @to_delete > 0
BEGIN
    FETCH NEXT FROM hist_cursor INTO @hist_val

    DELETE FROM usr_pwd_hist WHERE CURRENT OF hist_cursor

    SET @to_delete = @to_delete-1
END

CLOSE hist_cursor; 
DEALLOCATE hist_cursor;

Eu gostaria de substituir isso por uma abordagem baseada em conjunto. Não posso fazer uma instrução superior simples porque o número de registros a serem excluídos é uma variável. Não consigo usar um top com uma variável sem sql dinâmico e por política não permitimos sql dinâmico em produção.

Estou considerando esta abordagem abaixo, mas isso me deixa nervoso, pois sei que a Microsoft está planejando mudar a maneira como ROWCOUNT afeta os resultados de retorno . Ao colocar os destinos de exclusão em uma subconsulta, devo estar de acordo com as versões futuras do SQL, mas ainda estou me perguntando se existe uma maneira melhor de excluir um número variável de registros por ordem cronológica.

SET ROWCOUNT @to_delete;  /* limit records to be deleted */
DELETE FROM usr_pwd_hist WHERE history_nr IN
(
    SELECT history_nr 
    FROM usr_pwd_hist
    WHERE usr_id = @usr_id
    ORDER BY history_nr ASC  
);
SET ROWCOUNT 0;  /* return rowcount to default setting */

Querendo obter todos os registros de um único dia. Portanto, tudo entre 2013-03-05 00:00:00.000e 2013-03-05 23:59:59.999. Estamos ficando sobrepostos no back-end com coisas que aconteceram em 2013-03-06 00:00:00.000.

Então, nos testes eu corro no SSMS:

select cast('2013-03-05 23:59:59.999' as datetime)
select cast('2013-03-05 23:59:59.996' as datetime)
select cast('2013-03-05 23:59:59.994' as datetime)

E pegue:

2013-03-06 00:00:00.000
2013-03-05 23:59:59.997
2013-03-05 23:59:59.993

A parte do milissegundo volta um pouco. No caso da primeira linha, isso realmente importa. Porque não quero 2013-03-06 00:00:00.000 - quero um milissegundo antes da meia-noite.

TSQL declara na documentação que usa segundos fracionários em oposição a .Net datetime que usa milissegundos. Isso parece ser apenas uma diferença de sintaxe, mas se você realmente se preocupa com a precisão de milissegundos no TSQL, é forçado a usá DateTime2-la em geral. A transmissão de datetime2para datetimeainda atrapalha as coisas em alguns milissegundos.

Em c# DateTime.Parse("03/5/2013 23:59:59.999").Millisecondainda retorna 999.

Estou interpretando bem? Se eu me preocupo com a precisão de milissegundos, estou preso datetime2apenas a.

Normalmente, isso seria uma solução fácil, mas, neste caso, estamos usando uma função do sistema Microsoft que recebe datetimecomo parâmetro.

Estamos usando o CDC para capturar as alterações feitas em uma tabela de produção. As linhas alteradas estão sendo exportadas para um data warehouse (informatica). Eu sei que a coluna __$update_mask armazena quais colunas foram atualizadas em um formulário varbinary. Também sei que posso usar uma variedade de funções CDC para descobrir a partir dessa máscara quais eram essas colunas.

Minha pergunta é esta. Alguém pode me definir a lógica dessa máscara para que possamos identificar as colunas que foram trocadas no armazém? Como estamos processando fora do servidor, não temos acesso fácil a essas funções MSSQL CDC. Prefiro apenas quebrar a máscara sozinho no código. O desempenho das funções cdc no final do SQL é problemático para esta solução.

Resumindo, gostaria de identificar manualmente as colunas alteradas no campo __$update_mask.

Atualizar:

Como alternativa, o envio de uma lista legível por humanos de colunas alteradas para o depósito também era aceitável. Descobrimos que isso poderia ser executado com desempenho muito maior do que nossa abordagem original.

A resposta do CLR para esta pergunta abaixo atende a esta alternativa e inclui detalhes de interpretação da máscara para futuros visitantes. No entanto, a resposta aceita usando XML PATH é a mais rápida para o mesmo resultado final.

Estamos fazendo um processo de ETL. Quando tudo estiver dito e feito, há um monte de tabelas que devem ser idênticas. Qual é a maneira mais rápida de verificar se essas tabelas (em dois servidores diferentes) são de fato idênticas. Estou falando de esquema e dados.

Posso fazer um hash na tabela por conta própria, como eu seria capaz de fazer em um arquivo individual ou grupo de arquivos - para comparar um com o outro. Temos comparação de dados do Red-Gate, mas como as tabelas em questão contêm milhões de linhas cada, gostaria de algo com um pouco mais de desempenho.

Uma abordagem que me intriga é esse uso criativo da declaração de união . Mas, eu gostaria de explorar a ideia de hash um pouco mais, se possível.

POSTAR RESPOSTA ATUALIZADA

Para qualquer visitante futuro... aqui está a abordagem exata que acabei tomando. Funcionou tão bem que estamos fazendo isso em todas as tabelas de cada banco de dados. Obrigado às respostas abaixo por me apontarem na direção certa.

CREATE PROCEDURE [dbo].[usp_DatabaseValidation]
    @TableName varchar(50)

AS
BEGIN

    SET NOCOUNT ON;

    -- parameter = if no table name was passed do them all, otherwise just check the one

    -- create a temp table that lists all tables in target database

    CREATE TABLE #ChkSumTargetTables ([fullname] varchar(250), [name] varchar(50), chksum int);
    INSERT INTO #ChkSumTargetTables ([fullname], [name], [chksum])
        SELECT DISTINCT
            '[MyDatabase].[' + S.name + '].['
            + T.name + ']' AS [fullname],
            T.name AS [name],
            0 AS [chksum]
        FROM MyDatabase.sys.tables T
            INNER JOIN MyDatabase.sys.schemas S ON T.schema_id = S.schema_id
        WHERE 
            T.name like IsNull(@TableName,'%');

    -- create a temp table that lists all tables in source database

    CREATE TABLE #ChkSumSourceTables ([fullname] varchar(250), [name] varchar(50), chksum int)
    INSERT INTO #ChkSumSourceTables ([fullname], [name], [chksum])
        SELECT DISTINCT
            '[MyLinkedServer].[MyDatabase].[' + S.name + '].['
            + T.name + ']' AS [fullname],
            T.name AS [name],
            0 AS [chksum]
        FROM [MyLinkedServer].[MyDatabase].sys.tables T
            INNER JOIN [MyLinkedServer].[MyDatabase].sys.schemas S ON 
            T.schema_id = S.schema_id
        WHERE
            T.name like IsNull(@TableName,'%');;

    -- build a dynamic sql statement to populate temp tables with the checksums of each table

    DECLARE @TargetStmt VARCHAR(MAX)
    SELECT  @TargetStmt = COALESCE(@TargetStmt + ';', '')
            + 'UPDATE #ChkSumTargetTables SET [chksum] = (SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM '
            + T.FullName + ') WHERE [name] = ''' + T.Name + ''''
    FROM    #ChkSumTargetTables T

    SELECT  @TargetStmt

    DECLARE @SourceStmt VARCHAR(MAX)
    SELECT  @SourceStmt = COALESCE(@SourceStmt + ';', '')
            + 'UPDATE #ChkSumSourceTables SET [chksum] = (SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM '
            + S.FullName + ') WHERE [name] = ''' + S.Name + ''''
    FROM    #ChkSumSourceTables S

    -- execute dynamic statements - populate temp tables with checksums

    EXEC (@TargetStmt);
    EXEC (@SourceStmt);

    --compare the two databases to find any checksums that are different

    SELECT  TT.FullName AS [TABLES WHOSE CHECKSUM DOES NOT MATCH]
    FROM #ChkSumTargetTables TT
    LEFT JOIN #ChkSumSourceTables ST ON TT.Name = ST.Name
    WHERE IsNull(ST.chksum,0) <> IsNull(TT.chksum,0)

    --drop the temp tables from the tempdb

    DROP TABLE #ChkSumTargetTables;
    DROP TABLE #ChkSumSourceTables;

END

Rastreamento de quem fez a alteração identificada pelo CDC.

Seguindo as linhas do meu hack de data e hora , tentei a mesma abordagem adicionando suser_sname como um novo campo com valor padrão na tabela de controle de alteração do cdc. Mas, isso parece retornar o dono do processo cdc e não o usuário que iniciou a mudança na tabela base. Eu também tentei original_login, mas isso retorna o login da conta do serviço SQL. Novamente, provavelmente associado ao processo cdc e não ao usuário que iniciou a alteração.

Encontrei uma pergunta semelhante no estouro de pilha, mas sem resposta além de rastrear alterações no front-end ou por meio de um gatilho, o que parece anular o propósito de usar o cdc. Eu não iria republicar, mas como o original estava no stackoverflow, pensei em tentar aqui, especialmente se R2 ou 2012 introduziu uma maneira melhor.

Resumindo: como sei quem fez a alteração na captura de dados alterados?

Então, começamos a explorar o uso da captura de dados alterados em um de nossos bancos de dados de produção. Gostaríamos de saber a data e hora de cada alteração. Lendo passo a passo e tutoriais , etc., parece que a abordagem padrão é usar o LSN para se relacionar com a cdc.lsn_time_mappingtabela do sistema. Essa abordagem funciona, mas não é muito direta nem eficiente quando falamos de centenas de milhares de alterações por dia.

Em um ambiente de teste, fiz o seguinte ajuste nas tabelas de controle de alterações. Emiti uma ALTER TABLEinstrução para adicionar uma coluna ao final chamado [__ChangeDateTime]e tornei seu valor padrão GetDate(). A abordagem parece funcionar, o controle de alterações ainda funciona normalmente, as datas e horas estão sendo capturadas. Mas mexer nas tabelas do sistema me deixa um pouco nervoso.

Se este não é um campo do sistema que a Microsoft adicionou desde o início , eles devem ter seus motivos. Como eles optaram pela abordagem LSN para cdc.lsn_time_mapping, estou me preparando para problemas ao criar meu próprio hack dessa maneira?

ATUALIZAR:

Descoberto durante o teste que GetDate() às vezes não é preciso o suficiente para nossas necessidades - várias alterações compartilhando o mesmo tempo. Recomende o uso de sysdatetime() e datetime2 para mover o valor para o nanossegundo. Opção para 2008+ apenas obviamente.

Portanto, tivemos um processo de longa duração causando problemas esta manhã (30 segundos + tempo de execução). Decidimos verificar se a detecção de parâmetros era a culpada. Portanto, reescrevemos o proc e definimos os parâmetros de entrada para variáveis ​​para impedir a detecção de parâmetros. Uma abordagem testada/verdadeira. Bam, o tempo de consulta melhorou (menos de 1 segundo). Ao olhar para o plano de consulta, as melhorias foram encontradas em um índice que o original não estava usando.

Apenas para verificar se não obtivemos um falso positivo, fizemos um dbcc freeproccache no proc original e rodamos novamente para ver se os resultados aprimorados seriam os mesmos. Mas, para nossa surpresa, o proc original ainda rodava devagar. Tentamos novamente com um WITH RECOMPILE, ainda lento (tentamos uma recompilação na chamada para o proc e dentro do próprio proc). Até reiniciamos o servidor (caixa de desenvolvimento obviamente).

Então, minha pergunta é esta... como o sniffing de parâmetro pode ser o culpado quando obtemos a mesma consulta lenta em um cache de plano vazio... não deveria haver nenhum parâmetro para snif???

Em vez disso, estamos sendo afetados pelas estatísticas da tabela não relacionadas ao cache do plano. E se assim for, por que definir os parâmetros de entrada para variáveis ​​ajudaria?

Em testes adicionais, também descobrimos que a inserção de OPTION (OPTIMIZE FOR UNKNOWN) nas partes internas do proc DID obteve o plano aprimorado esperado.

Então, alguns de vocês mais espertos do que eu, podem dar algumas pistas sobre o que está acontecendo nos bastidores para produzir esse tipo de resultado?

Em outra observação, o plano lento também é abortado antecipadamente com razão GoodEnoughPlanFound, enquanto o plano rápido não tem motivo de interrupção antecipada no plano real.

Resumindo

• Criando variáveis ​​a partir de parâmetros de entrada (1 seg)
• com recompilação (30+ seg)
• dbcc freeproccache (mais de 30 segundos)
• OPÇÃO (OPTIMIZE FOR UKNOWN) (1 seg)

ATUALIZAR:

Veja o plano de execução lenta aqui: https://www.dropbox.com/s/cmx2lrsea8q8mr6/plan_slow.xml

Veja o plano de execução rápida aqui: https://www.dropbox.com/s/b28x6a01w7dxsed/plan_fast.xml

Nota: tabela, esquema, nomes de objetos alterados por motivos de segurança.

Estou tentando obter o guid de linha de todos os perdedores do conflito de replicação de mesclagem listados em meu visualizador de conflitos. O bug que permitia que os conflitos ocorressem foi identificado e resolvido, mas agora preciso remover os perdedores de conflito dos assinantes para que eles parem de tentar carregar as linhas em conflito a cada nova sincronização.

Posso passar por cada conflito individualmente para obter o rowguid, mas existem alguns milhares deles. Portanto, certamente deve haver uma consulta que eu possa escrever para obter esses dados de uma só vez.

Qualquer pessoa tem experiência em consultar as tabelas do sistema de replicação de mesclagem para informações de conflito ou sabe qual tabela do sistema devo procurar. Não estou encontrando muita ajuda nas interwebs.

Existe uma maneira (o hack do registro é aceitável) de remover as opções dos menus de contexto no SSMS?

Especificamente, gostaria de remover a opção de exclusão do menu de contexto quando você clica com o botão direito do mouse em uma publicação de replicação de mesclagem. Se realmente quisermos deletá-lo, faremos isso via tsql.

E sim, há uma história trágica motivando esta pergunta.

Pergunta hipotética - Para ajudar no planejamento de cenários.

Digamos que eu tenha uma publicação de mesclagem 2008 R2 com 5 assinantes ativos. A publicação é excluída e todas as assinaturas são removidas. Mais ou menos uma semana se passa e os dados são continuamente adicionados ou atualizados nos bancos de dados locais que costumavam ser assinantes.

Uma semana depois, uma nova publicação é criada no banco de dados original e as 5 caixas locais recebem novas assinaturas. O que acontece com os dados que foram adicionados localmente durante a semana em que não existia assinatura?

• R: Ele é enviado para o editor assim que a nova assinatura é criada?

• B: Os dados da semana off-line são excluídos?

• C: Os dados da semana off-line são ignorados pelo editor (e, portanto, por outros assinantes)?

• D: Algo mais acontece

Se C? Existe uma maneira de marcar esses registros para replicação para que possam ser levados ao editor e, finalmente, aos outros assinantes?

Eu tenho um esquema de replicação que foi criado há vários meses. Desde então, o esquema teve uma variedade de mudanças. Todas as assinaturas existentes foram atualizadas à medida que essas alterações foram feitas, pois a publicação também está configurada para enviar alterações de esquema.

Recentemente, no entanto, ao tentar adicionar uma nova assinatura, o instantâneo inicial falha ao ser aplicado. A causa do erro é que duas exibições diferentes falham ao serem aplicadas, pois as tabelas nas quais elas dependem ainda não foram criadas pelo instantâneo.

Sei que posso especificar a ordem de processamento dos artigos por meio do procedimento armazenado sp_changemergearticle. Mas, pelo que entendi... a configuração da ordem de processamento aqui é para especificar a ordem na qual as alterações de dados são aplicadas aos assinantes durante a sincronização. Existe uma maneira de especificar a ordem em que os artigos são aplicados quando uma nova assinatura é inicializada? Ele usa a mesma configuração?

Achei que gerar um novo instantâneo faria com que o mecanismo descobrisse a ordem correta, mas no caso da minha publicação atual, isso não aconteceu. A nova assinatura falha ao aplicar o instantâneo mesmo depois de gerar um novo instantâneo. Ele me diz o script exato que falha e ao aplicar manualmente é óbvio que está falhando porque uma tabela necessária para a exibição ainda não existe.

Qual o melhor jeito de consertar isso? A configuração da ordem de processamento de um artigo afeta a ordem do esquema, bem como a ordem dos dados, ou preciso procurar outro lugar para definir a ordem em que os artigos são criados em novas assinaturas?

Pelo que posso dizer, a configuração da ordem de processamento não tem nenhum efeito na ordem em que o instantâneo aplica seus artigos durante a inicialização. Principalmente porque atualmente todos os meus artigos têm valor 0 para sua ordem de processamento. Então, isso é algo que posso controlar ou estou à mercê do processo de geração de instantâneos?

Meu esquema de replicação de mesclagem começou a falhar repentinamente. Ao tentar sincronizar ele reclama que existe um objeto inválido. 'dbo.minhafunção'. A função existia, mas foi removida. Havia apenas uma referência a ela de uma função com valor de tabela e também foi atualizada. Gerei um novo instantâneo, mas ele continua reclamando que o objeto é inválido e não será sincronizado no assinante.

Em algum lugar dentro da replicação, ele ainda está procurando por essa função. Como faço para encontrá-lo e removê-lo - quando não está mais lá.

Eu até examinei os arquivos no instantâneo e não consigo encontrar nenhum lugar que esteja sendo referenciado.

Meu editor é SQL 2008 R2 - todos os meus assinantes são SQL 2008 Express

Apenas curioso, por BOL

Tempo de espera (ms/s) é o tempo de espera em milissegundos para todas as tarefas que aguardam um ou mais recursos na categoria desde a última atualização.

Average Waiter Count é o número de tarefas em espera.

É uma coincidência que no meu servidor Average Waiter Count seja sempre Wait Time / 1000 arredondado para o décimo mais próximo? Existe um link aqui que faz isso? Vou ficar envergonhado quando a resposta for extremamente lógica, mas por algum motivo me escapa no momento?

ou seja, aqui estão os valores de amostra dos últimos 15 minutos para a trava, mas outras categorias de espera são as mesmas (quando existem valores) - eu notei isso por algum tempo (muito mais do que os últimos 15 minutos), mas nunca despertou meu interesse o suficiente investigar até agora.

Wait Time         Average Waiter Count
______________________________________
576               0.6
1403              1.4
1856              1.9
1233              1.2
1365              1.4

Parece-me que, como o tempo de espera é uma contagem cumulativa e os garçons são uma média, os números não devem seguir uma proporção tão estreita quanto parecem.

Temos um servidor de banco de dados muito ativo com uma coleção eclética de aplicativos em execução. Dois dos mais ocupados são um banco de dados Laserfiche que faz digitalização de documentos e processamento de fluxo de trabalho durante todo o dia (média de cerca de 2800 solicitações em lote / segundo) e um aplicativo de servidor blackberry que roteia e-mails. Existem também cerca de 25 outros bancos de dados de pequenos aplicativos.

Como somos uma agência governamental, recebemos apenas o orçamento para uma única licença de servidor de banco de dados.

Recentemente, recebemos uma SAN para resolver problemas de contenção de disco.

Portanto, atualmente temos o TempDB em execução em seu próprio disco (raid 1 par de espelhos) e movemos os logs de transação e os arquivos de dados para a SAN. Os logs de transação foram colocados em um local lógico e os arquivos de dados em outro. Fisicamente, é o mesmo array, mas é um array composto por 14 eixos totais (discos) em uma configuração raid 1+0.

Um SAN bastante robusto - e as coisas estão funcionando muito melhor. Comprimentos de fila cortados pela metade.

Só hoje também nos foi dada outra opção. Também poderíamos ter uma matriz de 4 discos se precisássemos dela atualmente no servidor de arquivos. Eu sei que ter MDF e LDF em duas matrizes separadas é geralmente recomendado, mas a única maneira de fazer isso em nossa situação seria mover dados ou logs de transação da SAN para a matriz de 4 discos configurada como Raid 5. Lembre-se de que eles são atualmente em volumes lógicos separados, mas compartilhando o mesmo array físico.

Atirando do quadril, sinto que ter os MDFs e LDFs juntos em uma matriz de raid 1 + 0 de 14 fusos é provavelmente tão bom quanto tê-los separados com um em uma matriz de raid 5 de 4 fusos. Mas eu não estaria aqui perguntando se sou um especialista em lógica de disco. Ambas as opções estão usando discos SAS de 15k basicamente idênticos - ou seja, cada eixo é basicamente idêntico.

Então, em essência, a questão é. Ter MDF / LDF em um único array de 14 eixos configurado como raid 1 + 0 será melhorado por qualquer margem significativa (ou de todo) movendo dados ou log para seu próprio array de 4 eixos raid 5?

Pensamentos?

INFORMAÇÕES ATUALIZADAS:

Também observarei que atualmente o comprimento médio da fila no volume de log permanece bastante consistente em torno de 0,55. O comprimento médio da fila no volume de dados raramente é superior a 0,01 (geralmente 0,00)

sys.dm_io_virtual_file_stats RESULTADO DA CONSULTA:

<table>
 <tr>
  <td>database
  id</td>
  <td>Volume</td>
  <td>io_stall_read_ms</td>
  <td>num_of_reads</td>
  <td>avg_read_stall_ms</td>
  <td>io_stall_write_ms</td>
  <td>num_of_writes</td>
  <td>avg_write_stall_ms</td>
  <td>io_stalls</td>
  <td>total_io</td>
  <td>avg_io_stall_ms</td>
 </tr>
 <tr>
  <td>25</td>
  <td>h</td>
  <td>175086</td>
  <td>1411</td>
  <td>124</td>
  <td>69</td>
  <td>41</td>
  <td>1.6</td>
  <td>175155</td>
  <td>1452</td>
  <td>120.5</td>
 </tr>
 <tr>
  <td>16</td>
  <td>h</td>
  <td>54691</td>
  <td>748</td>
  <td>73</td>
  <td>34</td>
  <td>23</td>
  <td>1.4</td>
  <td>54725</td>
  <td>771</td>
  <td>70.9</td>
 </tr>
 <tr>
  <td>41</td>
  <td>h</td>
  <td>192255</td>
  <td>982</td>
  <td>195.6</td>
  <td>5232</td>
  <td>2142</td>
  <td>2.4</td>
  <td>197487</td>
  <td>3124</td>
  <td>63.2</td>
 </tr>
 <tr>
  <td>24</td>
  <td>h</td>
  <td>8616</td>
  <td>178</td>
  <td>48.1</td>
  <td>55</td>
  <td>22</td>
  <td>2.4</td>
  <td>8671</td>
  <td>200</td>
  <td>43.1</td>
 </tr>
 <tr>
  <td>29</td>
  <td>h</td>
  <td>54617</td>
  <td>1247</td>
  <td>43.8</td>
  <td>71</td>
  <td>41</td>
  <td>1.7</td>
  <td>54688</td>
  <td>1288</td>
  <td>42.4</td>
 </tr>
 <tr>
  <td>40</td>
  <td>h</td>
  <td>132664</td>
  <td>3158</td>
  <td>42</td>
  <td>184</td>
  <td>85</td>
  <td>2.1</td>
  <td>132848</td>
  <td>3243</td>
  <td>41</td>
 </tr>
 <tr>
  <td>15</td>
  <td>h</td>
  <td>26556</td>
  <td>763</td>
  <td>34.8</td>
  <td>33</td>
  <td>23</td>
  <td>1.4</td>
  <td>26589</td>
  <td>786</td>
  <td>33.8</td>
 </tr>
 <tr>
  <td>37</td>
  <td>h</td>
  <td>6943152</td>
  <td>500214</td>
  <td>13.9</td>
  <td>310706380</td>
  <td>9083273</td>
  <td>34.2</td>
  <td>317649532</td>
  <td>9583487</td>
  <td>33.1</td>
 </tr>
 <tr>
  <td>32</td>
  <td>h</td>
  <td>14832</td>
  <td>426</td>
  <td>34.7</td>
  <td>42</td>
  <td>38</td>
  <td>1.1</td>
  <td>14874</td>
  <td>464</td>
  <td>32</td>
 </tr>
 <tr>
  <td>43</td>
  <td>h</td>
  <td>46937</td>
  <td>947</td>
  <td>49.5</td>
  <td>1203</td>
  <td>844</td>
  <td>1.4</td>
  <td>48140</td>
  <td>1791</td>
  <td>26.9</td>
 </tr>
 <tr>
  <td>17</td>
  <td>h</td>
  <td>23166</td>
  <td>786</td>
  <td>29.4</td>
  <td>260</td>
  <td>125</td>
  <td>2.1</td>
  <td>23426</td>
  <td>911</td>
  <td>25.7</td>
 </tr>
 <tr>
  <td>44</td>
  <td>h</td>
  <td>65563</td>
  <td>2968</td>
  <td>22.1</td>
  <td>451</td>
  <td>334</td>
  <td>1.3</td>
  <td>66014</td>
  <td>3302</td>
  <td>20</td>
 </tr>
 <tr>
  <td>27</td>
  <td>h</td>
  <td>73622</td>
  <td>3325</td>
  <td>22.1</td>
  <td>547</td>
  <td>483</td>
  <td>1.1</td>
  <td>74169</td>
  <td>3808</td>
  <td>19.5</td>
 </tr>
 <tr>
  <td>31</td>
  <td>h</td>
  <td>19557</td>
  <td>978</td>
  <td>20</td>
  <td>218</td>
  <td>128</td>
  <td>1.7</td>
  <td>19775</td>
  <td>1106</td>
  <td>17.9</td>
 </tr>
 <tr>
  <td>13</td>
  <td>h</td>
  <td>5238308</td>
  <td>176396</td>
  <td>29.7</td>
  <td>70537264</td>
  <td>4109175</td>
  <td>17.2</td>
  <td>75775572</td>
  <td>4285571</td>
  <td>17.7</td>
 </tr>
 <tr>
  <td>26</td>
  <td>h</td>
  <td>849303</td>
  <td>57475</td>
  <td>14.8</td>
  <td>496337</td>
  <td>19098</td>
  <td>26</td>
  <td>1345640</td>
  <td>76573</td>
  <td>17.6</td>
 </tr>
 <tr>
  <td>28</td>
  <td>h</td>
  <td>12707</td>
  <td>799</td>
  <td>15.9</td>
  <td>103</td>
  <td>62</td>
  <td>1.6</td>
  <td>12810</td>
  <td>861</td>
  <td>14.9</td>
 </tr>
 <tr>
  <td>42</td>
  <td>h</td>
  <td>28630</td>
  <td>1233</td>
  <td>23.2</td>
  <td>1139</td>
  <td>883</td>
  <td>1.3</td>
  <td>29769</td>
  <td>2116</td>
  <td>14.1</td>
 </tr>
 <tr>
  <td>14</td>
  <td>h</td>
  <td>91425</td>
  <td>5480</td>
  <td>16.7</td>
  <td>3762</td>
  <td>2470</td>
  <td>1.5</td>
  <td>95187</td>
  <td>7950</td>
  <td>12</td>
 </tr>
 <tr>
  <td>35</td>
  <td>h</td>
  <td>8253</td>
  <td>546</td>
  <td>15.1</td>
  <td>193</td>
  <td>174</td>
  <td>1.1</td>
  <td>8446</td>
  <td>720</td>
  <td>11.7</td>
 </tr>
 <tr>
  <td>12</td>
  <td>h</td>
  <td>33008</td>
  <td>1852</td>
  <td>17.8</td>
  <td>2179</td>
  <td>1335</td>
  <td>1.6</td>
  <td>35187</td>
  <td>3187</td>
  <td>11</td>
 </tr>
 <tr>
  <td>36</td>
  <td>h</td>
  <td>4322</td>
  <td>470</td>
  <td>9.2</td>
  <td>150</td>
  <td>119</td>
  <td>1.3</td>
  <td>4472</td>
  <td>589</td>
  <td>7.6</td>
 </tr>
 <tr>
  <td>6</td>
  <td>h</td>
  <td>537</td>
  <td>61</td>
  <td>8.7</td>
  <td>21</td>
  <td>22</td>
  <td>0.9</td>
  <td>558</td>
  <td>83</td>
  <td>6.6</td>
 </tr>
 <tr>
  <td>33</td>
  <td>h</td>
  <td>4172</td>
  <td>585</td>
  <td>7.1</td>
  <td>63</td>
  <td>59</td>
  <td>1.1</td>
  <td>4235</td>
  <td>644</td>
  <td>6.6</td>
 </tr>
 <tr>
  <td>30</td>
  <td>h</td>
  <td>633</td>
  <td>71</td>
  <td>8.8</td>
  <td>57</td>
  <td>38</td>
  <td>1.5</td>
  <td>690</td>
  <td>109</td>
  <td>6.3</td>
 </tr>
 <tr>
  <td>10</td>
  <td>h</td>
  <td>479</td>
  <td>65</td>
  <td>7.3</td>
  <td>63</td>
  <td>22</td>
  <td>2.7</td>
  <td>542</td>
  <td>87</td>
  <td>6.2</td>
 </tr>
 <tr>
  <td>38</td>
  <td>h</td>
  <td>635</td>
  <td>70</td>
  <td>8.9</td>
  <td>54</td>
  <td>40</td>
  <td>1.3</td>
  <td>689</td>
  <td>110</td>
  <td>6.2</td>
 </tr>
 <tr>
  <td>19</td>
  <td>h</td>
  <td>867</td>
  <td>125</td>
  <td>6.9</td>
  <td>133</td>
  <td>40</td>
  <td>3.2</td>
  <td>1000</td>
  <td>165</td>
  <td>6</td>
 </tr>
 <tr>
  <td>20</td>
  <td>h</td>
  <td>2157</td>
  <td>342</td>
  <td>6.3</td>
  <td>107</td>
  <td>37</td>
  <td>2.8</td>
  <td>2264</td>
  <td>379</td>
  <td>6</td>
 </tr>
 <tr>
  <td>18</td>
  <td>h</td>
  <td>655</td>
  <td>84</td>
  <td>7.7</td>
  <td>109</td>
  <td>44</td>
  <td>2.4</td>
  <td>764</td>
  <td>128</td>
  <td>5.9</td>
 </tr>
 <tr>
  <td>9</td>
  <td>h</td>
  <td>22017</td>
  <td>1269</td>
  <td>17.3</td>
  <td>12187</td>
  <td>4510</td>
  <td>2.7</td>
  <td>34204</td>
  <td>5779</td>
  <td>5.9</td>
 </tr>
 <tr>
  <td>11</td>
  <td>h</td>
  <td>1641</td>
  <td>226</td>
  <td>7.2</td>
  <td>158</td>
  <td>94</td>
  <td>1.7</td>
  <td>1799</td>
  <td>320</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>7</td>
  <td>h</td>
  <td>556</td>
  <td>66</td>
  <td>8.3</td>
  <td>40</td>
  <td>40</td>
  <td>1</td>
  <td>596</td>
  <td>106</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>20</td>
  <td>t</td>
  <td>639</td>
  <td>90</td>
  <td>7</td>
  <td>118</td>
  <td>43</td>
  <td>2.7</td>
  <td>757</td>
  <td>133</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>24</td>
  <td>t</td>
  <td>1031</td>
  <td>167</td>
  <td>6.1</td>
  <td>67</td>
  <td>29</td>
  <td>2.2</td>
  <td>1098</td>
  <td>196</td>
  <td>5.6</td>
 </tr>
 <tr>
  <td>25</td>
  <td>t</td>
  <td>1269</td>
  <td>210</td>
  <td>6</td>
  <td>111</td>
  <td>47</td>
  <td>2.3</td>
  <td>1380</td>
  <td>257</td>
  <td>5.3</td>
 </tr>
 <tr>
  <td>29</td>
  <td>t</td>
  <td>680</td>
  <td>94</td>
  <td>7.2</td>
  <td>113</td>
  <td>54</td>
  <td>2.1</td>
  <td>793</td>
  <td>148</td>
  <td>5.3</td>
 </tr>
 <tr>
  <td>30</td>
  <td>t</td>
  <td>233</td>
  <td>25</td>
  <td>9</td>
  <td>145</td>
  <td>47</td>
  <td>3</td>
  <td>378</td>
  <td>72</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>13</td>
  <td>t</td>
  <td>11947937</td>
  <td>55092</td>
  <td>216.9</td>
  <td>163346886</td>
  <td>33789532</td>
  <td>4.8</td>
  <td>175294823</td>
  <td>33844624</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>15</td>
  <td>t</td>
  <td>693</td>
  <td>119</td>
  <td>5.8</td>
  <td>82</td>
  <td>29</td>
  <td>2.7</td>
  <td>775</td>
  <td>148</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>16</td>
  <td>t</td>
  <td>731</td>
  <td>119</td>
  <td>6.1</td>
  <td>48</td>
  <td>29</td>
  <td>1.6</td>
  <td>779</td>
  <td>148</td>
  <td>5.2</td>
 </tr>
 <tr>
  <td>29</td>
  <td>h</td>
  <td>176</td>
  <td>34</td>
  <td>5</td>
  <td>1</td>
  <td>1</td>
  <td>0.5</td>
  <td>177</td>
  <td>35</td>
  <td>4.9</td>
 </tr>
 <tr>
  <td>18</td>
  <td>t</td>
  <td>305</td>
  <td>44</td>
  <td>6.8</td>
  <td>165</td>
  <td>52</td>
  <td>3.1</td>
  <td>470</td>
  <td>96</td>
  <td>4.8</td>
 </tr>
 <tr>
  <td>5</td>
  <td>h</td>
  <td>500</td>
  <td>75</td>
  <td>6.6</td>
  <td>60</td>
  <td>40</td>
  <td>1.5</td>
  <td>560</td>
  <td>115</td>
  <td>4.8</td>
 </tr>
 <tr>
  <td>8</td>
  <td>t</td>
  <td>462</td>
  <td>74</td>
  <td>6.2</td>
  <td>118</td>
  <td>48</td>
  <td>2.4</td>
  <td>580</td>
  <td>122</td>
  <td>4.7</td>
 </tr>
 <tr>
  <td>5</td>
  <td>t</td>
  <td>294</td>
  <td>33</td>
  <td>8.6</td>
  <td>80</td>
  <td>47</td>
  <td>1.7</td>
  <td>374</td>
  <td>80</td>
  <td>4.6</td>
 </tr>
 <tr>
  <td>3</td>
  <td>h</td>
  <td>520</td>
  <td>109</td>
  <td>4.7</td>
  <td>3</td>
  <td>4</td>
  <td>0.6</td>
  <td>523</td>
  <td>113</td>
  <td>4.6</td>
 </tr>
 <tr>
  <td>39</td>
  <td>h</td>
  <td>394</td>
  <td>62</td>
  <td>6.3</td>
  <td>77</td>
  <td>40</td>
  <td>1.9</td>
  <td>471</td>
  <td>102</td>
  <td>4.6</td>
 </tr>
 <tr>
  <td>39</td>
  <td>t</td>
  <td>124</td>
  <td>16</td>
  <td>7.3</td>
  <td>165</td>
  <td>47</td>
  <td>3.4</td>
  <td>289</td>
  <td>63</td>
  <td>4.5</td>
 </tr>
 <tr>
  <td>8</td>
  <td>h</td>
  <td>459</td>
  <td>78</td>
  <td>5.8</td>
  <td>93</td>
  <td>43</td>
  <td>2.1</td>
  <td>552</td>
  <td>121</td>
  <td>4.5</td>
 </tr>
 <tr>
  <td>41</td>
  <td>t</td>
  <td>8295</td>
  <td>470</td>
  <td>17.6</td>
  <td>4035</td>
  <td>2359</td>
  <td>1.7</td>
  <td>12330</td>
  <td>2829</td>
  <td>4.4</td>
 </tr>
 <tr>
  <td>31</td>
  <td>t</td>
  <td>637</td>
  <td>91</td>
  <td>6.9</td>
  <td>170</td>
  <td>95</td>
  <td>1.8</td>
  <td>807</td>
  <td>186</td>
  <td>4.3</td>
 </tr>
 <tr>
  <td>7</td>
  <td>t</td>
  <td>242</td>
  <td>29</td>
  <td>8.1</td>
  <td>80</td>
  <td>47</td>
  <td>1.7</td>
  <td>322</td>
  <td>76</td>
  <td>4.2</td>
 </tr>
 <tr>
  <td>22</td>
  <td>h</td>
  <td>298</td>
  <td>80</td>
  <td>3.7</td>
  <td>0</td>
  <td>1</td>
  <td>0</td>
  <td>298</td>
  <td>81</td>
  <td>3.6</td>
 </tr>
 <tr>
  <td>38</td>
  <td>t</td>
  <td>139</td>
  <td>22</td>
  <td>6</td>
  <td>115</td>
  <td>47</td>
  <td>2.4</td>
  <td>254</td>
  <td>69</td>
  <td>3.6</td>
 </tr>
 <tr>
  <td>40</td>
  <td>t</td>
  <td>1016</td>
  <td>159</td>
  <td>6.4</td>
  <td>388</td>
  <td>236</td>
  <td>1.6</td>
  <td>1404</td>
  <td>395</td>
  <td>3.5</td>
 </tr>
 <tr>
  <td>22</td>
  <td>t</td>
  <td>76</td>
  <td>18</td>
  <td>4</td>
  <td>7</td>
  <td>5</td>
  <td>1.2</td>
  <td>83</td>
  <td>23</td>
  <td>3.5</td>
 </tr>
 <tr>
  <td>44</td>
  <td>t</td>
  <td>873</td>
  <td>133</td>
  <td>6.5</td>
  <td>479</td>
  <td>263</td>
  <td>1.8</td>
  <td>1352</td>
  <td>396</td>
  <td>3.4</td>
 </tr>
 <tr>
  <td>4</td>
  <td>h</td>
  <td>10565</td>
  <td>2057</td>
  <td>5.1</td>
  <td>2840</td>
  <td>2061</td>
  <td>1.4</td>
  <td>13405</td>
  <td>4118</td>
  <td>3.3</td>
 </tr>
 <tr>
  <td>32</td>
  <td>t</td>
  <td>94</td>
  <td>18</td>
  <td>4.9</td>
  <td>72</td>
  <td>33</td>
  <td>2.1</td>
  <td>166</td>
  <td>51</td>
  <td>3.2</td>
 </tr>
 <tr>
  <td>19</td>
  <td>t</td>
  <td>116</td>
  <td>16</td>
  <td>6.8</td>
  <td>116</td>
  <td>60</td>
  <td>1.9</td>
  <td>232</td>
  <td>76</td>
  <td>3</td>
 </tr>
 <tr>
  <td>11</td>
  <td>t</td>
  <td>144</td>
  <td>18</td>
  <td>7.6</td>
  <td>181</td>
  <td>91</td>
  <td>2</td>
  <td>325</td>
  <td>109</td>
  <td>3</td>
 </tr>
 <tr>
  <td>10</td>
  <td>t</td>
  <td>69</td>
  <td>12</td>
  <td>5.3</td>
  <td>48</td>
  <td>29</td>
  <td>1.6</td>
  <td>117</td>
  <td>41</td>
  <td>2.8</td>
 </tr>
 <tr>
  <td>6</td>
  <td>t</td>
  <td>69</td>
  <td>11</td>
  <td>5.8</td>
  <td>40</td>
  <td>29</td>
  <td>1.3</td>
  <td>109</td>
  <td>40</td>
  <td>2.7</td>
 </tr>
 <tr>
  <td>1</td>
  <td>h</td>
  <td>941</td>
  <td>181</td>
  <td>5.2</td>
  <td>368</td>
  <td>356</td>
  <td>1</td>
  <td>1309</td>
  <td>537</td>
  <td>2.4</td>
 </tr>
 <tr>
  <td>9</td>
  <td>t</td>
  <td>5034</td>
  <td>394</td>
  <td>12.7</td>
  <td>9584</td>
  <td>5599</td>
  <td>1.7</td>
  <td>14618</td>
  <td>5993</td>
  <td>2.4</td>
 </tr>
 <tr>
  <td>17</td>
  <td>t</td>
  <td>1335</td>
  <td>213</td>
  <td>6.2</td>
  <td>1293</td>
  <td>1119</td>
  <td>1.2</td>
  <td>2628</td>
  <td>1332</td>
  <td>2</td>
 </tr>
 <tr>
  <td>3</td>
  <td>h</td>
  <td>21</td>
  <td>6</td>
  <td>3</td>
  <td>15</td>
  <td>13</td>
  <td>1.1</td>
  <td>36</td>
  <td>19</td>
  <td>1.8</td>
 </tr>
 <tr>
  <td>34</td>
  <td>h</td>
  <td>1140</td>
  <td>132</td>
  <td>8.6</td>
  <td>4146</td>
  <td>2921</td>
  <td>1.4</td>
  <td>5286</td>
  <td>3053</td>
  <td>1.7</td>
 </tr>
 <tr>
  <td>14</td>
  <td>t</td>
  <td>714</td>
  <td>111</td>
  <td>6.4</td>
  <td>10175</td>
  <td>6589</td>
  <td>1.5</td>
  <td>10889</td>
  <td>6700</td>
  <td>1.6</td>
 </tr>
 <tr>
  <td>42</td>
  <td>t</td>
  <td>949</td>
  <td>139</td>
  <td>6.8</td>
  <td>3420</td>
  <td>2671</td>
  <td>1.3</td>
  <td>4369</td>
  <td>2810</td>
  <td>1.6</td>
 </tr>
 <tr>
  <td>37</td>
  <td>t</td>
  <td>4006</td>
  <td>489</td>
  <td>8.2</td>
  <td>15548682</td>
  <td>9892846</td>
  <td>1.6</td>
  <td>15552688</td>
  <td>9893335</td>
  <td>1.6</td>
 </tr>
 <tr>
  <td>2</td>
  <td>f</td>
  <td>164348</td>
  <td>106669</td>
  <td>1.5</td>
  <td>178498</td>
  <td>121970</td>
  <td>1.5</td>
  <td>342846</td>
  <td>228639</td>
  <td>1.5</td>
 </tr>
 <tr>
  <td>28</td>
  <td>t</td>
  <td>1305</td>
  <td>194</td>
  <td>6.7</td>
  <td>7006</td>
  <td>5797</td>
  <td>1.2</td>
  <td>8311</td>
  <td>5991</td>
  <td>1.4</td>
 </tr>
 <tr>
  <td>45</td>
  <td>h</td>
  <td>123</td>
  <td>93</td>
  <td>1.3</td>
  <td>510</td>
  <td>373</td>
  <td>1.4</td>
  <td>633</td>
  <td>466</td>
  <td>1.4</td>
 </tr>
 <tr>
  <td>43</td>
  <td>t</td>
  <td>1243</td>
  <td>130</td>
  <td>9.5</td>
  <td>13330</td>
  <td>10836</td>
  <td>1.2</td>
  <td>14573</td>
  <td>10966</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>35</td>
  <td>t</td>
  <td>329</td>
  <td>47</td>
  <td>6.9</td>
  <td>25471</td>
  <td>19582</td>
  <td>1.3</td>
  <td>25800</td>
  <td>19629</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>27</td>
  <td>t</td>
  <td>1866</td>
  <td>294</td>
  <td>6.3</td>
  <td>12196</td>
  <td>10243</td>
  <td>1.2</td>
  <td>14062</td>
  <td>10537</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>12</td>
  <td>t</td>
  <td>13789</td>
  <td>2852</td>
  <td>4.8</td>
  <td>28818</td>
  <td>29040</td>
  <td>1</td>
  <td>42607</td>
  <td>31892</td>
  <td>1.3</td>
 </tr>
 <tr>
  <td>4</td>
  <td>t</td>
  <td>511</td>
  <td>67</td>
  <td>7.5</td>
  <td>158330</td>
  <td>130742</td>
  <td>1.2</td>
  <td>158841</td>
  <td>130809</td>
  <td>1.2</td>
 </tr>
 <tr>
  <td>34</td>
  <td>t</td>
  <td>99</td>
  <td>13</td>
  <td>7.1</td>
  <td>134764</td>
  <td>112984</td>
  <td>1.2</td>
  <td>134863</td>
  <td>112997</td>
  <td>1.2</td>
 </tr>
 <tr>
  <td>2</td>
  <td>f</td>
  <td>23</td>
  <td>147</td>
  <td>0.2</td>
  <td>17980</td>
  <td>16879</td>
  <td>1.1</td>
  <td>18003</td>
  <td>17026</td>
  <td>1.1</td>
 </tr>
 <tr>
  <td>1</td>
  <td>h</td>
  <td>54</td>
  <td>10</td>
  <td>4.9</td>
  <td>1845</td>
  <td>1761</td>
  <td>1</td>
  <td>1899</td>
  <td>1771</td>
  <td>1.1</td>
 </tr>
 <tr>
  <td>33</td>
  <td>t</td>
  <td>220</td>
  <td>33</td>
  <td>6.5</td>
  <td>746</td>
  <td>980</td>
  <td>0.8</td>
  <td>966</td>
  <td>1013</td>
  <td>1</td>
 </tr>
 <tr>
  <td>36</td>
  <td>t</td>
  <td>199</td>
  <td>27</td>
  <td>7.1</td>
  <td>26330</td>
  <td>25429</td>
  <td>1</td>
  <td>26529</td>
  <td>25456</td>
  <td>1</td>
 </tr>
 <tr>
  <td>45</td>
  <td>t</td>
  <td>5</td>
  <td>8</td>
  <td>0.6</td>
  <td>6306</td>
  <td>6142</td>
  <td>1</td>
  <td>6311</td>
  <td>6150</td>
  <td>1</td>
 </tr>
 <tr>
  <td>26</td>
  <td>t</td>
  <td>2969</td>
  <td>348</td>
  <td>8.5</td>
  <td>64557</td>
  <td>70819</td>
  <td>0.9</td>
  <td>67526</td>
  <td>71167</td>
  <td>0.9</td>
 </tr>
</table>

Temos um cliente que vamos permitir o uso de um de nossos aplicativos. A equipe no local se conecta regularmente à nossa rede via VPN. O aplicativo .Net que se conecta ao SQL Server usa segurança integrada. Os laptops que eles usam são membros do nosso domínio.

O cliente também solicitou o uso do aplicativo. Então, demos a eles uma conta de rede e a capacidade de criar uma sessão VPN em nossa rede. Dei a essa conta um login no servidor SQL com os mesmos direitos que nossa própria equipe.

O problema é que quando eles tentam usar o aplicativo recebem o seguinte erro: O login é de um domínio não confiável e não pode ser usado com a autenticação do Windows.

Suponho que, como eles estão usando um computador que não está em nosso domínio, não importa que estejam usando um login com a VPN que está. Então, qual é a melhor maneira de resolver esse problema? Prefiro não mudar para autenticação SQL para este pequeno aplicativo.