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

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

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

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

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

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