questions about parameter naming

[albourgz]

I have the following table:

Code: Select all

SQL> desc cec.gaches;
 Nom                                       NULL ?   Type
 ----------------------------------------- -------- ----------------------------
 IDGROUP                                   NOT NULL NUMBER(9)
 TYPE                                      NOT NULL NUMBER(9)
 SUBPRODUCT                                NOT NULL NUMBER(9)
 CNT                                                NUMBER(8)

where PK is (idgroup, type, subproduct).

I have this row:

Code: Select all

SQL> select * from cec.gaches where idgroup=1648670;

   IDGROUP       TYPE SUBPRODUCT        CNT
---------- ---------- ---------- ----------
   1648670          1      25896          3

In previous versions, in bcb 6, I had a TOraQuery with, as sql statement:

Code: Select all

UPDATE CEC.gaches SET CNT=CNT+:4 WHERE IDGroup=:1 AND SubProduct=:2 AND Type=:3

To fill in parameters: I did:

Code: Select all

OraQuery1->Prepare();
OraQuery1->Params->Items[0]->AsInteger=1648670;
OraQuery1->Params->Items[1]->AsInteger=25896;
OraQuery1->Params->Items[2]->AsInteger=1;
OraQuery1->Params->Items[3]->AsInteger=4;
OraQuery1->ExecSQL();
ShowMessage(AnsiString(OraQuery1->RowsAffected));
OraQuery1->Commit();

=> Displayed 1.
(items [0] referred to :1, [1] to :2, ...)

In bcb 2009 and odac 6.90.0.54, big change: he displays 0.
Why?
Params->Items[0] is assumed to be :4, [1] is :1, [2] is :2, [3] is :3.

To make it work as before I have to change code assigning parameters:

Code: Select all

OraQuery1->Params->Items[0]->AsInteger=4;
OraQuery1->Params->Items[1]->AsInteger=1648670;
OraQuery1->Params->Items[2]->AsInteger=25896;
OraQuery1->Params->Items[3]->AsInteger=1;

Is this behaviour normal? I thought that :1 :2 :3 could be used to access parameters by "position".


Regards,
Alain

[Challenger]

Order of parameters in collection depends on their order in SQL statement. Can you specify the version of ODAC that had such behavior?

[albourgz]

5.55.1.26 I think.

[Challenger]

We have tested the 5.55.1.26 version and saw the same behavior.