Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 6 of 6 total |
CHECK constraint not checked |
Tue, Feb 27 2007 7:35 PM | Permanent Link |
"Ole Willy Tuv" | create table test (c1 integer)
insert into test values (0); alter table test add constraint ck_test_c1 check (c1 >= 1); The ALTER TABLE statement should throw a constraint violation error since the table data does not satisfy the constraint. Ole Willy Tuv |
Wed, Feb 28 2007 9:13 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ole,
<< The ALTER TABLE statement should throw a constraint violation error since the table data does not satisfy the constraint. >> Check the TEDBQuery.OnLogMessage event handler. It will indicate what happened due to the constraint violation (row removed). I'm surfacing this logging in build 2 of the EDB Manager. It was an oversight that it was left out. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 28 2007 9:26 AM | Permanent Link |
"Ole Willy Tuv" | Tim,
<< Check the TEDBQuery.OnLogMessage event handler. It will indicate what happened due to the constraint violation (row removed). >> I don't have ElevateDB (VCL) installed, I'm just using the EDB Manager binary. I don't think that silently removing conflicting rows is a good way to handle constraint violations. The general rule is to raise an exception. Ole Willy Tuv |
Wed, Feb 28 2007 10:04 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ole,
<< I don't think that silently removing conflicting rows is a good way to handle constraint violations. The general rule is to raise an exception. >> The ideal situation is what DBISAM had, and I plan to add support for interrogating the user as to how to proceed. However, for now it will log the issues with the ALTER and display them to the user. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 28 2007 10:37 AM | Permanent Link |
"Ole Willy Tuv" | Tim,
<< The ideal situation is what DBISAM had, and I plan to add support for interrogating the user as to how to proceed. However, for now it will log the issues with the ALTER and display them to the user. >> OK. In case you'd like to know the general constraint check rule you're deviating from: ISO/IEC 9075-2:2003 10.8 <constraint name definition> and <constraint characteristics> 5) When a constraint is effectively checked, if the constraint is not satisfied, then an exception condition is raised: integrity constraint violation. If this exception condition is raised as a result of executing a <commit statement>, then SQLSTATE is not set to integrity constraint violation, but is set to transaction rollback - integrity constraint violation (see the General Rules of Subclause 16.6, "<commit statement>"). Ole Willy Tuv |
Sun, Apr 8 2007 7:58 AM | Permanent Link |
"Ole Willy Tuv" | Tim,
<<< I don't think that silently removing conflicting rows is a good way to handle constraint violations. The general rule is to raise an exception. >>> << The ideal situation is what DBISAM had, and I plan to add support for interrogating the user as to how to proceed. However, for now it will log the issues with the ALTER and display them to the user. >> AFAICS, 1.02 build 1 validates data integrity when executing constraint definitions and raises proper exceptions if a constraint is violated. Excellent. Ole Willy Tuv |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |