> Sounds right to me. Alter the table field not null, but this time don't
> update the field to any value.

I just tried removing the constraint but leaving everything else exactly
the same, and lo-and-behold the exception that was being raised is no
longer being raised. So it would seem that we have an explanation.
Or have we? If it is true that all the records must be set in one go,
then why isn't an exception raised when the front-end code tries to set
them one-bye one (and seemingly fails)? I have just tried letting the
front-end code alter the table structure and committing the change, and
then switching to FlameRobin to change the field in just one of the
records. Sure enough, I can change one record and commit the change
with no errors reported. If I quit FlameRobin, and restart it, I can
see from SELECT * FROM "Readers"; that my change is still there. So I
should be able to do the same from the front-end code. So I've just
changed the front-end code so that instead of setting the value to 0, it
sets it to 1; now I get an exception thrown! So it looks like
something checks with the existing value and gets back 0 (even though
it's NULL), and decides that no change need be made. Since no change
is made, no exception gets raised, and the value stays as NULL. But
why doesn't FlameRobin object when the same value change is made and
committed?

Regards,

Robert.
----------


----------


No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.36/2126 - Release Date: 05/21/09 06:22:00


[Non-text portions of this message have been removed]