I basically have two tables with the same structure. One is an archive
of the other (backup). I want to essentially insert the data in to the
other.
I use:
INSERT INTO table ( column, column ... )
SELECT * FROM table2
Now, table2 has a rule on various columns:
@.CHARACTER IN ('Y','N')
but the column allows nulls, in the design view is says so anyway.
When I run this query I get:
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
Obviously, I've changed the names of everything.
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
Thanks.(markjerz@.googlemail.com) writes:
Quote:
Originally Posted by
Now, table2 has a rule on various columns:
>
@.CHARACTER IN ('Y','N')
>
but the column allows nulls, in the design view is says so anyway.
>
When I run this query I get:
>
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
>
Obviously, I've changed the names of everything.
>
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
In my opinion it is a bug, but it has been way since SQL 7 (SQL 6.5
did it right), and Microsoft considers rules to be a deprecated feature,
so I have no hope for a fix.
The workaround is to write the rule so that it explicitly permits NULL.
As for the deprecation - binding rules directly to table columns is a poor
idea; use constraints instead. However, in my opinion Microsoft has
failed to understand that binding rules to user-defined types is an
asset, and for which they do not have any replacement.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||markjerz@.googlemail.com wrote:
Quote:
Originally Posted by
Hi,
>
I basically have two tables with the same structure. One is an archive
of the other (backup). I want to essentially insert the data in to the
other.
>
I use:
>
INSERT INTO table ( column, column ... )
SELECT * FROM table2
>
Now, table2 has a rule on various columns:
>
@.CHARACTER IN ('Y','N')
>
but the column allows nulls, in the design view is says so anyway.
>
When I run this query I get:
>
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
>
Obviously, I've changed the names of everything.
>
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
>
Thanks.
>
my guess is by using the rule (IN ('Y','N')) - and that because you have said
ONLY Y,N values are allowed. It is essentially a check constraint in other
databases. And I would consider any other behavior a bug.
--
Michael Austin
Database Consultant
Domain Registration and Linux/Windows Web Hosting Reseller
http://www.spacelots.com|||Thanks for your help Erland.
Sadly, I am adding features to existing code so I can't really go
changing too much stuff, will probably just add the NULL value to the
rule.
Michael, according to Microsoft, if you allow nulls in a table column
and then set a rule (like mine) the table structure is supposed to
overwrite the rule to allow nulls. This works when doing simple inserts
but sadly seems to fall down when using INSERT INTO .... SELECT * FROM
....
Again, thanks for clearing that up Erland.
Michael Austin wrote:
Quote:
Originally Posted by
markjerz@.googlemail.com wrote:
>
Quote:
Originally Posted by
Hi,
I basically have two tables with the same structure. One is an archive
of the other (backup). I want to essentially insert the data in to the
other.
I use:
INSERT INTO table ( column, column ... )
SELECT * FROM table2
Now, table2 has a rule on various columns:
@.CHARACTER IN ('Y','N')
but the column allows nulls, in the design view is says so anyway.
When I run this query I get:
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
Obviously, I've changed the names of everything.
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
Thanks.
>
my guess is by using the rule (IN ('Y','N')) - and that because you have said
ONLY Y,N values are allowed. It is essentially a check constraint in other
databases. And I would consider any other behavior a bug.
>
--
Michael Austin
Database Consultant
Domain Registration and Linux/Windows Web Hosting Reseller
http://www.spacelots.com|||Hi Erland,
I am now having problems updating the rule to allow nulls. It's
basically telling me that it can not drop the rule because it is bound
to one or more columns.
I'm not actually dropping the rule just opening it's properties in
enterprise manager and then clicking apply once I've changed it.
Any ideas? It seems a little stupid that I would have to unbind it
first then change it and rebind it. It's currently bound to a lot of
columns.
Mark
Erland Sommarskog wrote:
Quote:
Originally Posted by
(markjerz@.googlemail.com) writes:
Quote:
Originally Posted by
Now, table2 has a rule on various columns:
@.CHARACTER IN ('Y','N')
but the column allows nulls, in the design view is says so anyway.
When I run this query I get:
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
Obviously, I've changed the names of everything.
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
>
In my opinion it is a bug, but it has been way since SQL 7 (SQL 6.5
did it right), and Microsoft considers rules to be a deprecated feature,
so I have no hope for a fix.
>
The workaround is to write the rule so that it explicitly permits NULL.
>
As for the deprecation - binding rules directly to table columns is a poor
idea; use constraints instead. However, in my opinion Microsoft has
failed to understand that binding rules to user-defined types is an
asset, and for which they do not have any replacement.
>
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||just drop table and recreate it with new rules and then import.
markjerz@.googlemail.com wrote:
Quote:
Originally Posted by
Hi Erland,
>
I am now having problems updating the rule to allow nulls. It's
basically telling me that it can not drop the rule because it is bound
to one or more columns.
>
I'm not actually dropping the rule just opening it's properties in
enterprise manager and then clicking apply once I've changed it.
>
Any ideas? It seems a little stupid that I would have to unbind it
first then change it and rebind it. It's currently bound to a lot of
columns.
>
Mark
>
>
Erland Sommarskog wrote:
>
Quote:
Originally Posted by
(markjerz@.googlemail.com) writes:
Quote:
Originally Posted by
Now, table2 has a rule on various columns:
>
@.CHARACTER IN ('Y','N')
>
but the column allows nulls, in the design view is says so anyway.
>
When I run this query I get:
>
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
>
Obviously, I've changed the names of everything.
>
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
In my opinion it is a bug, but it has been way since SQL 7 (SQL 6.5
did it right), and Microsoft considers rules to be a deprecated feature,
so I have no hope for a fix.
The workaround is to write the rule so that it explicitly permits NULL.
As for the deprecation - binding rules directly to table columns is a poor
idea; use constraints instead. However, in my opinion Microsoft has
failed to understand that binding rules to user-defined types is an
asset, and for which they do not have any replacement.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
using that rule with a lot of data in them. I've read something about
updating syscomments table? Not sure of the exact procedure though so
any help would be good.
Thanks.
othell...@.yahoo.com wrote:
Quote:
Originally Posted by
just drop table and recreate it with new rules and then import.
>
markjerz@.googlemail.com wrote:
Quote:
Originally Posted by
Hi Erland,
I am now having problems updating the rule to allow nulls. It's
basically telling me that it can not drop the rule because it is bound
to one or more columns.
I'm not actually dropping the rule just opening it's properties in
enterprise manager and then clicking apply once I've changed it.
Any ideas? It seems a little stupid that I would have to unbind it
first then change it and rebind it. It's currently bound to a lot of
columns.
Mark
Erland Sommarskog wrote:
Quote:
Originally Posted by
(markjerz@.googlemail.com) writes:
Now, table2 has a rule on various columns:
@.CHARACTER IN ('Y','N')
but the column allows nulls, in the design view is says so anyway.
When I run this query I get:
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
Obviously, I've changed the names of everything.
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
>
In my opinion it is a bug, but it has been way since SQL 7 (SQL 6.5
did it right), and Microsoft considers rules to be a deprecated feature,
so I have no hope for a fix.
>
The workaround is to write the rule so that it explicitly permits NULL.
>
As for the deprecation - binding rules directly to table columns is a poor
idea; use constraints instead. However, in my opinion Microsoft has
failed to understand that binding rules to user-defined types is an
asset, and for which they do not have any replacement.
>
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Quote:
Originally Posted by
That's not even slightly viable. I have well over a hundred tables
using that rule with a lot of data in them.
Rules are not viable at all in my opinion. This is perhaps one reason
why they are deprecated in favour of constraints:
"CREATE RULE will be removed in a future version of Microsoft SQL
Server. Avoid using CREATE RULE in new development work, and plan to
modify applications that currently use it. We recommend that you use
check constraints instead. Check constraints are created by using the
CHECK keyword of CREATE TABLE or ALTER TABLE. For more information, see
CHECK Constraints."
Quote:
Originally Posted by
I've read something about
updating syscomments table? Not sure of the exact procedure though so
any help would be good.
>
There is no exact procedure. Updating system tables is dangerous,
unreliable and unsupported. Don't go there.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/...US,SQL.90).aspx
--|||If you have 100s of tables with a faulty rule then you should drop the
whole database and recreate them with a correct rule. It should not
take more than a day to recreate 100s of tables correctly
markjerz@.googlemail.com wrote:
Quote:
Originally Posted by
That's not even slightly viable. I have well over a hundred tables
using that rule with a lot of data in them. I've read something about
updating syscomments table? Not sure of the exact procedure though so
any help would be good.
>
Thanks.
>
>
othell...@.yahoo.com wrote:
>
Quote:
Originally Posted by
just drop table and recreate it with new rules and then import.
markjerz@.googlemail.com wrote:
Quote:
Originally Posted by
Hi Erland,
>
I am now having problems updating the rule to allow nulls. It's
basically telling me that it can not drop the rule because it is bound
to one or more columns.
>
I'm not actually dropping the rule just opening it's properties in
enterprise manager and then clicking apply once I've changed it.
>
Any ideas? It seems a little stupid that I would have to unbind it
first then change it and rebind it. It's currently bound to a lot of
columns.
>
Mark
>
>
Erland Sommarskog wrote:
>
(markjerz@.googlemail.com) writes:
Now, table2 has a rule on various columns:
>
@.CHARACTER IN ('Y','N')
>
but the column allows nulls, in the design view is says so anyway.
>
When I run this query I get:
>
A column insert or update conflicts with a rule imposed by a previous
CREATE RULE statement. The statement was terminated. The conflict
occurred in database 'database', table 'table', column 'column'.
The statement has been terminated.
>
Obviously, I've changed the names of everything.
>
The only data in those columns which could possibly conflict with the
rule is the NULL value. Any ideas why this doesn't work?
In my opinion it is a bug, but it has been way since SQL 7 (SQL 6.5
did it right), and Microsoft considers rules to be a deprecated feature,
so I have no hope for a fix.
The workaround is to write the rule so that it explicitly permits NULL.
As for the deprecation - binding rules directly to table columns is a poor
idea; use constraints instead. However, in my opinion Microsoft has
failed to understand that binding rules to user-defined types is an
asset, and for which they do not have any replacement.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
No comments:
Post a Comment