TUniQuery not choosing primary key when doing a .Edit/.Post

Discussion of open issues, suggestions and bugs regarding UniDAC (Universal Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
peolsson
Posts: 11
Joined: Thu 30 Apr 2009 07:30

TUniQuery not choosing primary key when doing a .Edit/.Post

Post by peolsson » Mon 22 Jun 2009 12:22

I have a problem when using TUniQuery, at least I know it's a problem for the PostgreSQL driver (I think it works differently in at least MySQL).

Some of the tables I'm using both have a primary key, plus a unique key on another column. The create table syntax looks like this;

CREATE TABLE namn (
namn_id serial NOT NULL,
namn_uid character varying(38) DEFAULT NULL::character varying,
namn_fnamn character varying(40) DEFAULT NULL::character varying,
namn_enamn character varying(40) DEFAULT NULL::character varying,
CONSTRAINT namn_pkey PRIMARY KEY (namn_id),
CONSTRAINT namn_namn_uid_key UNIQUE (namn_uid));

---

The reason for this is because we in some cases uses uuid's (for some replication stuff), but we still use the first field (namn_id) internally in most of the applications I've done. The problem here is that the uid field is not always populated, since the unique index will work anyway, as long as the field is NULL.

Anyway, when using a table like this, and doing a TUniQuery.Edit and then a TUniQuery.Post, it chooses the uid field as the unique key, instead of the namn_id-field. And if not the uid field is populated, this will cause the query to update all null columns (which might be all of the records).

Shouldn't it use the primary key first of all, instead of using the second unique index? I know that I'm able to set what keyfields to use, but I still think I shouldn't need to do that, and that the driver itself should do it for me. As I said earlier, I think it works in MySQL when using the same table structure.

Regards,

Peter Olsson

Plash
Devart Team
Posts: 2844
Joined: Wed 10 May 2006 07:09

Post by Plash » Thu 25 Jun 2009 07:31

PostgreSQL, Oracle, InterBase, and SQLite providers use any unique index as a key. If there are several indexes the providers use the first index found. In the most cases it is the primary key.

We'll consider the possibility to add checking for primary key in a future UniDAC version.

Post Reply