Início / dba / Perguntas / 49278
Accepted
Daniel Mann
Asked: 2013-09-05 11:08:26 +0800 CST

Publicação de alterações de banco de dados com SSDT que incluem a alteração de tipos de dados de colunas

  • 772

Eu tenho um projeto SQL Server Data Tools (VS2012) que é publicado automaticamente durante o processo de compilação. Uma coluna foi atualizada recentemente de um intpara decimal(18,4). Como resultado dessa alteração, a publicação falha com o erro

(49,1): SQL72014: .Net SqlClient Data Provider: Msg 50000, Level 16, State 127, Line 6 Linhas foram detectadas. A atualização do esquema está terminando porque pode ocorrer perda de dados. (44,0): SQL72045: Erro de execução de script. O script executado: /* O tipo da coluna QuantidadeRecebida na tabela [dbo].[Reconciliação_Recebimento] atualmente é INT NOT NULL, mas está sendo alterado para DECIMAL (18, 4) NOT NULL. Pode ocorrer perda de dados. */

IF EXISTS (selecione top 1 1 de [dbo].[Reconciliation_Receiving]) RAISERROR (N'Rows foram detectadas. A atualização do esquema está terminando porque pode ocorrer perda de dados.', 16, 127) WITH NOWAIT Ocorreu um erro enquanto o lote estava sendo sendo executado.

Entendo por que estou recebendo esse erro e sei que ele pode ser resolvido desativando o sinalizador "Bloquear implantação incremental se ocorrer perda de dados". No entanto, há uma forte oposição à desabilitação desse recurso, portanto, não será uma solução aceitável.

A única outra solução que consigo pensar é fazer o seguinte:

  1. Faça uma tabela temporária e copie o conteúdo da tabela existente na tabela temporária
  2. Truncar a tabela existente
  3. Deixe o SSDT atualizar o tipo de dados
  4. Preencha os dados de volta da tabela temporária

Isso parece terrivelmente desajeitado e ineficiente, no entanto.

Existe uma alternativa melhor?

sql-server ssdt

3 respostas

  1. Best Answer

    Fiquei tentado a ignorar essa bandeira também, mas fiquei do lado de seus colegas de trabalho e agora tento lidar com essas questões "corretamente". A rota (marginalmente) menos complicada é usar scripts de pré e pós-implantação para fazer o trabalho com uma renomeação.

    • Renomeie a tabela existente em um script de pré-implantação.
    • Com a tabela existente ausente, a tabela em foco será criada de acordo com a nova definição de esquema.
    • Em uma cópia de script pós-implantação da tabela original renomeada para a nova versão.

    Dependendo da natureza do destino, você pode precisar cuidar de descartar e recriar restrições de chave estrangeira.

    • 6

  2. No meu caso eu estava removendo uma coluna de uma tabela.

    A solução fornecida nesta resposta não funcionou para mim, resultou em um invalid object nameerro durante a publicação.

    Descobri que era necessário copiar as linhas da tabela, desabilitar a verificação de restrição e excluir as linhas em um script de pré-implantação e, em seguida, copiar as linhas de volta para a tabela com a inserção de identidade habilitada no script pós-implantação.

    Em Script.PreDeployment.sql:

    -- copy and delete dbo.Table1
BEGIN TRY
    IF (EXISTS (
        SELECT * FROM INFORMATION_SCHEMA.TABLES 
        WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'Table1_copy'))
    BEGIN
        PRINT 'Dropping Table1_copy'
        DROP TABLE dbo.Table1_copy
    END

    PRINT 'Copying dbo.Table1'

    SELECT @LastID = MAX(ID), @StartID = MIN(ID)
    FROM dbo.Table1

    SET @EndID = @StartID + 1000

    SELECT * 
    INTO dbo.Table1_copy 
    FROM dbo.Table1
    WHERE ID BETWEEN @StartID AND @EndId

    SET @StartID = @EndID + 1

    SET IDENTITY_INSERT dbo.Table1_copy ON

    WHILE @StartID < @LastID
    BEGIN
        SET @EndID = @StartID + 1000

        INSERT dbo.Table1_copy (ID, Column1, Column2, Column3)
        SELECT ID, Column1, Column2, Column3
        FROM dbo.Table1
        WHERE ID BETWEEN @StartID AND @EndId

        SET @StartID = @EndID + 1
    END

    SET IDENTITY_INSERT dbo.Table1_copy OFF

    PRINT 'Copied dbo.Table1 to dbo.Table1_copy'

    EXEC sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all"

    PRINT 'Deleting dbo.Table1'
    WHILE EXISTS (SELECT 1 FROM dbo.Table1) 
        DELETE TOP(1000) FROM dbo.Table1
    PRINT 'Deleted dbo.Table1'

    PRINT 'SUCCESS: Copy and delete dbo.Table1'
END TRY
BEGIN CATCH
    EXEC sp_msforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"

    PRINT 'ERROR: Copy and delete dbo.Table1'
    PRINT 'ERROR MESSAGE: ' + ERROR_MESSAGE()
END CATCH
GO

    Em Script.PostDeployment.sql

    DECLARE @StartID BIGINT, @LastID BIGINT, @EndID BIGINT

-- populate dbo.Table1
BEGIN TRY
    PRINT 'Populating dbo.Table1'

    SET IDENTITY_INSERT dbo.Table1 ON

    SELECT @LastID = MAX(ID)
    FROM dbo.Table1_copy

    WHILE @StartID < @LastID
    BEGIN
        SET @EndID = @StartID + 1000

        INSERT dbo.Table1 (ID, Column1, Column2, Column3)
        SELECT ID, Column1, Column2, Column3
        FROM dbo.Table1
        WHERE ID BETWEEN @StartID AND @EndId

        SET @StartID = @EndID + 1
    END

    SET IDENTITY_INSERT dbo.Table1 OFF

    EXEC sp_msforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"

    PRINT 'SUCCESS: Populating dbo.Table1'
END TRY
BEGIN CATCH
    SET IDENTITY_INSERT dbo.Table1 OFF

    PRINT 'ERROR: Populating dbo.Table1'
    PRINT 'ERROR MESSAGE: ' + ERROR_MESSAGE()
END CATCH
GO
    • 2

  3. ALTER TABLE tabela_1 ALTER COLUMN [a] decimal (18,2)

    Fará o trabalho neste caso, solução muito mais simples para um script de pré-implantação. Também descobri que alterar o destino antes da publicação evitará que o erro de perda de dados seja gerado.

    Às vezes, o SSDT identificará soluções ALTER TABLE/ALTER COLUMN e as usará na compilação, mas não conheço as regras para tornar isso confiável da perspectiva do usuário. Não sei porque não usa nesse caso. Não há chance de perda de dados com ALTER COLUMN.

    • 0

relate perguntas