DB Project Publish Empty string inserting a Zero

  • Hi,

    we have a Visual Studio 2013 DB Project which we use to create and populate a test database.

    We have a table with a varchar NULL column (defaultvalue), and when we run the publish.sql script any INSERT of '' get converted to '0' values.

    This is the table definition

    CREATE TABLE [dbo].[CatalogueItemExtensionFields]

    (

    [RowID] tinyint identity not null,

    [FieldType] tinyint not null,

    [Description] varchar(120) not null,

    [Nullable] bit not null,

    [DefaultValue] varchar(100) null,

    [Active_Flag] bit null,

    [OrderPriority] tinyint not null,

    [ContextGuid] uniqueidentifier not null

    );

    This is the INSERT statement, and we want to insert an empty string into the "defaultvalue" field

    set identity_insert CatalogueItemExtensionFields on

    INSERT INTO CatalogueItemExtensionFields (rowid, fieldtype, description, nullable, defaultvalue, active_flag, orderpriority)

    VALUES (1, 3, 'Product Group', 0, '', 1, 1)

    set identity_insert CatalogueItemExtensionFields off

    If we run the above script manually it works fine. But when it is run in SQLCMD mode by the DB project PUBLISH action, we see that '0' is inserted.

    What we have also done is modify the publish.sql file manually, as follows

    set identity_insert CatalogueItemExtensionFields on

    INSERT INTO CatalogueItemExtensionFields (rowid, fieldtype, description, nullable, defaultvalue, active_flag, orderpriority)

    VALUES (1, 3, 'Product Group', 0, 'TEST STRING', 1, 1)

    set identity_insert CatalogueItemExtensionFields off

    When we manually execute the publish.sql we get this error:

    'Msg 245, Level 16, State 1, Line 7 Conversion failed when converting the varchar value 'test' to data type int.'

    So this means that the SQLCMD thinks the field is an INT, but that is not how it appears in the table definition.

    Is there an obscure DB setting used in SQLCMD mode?

    Thanks for your help

  • Hi,

    sorry but I had missed a crucial point. I was running multiple INSERT statements, and in some of those I was writing an INT to the varchar field.

    As a result, SQL Server "decided" that the field was really (?) an INT, and giving me the error when I tried to insert a string.

    Not sure I understand why though.

    set identity_insert CatalogueItemExtensionFields on

    INSERT INTO CatalogueItemExtensionFields (rowid, fieldtype, description, nullable, defaultvalue, active_flag, orderpriority) VALUES

    (6, 3, N'Product Group', 0, N'', 1, 6),

    (7, 2, N'Minimum Order Quantity', 1, NULL, 1, 7),

    (8, 3, N'Additional HIBCs', 0, 1, 1, 8)

    set identity_insert CatalogueItemExtensionFields off

    If I instead run the following statement, with a default value of '1' for RowID = 8, it all works fine.

    INSERT INTO CatalogueItemExtensionFields (rowid, fieldtype, description, nullable, defaultvalue, active_flag, orderpriority) VALUES

    (6, 3, N'Product Group', 0, N'', 1, 6),

    (7, 2, N'Minimum Order Quantity', 1, NULL, 1, 7),

    (8, 3, N'Additional HIBCs', 0, '1', 1, 8),

    So, why does SQL Server do this?

    Full post on Stack Overflow

  • empty string converts to an int without an error, and it's value is zero. it has to do with the precidence of implicit conversions

    you could use the NULLIF function to resolve this, but i'm not sure if that's possible in your case or not

    INSERT INTO CatalogueItemExtensionFields (rowid, fieldtype, description, nullable, defaultvalue, active_flag, orderpriority)

    SELECT 1, 3, 'Product Group', 0,NULLIF('',''), 1, 1 UNION ALL

    SELECT 2, 3, 'Product Group', 0,NULLIF('4',''), 1, 1

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply