Não, não está registrado em nenhum lugar. Vá votar e indique seu caso de negócios; esse é um dos itens que devem ser corrigidos no SQL Server.
Isso foi solicitado anos atrás no Connect (provavelmente primeiro no período de tempo do SQL Server 2000 ou 2005) e depois novamente no novo sistema de feedback:
E agora ele foi entregue no SQL Server 2019 , SQL Server 2017 CU12 e aparecerá em uma futura CU do SQL Server 2016 SP2.
No primeiro CTP público do SQL Server 2019, ele aparece apenas sob o sinalizador de rastreamento 460. Isso parece meio secreto, mas foi publicado neste whitepaper da Microsoft . Esse será o comportamento padrão (nenhum sinalizador de rastreamento necessário) daqui para frente, embora você possa controlar isso por meio de uma nova configuração de escopo do banco de dados VERBOSE_TRUNCATION_WARNINGS
.
Aqui está um exemplo:
USE tempdb;
GO
CREATE TABLE dbo.x(a char(1));
INSERT dbo.x(a) VALUES('foo');
GO
Resultar em todas as versões suportadas antes do SQL Server 2019:
Msg 8152, nível 16, estado 30, linha 5
String ou dados binários seriam truncados.
A instrução foi encerrada.
Agora, nos CTPs do SQL Server 2019, com o sinalizador de rastreamento ativado:
DBCC TRACEON(460);
GO
INSERT dbo.x(a) VALUES('foo');
GO
DROP TABLE dbo.x;
DBCC TRACEOFF(460);
O resultado mostra a tabela, a coluna e o valor ( truncado , não completo ):
Msg 2628, Nível 16, Estado 1, Linha 11
Seqüência de caracteres ou dados binários seriam truncados na tabela 'tempdb.dbo.x', coluna 'a'. Valor truncado: 'f'.
A instrução foi encerrada.
Até que você possa largar tudo e atualizar para o SQL Server 2019 ou migrar para o Banco de Dados SQL do Azure, você pode alterar o código "automagic" para realmente extrair o max_length sys.columns
, juntamente com o nome do qual você deve chegar lá e aplicar LEFT(column, max_length)
ou qualquer que seja o equivalente do PG. Ou, como isso significa que você perderá dados silenciosamente, descubra quais colunas são incompatíveis e corrija as colunas de destino para que elas se ajustem a todos os dados da origem. Dado o acesso de metadados aos dois sistemas e o fato de você já estar escrevendo uma consulta que deve corresponder automaticamente a colunas de origem -> destino (caso contrário, esse erro dificilmente seria o seu maior problema), não seria necessário fazer força bruta adivinhando.
sys.columns
porque não tinha absolutamente nenhuma idéia de qual código você está usando no momento para gerar "automagicamente" suas consultas. Realmente não há muito mais complexo que eu possa adivinhar sobre incorporar ao seu código do queSELECT name, object_id, max_length FROM sys.columns;
. Como você já possui um código automagic que deve estar fazendo isso - ou algo parecido -, não achei que fosse necessário um exemplo.