string ou dados binários seriam truncados na tabela '******', coluna '******'. Valor truncado: '*******'

Parece que esta tabela foi definida com mascaramento de dados dinâmico e o usuário que o aplicativo usa para acessar o banco de dados não tem permissão para visualizar dados mascarados (o que é bom!).

É por isso que o comportamento difere entre o aplicativo e o SSMS: espero que você esteja usando um usuário com privilégios mais altos ao executar a consulta do SSMS

Aqui está uma demonstração:

CREATE TABLE dbo.Test
(
    Id int IDENTITY PRIMARY KEY,
    Filler varchar(100) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL
);
GO

CREATE USER TestUser WITHOUT LOGIN;  
GRANT SELECT ON dbo.Test TO TestUser;  
GRANT INSERT ON dbo.Test TO TestUser;
GO

EXECUTE AS USER = 'TestUser';
INSERT dbo.Test 
    (Filler)
VALUES
    (REPLICATE(N'A', 101)); 
REVERT;

O resultado disso é:

Msg 2628, Level 16, State 1, Line 12
String or binary data would be truncated in table '******', column '******'. Truncated value: '******'.

Para obter a mensagem completa no aplicativo, você precisará conceder a UNMASKpermissão ao usuário:

GRANT UNMASK TO TestUser;

Executar o INSERTcódigo novamente resulta no texto completo do erro:

Msg 2628, Level 16, State 1, Line 14
String or binary data would be truncated in table 'tempdb.dbo.Test', column 'Filler'. Truncated value: 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.

Ao usar o Banco de Dados SQL do Azure, o Mascaramento de Dados Dinâmico também pode ser configurado na interface do usuário do Portal do Azure. Você pode querer verificar lá (embora, até onde eu saiba, as máscaras configuradas dessa maneira ainda atualizam os sys.columnsmetadados):

Eu também verificaria se há outros bancos de dados que fazem parte da mesma instância lógica do SQL Server no Azure - talvez haja algum tipo de consulta estranha entre bancos de dados em andamento.

Acho que está relacionado a um bug novo e subnotificado no Banco de Dados SQL do Azure (somente), onde as Tabelas Temporais são tratadas de forma diferente das tabelas normais, quando ocorrem os erros 245 e 2628.

Descobri que adicionei a Classificação de Sensibilidade a todas as minhas Tabelas Temporais (e apenas a algumas das minhas Tabelas não Temporais).

Como em

add SENSITIVITY CLASSIFICATION to dbo.Mytable.name with (LABEL = 'General', INFORMATION_TYPE = 'Public')

quando eu descarto a Classificação de Sensibilidade, a antiga mensagem de erro está de volta.

Tenho um exemplo que demonstra o erro:

drop table if exists dbo.mytable
go
create table dbo.Mytable (i int not null identity(1,1) primary key clustered, name varchar(10) not null)
go
insert into dbo.Mytable ( name ) values ( 'abc' )
go
select * from dbo.Mytable where name = 1  -- programming error; data type mis-match

retorna

(1 row affected)
Msg 245, Level 16, State 1, Line 8
Conversion failed when converting the varchar value 'abc' to data type int.

Esta é a mensagem de erro correta . Agora execute isso:

add SENSITIVITY CLASSIFICATION to dbo.Mytable.name with (LABEL = 'General', INFORMATION_TYPE = 'Public')

e quando você executa isso

select * from dbo.Mytable where name = 1 -- programming error; data type mis-match

Você vai ver isso

Msg 245, Level 16, State 1, Line 169
Conversion failed when converting the ****** value '******' to data type ******.

Esta é a mensagem de erro incorreta .

Eu tentei este código no Banco de Dados SQL do Azure, onde recebo a mensagem incorreta, e no SQL Server 2019 CU6, onde recebo apenas a mensagem correta.

Eu relatei isso à Microsoft, e eles reconheceram que isso é um bug e que será corrigido em alguns meses.

Criei dois scripts para 1) documentar as classificações existentes e 2) eliminar todas essas classificações.

Os scripts podem ser encontrados aqui: document and drop classificações

O mascaramento na mensagem de erro pode ocorrer também em cenários não relacionados ao mascaramento dinâmico de dados (ou tabelas temporais). Veja o exemplo a seguir:

