UNIDAC for oracle Sometimes update not by key fields

Discussion of open issues, suggestions and bugs regarding UniDAC (Universal Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
daizhicun
Posts: 109
Joined: Thu 21 Jan 2010 11:49

UNIDAC for oracle Sometimes update not by key fields

Post by daizhicun » Mon 06 Sep 2010 10:08

for example:
crate table test
(
keyField varhcar2(10) not null,
UniIdxFiled varhcar2(10) ,
memo varchar2(10)
)
keyField is key filed ;
UniIdxFiled is UNIQUE INDEX field,but can null;
memo is a normal filed;


when i execute:

uniQuery1.sql.text:='select * from test';
UniQuery1.open;
Dbgrid1.datasoure.dataset:=UniQuery1;

then:
I update data by DbGrid1;

i Monitor the SQL:
it sometimes is :

Update memo =:memo where UniIdxFiled =:OLD_UniIdxFiled ;

I Think ,it must be:

Update memo =:memo where keyField =:OLD_keyField ;


becuause ,when UniIdxFiled is null;


Update memo =:memo where UniIdxFiled =:OLD_UniIdxFiled ;

will update more data that I won't update ;


So ,I hope the automatic SQL for update or delete 's condition Must be
Key fields;

if the tables has no Key fields , when can not use UniIdxFiled too.

because UniIdxFiled can be null sometimes;
you must use condition by KeyField,or UNIQUE INDEX field with can not null,or all fields that selects;

of cause:
i often write :select a.*,rowid from test ;
this update data is OK.

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Post by AlexP » Tue 07 Sep 2010 08:39

Hello,

Thank you for the information.
We have reproduced your issue.
We will notify you as soon as we have any results.

bork
Devart Team
Posts: 649
Joined: Fri 12 Mar 2010 07:55

Post by bork » Tue 12 Oct 2010 08:45

Hello

We fixed the bug with selecting Unique Key instead of Primary Key as a Key field for TOraQuery and TSmartQuery. But the issue with selecting Unique Key with fields that can be nullable is not solved, because it takes a lot of time to detect if Unique Key has nullable fields or not. This checking can decrease performance of all queries. If we find a way to detect Unique Key with nullable fields quickly, we will fix this issue.

daizhicun
Posts: 109
Joined: Thu 21 Jan 2010 11:49

Post by daizhicun » Sun 17 Oct 2010 11:45

i think it is not difficult. you can judge the old_key_value is null.
if is null , it can not as where condiction;

AlexP
Devart Team
Posts: 5530
Joined: Tue 10 Aug 2010 11:35

Post by AlexP » Tue 19 Oct 2010 06:18

Hello,

Now the WHERE section in the UPDATE statement is created only at first update call for the table, so if we checked values and generated the WHERE section for the first updating record correctly, we cannot be sure that the WHERE section will be correct for other records.
If we would recreate WHERE section for each record, it could decrease performance of all queries.
We will search the way to resolve the problem.

daizhicun
Posts: 109
Joined: Thu 21 Jan 2010 11:49

Post by daizhicun » Fri 22 Oct 2010 03:52

i see. this is not a good way now.

Post Reply