home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!europa.asd.contel.com!emory!emory!not-for-mail
- From: rridley@sin-pss.DHL.COM (Richard Ridley)
- Newsgroups: comp.databases.informix
- Subject: RE: UPDATE problem on UNIQUE constraint
- Date: 6 Jan 1993 22:23:04 -0500
- Organization: Mailing List Gateway
- Lines: 37
- Sender: walt@mathcs.emory.edu
- Distribution: world
- Message-ID: <1ig7moINN978@emory.mathcs.emory.edu>
- Reply-To: rridley@sin-pss.DHL.COM (Richard Ridley)
- NNTP-Posting-Host: emory.mathcs.emory.edu
- X-Informix-List-ID: <list.1755>
-
-
- %UNIPLEX
- %TO informix-list@rmy.emory.edu
- %FROM rridley
- %SYSTEM DHLNET
- %SUBJECT RE: UPDATE problem on UNIQUE constraint
- %VERIFY y
- %DATE 07/01/93 10:28
- %REFERENCE 10661
-
- Pedro Freire writes :
-
- >When the statement is executed, it proceeds by looking up the first
- >row that satisfies the condition, updating it and then repeats the process
- >with the next row and so on, until there are no more rows to update.
- >The question is that, when updating a row that has c_int_art = P and row P+1
- >exists and hasn't been updated (yet), after the update you'll have 2
- >rows P+1 and that violates the UNIQUE INDEX constraint, which causes
- >the statement (and the program) to be aborted with the following error message:
-
- >"Could not update a row in the table"
- >SQL -346
- >ISAM -100
-
- Which version of Online are you running ?
-
- According to the 4.1 Online Enhancements documentation, effective
- checking of unique constraints is implemented from 4.1.
-
- This should solve your problem.
-
- Cheers,
-
- Richard Ridley
-
- DHL Asia Pacific
- %UEND
-