CREATE DATABASE ErrorMessageTest
GO
USE ErrorMessageTest
GO
CREATE USER SimpleUser WITHOUT LOGIN
GO
ALTER ROLE db_datareader ADD MEMBER SimpleUser
GO
CREATE FUNCTION dbo.Numbers(@MaxNumber int)
RETURNS TABLE AS RETURN
 WITH Nbrs_4( n ) AS ( SELECT 1 UNION SELECT 0 ),
          Nbrs_3( n ) AS ( SELECT 1 FROM Nbrs_4 n1 CROSS JOIN Nbrs_4 n2 ),
          Nbrs_2( n ) AS ( SELECT 1 FROM Nbrs_3 n1 CROSS JOIN Nbrs_3 n2 ),
          Nbrs_1( n ) AS ( SELECT 1 FROM Nbrs_2 n1 CROSS JOIN Nbrs_2 n2 ),
          Nbrs_0( n ) AS ( SELECT 1 FROM Nbrs_1 n1 CROSS JOIN Nbrs_1 n2 ),
          Nbrs  ( n ) AS ( SELECT 1 FROM Nbrs_0 n1 CROSS JOIN Nbrs_0 n2 )
        SELECT n
          FROM ( SELECT ROW_NUMBER() OVER (ORDER BY n)
                   FROM Nbrs ) D ( n )
         WHERE n <= @MaxNumber ;
GO
CREATE FUNCTION dbo.Split(@Param nvarchar(MAX),@Separator NCHAR(1))
RETURNS TABLE AS RETURN 
SELECT SUBSTRING(@Param, N, CHARINDEX(@Separator, @Param + @Separator, n) - n) AS VALUE, 
    ROW_NUMBER() OVER (ORDER BY N) AS Position
FROM dbo.Numbers(LEN(@Param)) n
WHERE SUBSTRING(@Separator + @Param, n, 1) = @Separator

GO
EXECUTE AS USER='SimpleUser'

DECLARE @ApplyToMonth NVARCHAR(101) = '1,2,3,4,5,6, test error message,8'

SELECT t.VALUE AS OriginalValue, TRY_CAST(REPLACE(t.VALUE, ' ', '') AS INT) AS IntValue
    FROM dbo.Split(@ApplyToMonth, ',') t
SELECT    x.OriginalValue, x.IntValue,
        CASE WHEN x.IntValue IS NULL THEN CAST(x.OriginalValue AS INT) ELSE 0 END AS RaisErrorColumn
FROM (
    SELECT t.VALUE AS OriginalValue, TRY_CAST(REPLACE(t.VALUE, ' ', '') AS INT) AS IntValue
    FROM dbo.Split(@ApplyToMonth, ',') t
) x

GO
REVERT
GO
USE master
GO
DROP DATABASE ErrorMessageTest

No SQL Server 2016 e no SQL Server 2017, isso produz a seguinte mensagem de erro:

Conversion failed when converting the ****** value '******' to data type ******.

Surpreendentemente, a solução neste caso é a mesma que nos outros casos:GRANT UNMASK TO SimpleUser

Estou inclinado a dizer que isso é um bug, porque no SQL Server 2019 CU5, recebo a mensagem de erro completa (sem conceder UNMASK):

Conversion failed when converting the nvarchar value ' test error message' to data type int.

O comportamento que você está vendo (ou seja, meta-dados sendo substituídos por ***mensagens de erro para contas sysadminnão/não dbo-contas) parece ser o efeito do sinalizador de rastreamento 3625: Configuração de visibilidade de metadados . Não tenho uma conta do Azure para testar, mas a documentação indica que esse recurso está disponível no Banco de Dados SQL do Azure.

Uma possibilidade muito menos provável (na verdade, nem deveria ser possível neste momento) é que alguém configurou a opção "restrições de recursos" de curta duração ( felizmente!ERRORMESSAGE ) para , que era efetivamente a mesma coisa que o sinalizador de rastreamento 3625. Houve alguns meses, acredito, em que o recurso "Restrições de recursos" estava sendo desativado em que era possível que ele fosse configurado anteriormente, mas não estivesse mais totalmente acessível. No entanto, esse recurso deve ter sido 100% removido (do Banco de Dados SQL do Azure) até 4 de março de 2020, o mais tardar.