Change is not likely. Putting a "UNIQUE" constraint is syntactic sugar for
creating a unique index. That is
CREATE TABLE dataStreamRecord
(
fwParameterID INTEGER NOT NULL,
dateTime INTEGER NOT NULL,
data INTEGER NOT NULL,
UNIQUE (fwParameterID, dateTime)
);
is merely an alternate way of saying:
CREATE TABLE dataStreamRecord
(
fwParameterID INTEGER NOT NULL,
dateTime INTEGER NOT NULL,
data INTEGER NOT NULL
);
create unique index dataStreamRecord_autoindex_1 on
dataStreamRecord(fwParameterID, dateTime);
in other words, the UNIQUE constraint is implemented as a unique index (as it
is in just about every other database system).
If you are absolutely certain that the record being inserted is not a duplicate
then perhaps the index is corrupt? Checking this (pragma integrity_check),
however, or rebuilding the index (the reindex command) will take a while on a
big database though ...
---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[email protected]] On Behalf Of Andrew Stewart
>Sent: Friday, 14 September, 2018 14:14
>To: [email protected]
>Subject: [sqlite] Unique Constraint Failed
>
>Hi all,
> I realize that this is the constraint that is
>failing. The data is very large, encrypted and at a customer's site
>- not easy to use an external program to view or to transfer to my
>office.
>
> What I am wondering is if there are any limits on the
>Unique table that is maintained or if any of the code that is used
>for this has been changed in the last couple of years.
>
>Andrew Stewart
>Software Designer
>
>ARGUS CONTROLS
>18445 53rd Avenue | Surrey, BC | V3S 7A4 | Canada
>t +1.604.538.3531 ext. 108 | +1.800.667.2090 | f +1.604.538.4728
>www.arguscontrols.com<http://www.arguscontrols.com/>
>
>Notice: This electronic transmission contains confidential
>information, intended only for the person(s) named above. If you are
>not the intended recipient, you are hereby notified that any
>disclosure, copying, distribution, or any other use of this email is
>strictly prohibited. If you have received this transmission by error,
>please notify us immediately by return email and destroy the original
>transmission immediately and all copies thereof.
>_______________________________________________
>sqlite-users mailing list
>[email protected]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users