M Herbener's questions

Usando o SQL Server 2022 Standard Edition e usuários de banco de dados independente (o que significa nenhum login SQL correspondente no nível da instância). Gostaria que os usuários do banco de dados contido pudessem usar um servidor vinculado e, especificamente, com o usuário contido mapeado para usar um nome de usuário/senha específico no banco de dados remoto. Quando tento adicionar o mapeamento usando SSMS, recebo o erro

Ocorreu uma exceção ao executar uma instrução ou lote Transact-SQL. (Microsoft.SqlServer.ConnectionInfo) 'nome de usuário' não é um login válido ou você não tem permissão. (Microsoft SQL Server, Erro: 15007)

Minha interpretação é que esse recurso de mapeamento de usuários do servidor vinculado funciona apenas com logins em nível de instância e não é possível quando o login local é um usuário de banco de dados independente. No entanto, não consigo encontrar nenhuma documentação explícita da Microsoft sobre essa limitação.

Alguém pode confirmar meu entendimento ou estou faltando algo que tornaria isso possível?

Usando o SQL Server 2017 Standard CU8 no Windows Server 2016. Criei um usuário de banco de dados independente (definido apenas em um banco de dados com Containment type: partial) com tipo SQL user with password(portanto, não uma conta de usuário baseada no Windows). Em uma definição de servidor vinculado, na guia Segurança, na Local Server login to remote server loginárea, existe alguma maneira de especificar esse usuário como um usuário local (para mapeá-lo especificamente para um usuário remoto)? Eu tentei apenas o nome de usuário e também prefixei com o nome do banco de dados (separado por \ e por .), mas sempre recebo um erro Error: ‘contained_user’ is not a valid login or you do not have permission.

De certa forma, isso faz sentido, já que um servidor vinculado é um objeto em nível de instância e ter um banco de dados independente dependente dele seria um pouco contrário à ideia de contenção, mas não vi essa limitação documentada em nenhum lugar (como https:/ /learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases?view=sql-server-2017#Limitations ou https://learn.microsoft.com/en-us/sql/relational -databases/system-stored-procedures/sp-addlinkedsrvlogin-transact-sql?view=sql-server-2017 ), então me perguntei se eu estava apenas errando a sintaxe.

A propósito, um usuário baseado em login do Windows criado em um banco de dados independente PODE ser associado a um servidor vinculado.

obrigado!

Martinho

Estou tentando determinar se posso usar Always Encrypted em uma coluna em uma tabela temporária (SQL Server 2016 SP1 Enterprise no Windows 2016). Eu tentei da seguinte forma:

CREATE TABLE #listofdates (compare_dt datetime2(7) encrypted with (
    COLUMN_ENCRYPTION_KEY = [ColEnc1]
    , ENCRYPTION_TYPE = Deterministic
    , ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
    ) NOT NULL
)

No entanto, recebo o erro:

Msg 33293, Level 16, State 8, Line 3
Não é possível localizar a chave de criptografia da coluna "ColEnc1" porque ela não existe ou você não tem permissões.

Eu acho que esse erro é enganoso, porque a instrução funciona se eu simplesmente substituir o nome da tabela #listofdatespor outro nome sem o # inicial (portanto, alternando de uma tabela temporária para uma tabela comum).

A seção no site da MS que lista os limites/restrições no Always Encrypted não menciona tabelas temporárias.