Comments
4 comments
-
I'm not sure. Could you post the DDL for the type and I'll see if I can reproduce it here?
-
Thanks for the reply, Chris...
After playing with this for a while, I suspect it has to do with default and check constraints, however I find it curious that the compare doesn't find (or at least display) any differences.
This is how the table type scripts out as a CREATE:USE [dev_cisitem] GO CREATE TYPE [stage1].[common_message_list] AS TABLE( [common_message_id] [int] IDENTITY(1,1) NOT NULL, [obj_id] [varchar](32) NULL, [obj_type] [varchar](32) NULL, [status_code] [char](1) NOT NULL DEFAULT ('S'), [msg_source] [varchar](32) NULL, [msg_level] [varchar](16) NOT NULL DEFAULT ('Informational'), [msg_text] [varchar](128) NOT NULL, [msg_parm] [varchar](128) NULL, CHECK (([msg_level]='Abort' OR [msg_level]='Error' OR [msg_level]='Warning' OR [msg_level]='Validation' OR [msg_level]='Informational')), CHECK (([status_code]='S' OR [status_code]='F')) ) GO
-
Sorry for the delay, this is definitely a bug.
I've logged it under the bug tracking code SOC-4068. I'll let you know as soon as I find out when it's expected to be fixed.
Sorry for the inconvenience. -
Thanks for the update Chris...
I'll watch for your resolution.
-John
Add comment
Please sign in to leave a comment.
There are no changes being made to this UDT and curiously, the diff at the bottom of the source control tab does not indicate any differences.
However, if this UDT is selected and committed, when the screen is refreshed, it still remains in the list of objects requiring committing.
Any ideas on why this single UDT might always appear to need a commit?