Subject | Performance tip: Naming of update SQL input parameters |
---|---|
Author | IBO Support List |
Post date | 2014-10-18T20:45:42Z |
All,
A few months back I had a bug reported where IBO was struggling with some
ambiguity in determining how to apply input parameter names of update SQL
statements to columns in a table where there were fields in the table that
had OLD_ as a prefix to them.
As you likely know, with update SQL statements using the OLD_ prefix on the
input parameter name indicated that the old value of the column should be
used when executing the statement. However, if you also have a column in
your table with OLD_ as a prefix (e.g. ID and OLD_ID) this was confuising
and ambiguous when trying to figure out if it used the OLD_ID value or the
ID column's old value.
So, to solve this problem, I included new schema cache data to be pulled in
from the metatdata to help deal with the ambiguity so that IBO would
function properly. Unfortunately, this adds in a little extra overhead,
which in some cases can be substantial if your database has a large number
of columns or stored procedure parameters.
Here's what to do to avoid the ambiguity altogether...
You are able to use the prefix of OLD. Just as you do in trigger code. In
this way IBO will know that you want the old column value and it won't get
confused if you also have columns named with OLD_ as a prefix. Therefore,
that extra data from the schema will not be pulled in.
So, for example, if you were using an EditSQL value of:
UPDATE MYTABLE T
SET T.ID = :ID
, T.COL = :COL
WHERE
T.ID = :OLD_ID
You would instead use this value:
UPDATE MYTABLE T
SET T.ID = :ID
, T.COL = :COL
WHERE
T.ID = :OLD.ID
Hope this helps!
Regards,
Jason Wharton
www.ibobjects.com
A few months back I had a bug reported where IBO was struggling with some
ambiguity in determining how to apply input parameter names of update SQL
statements to columns in a table where there were fields in the table that
had OLD_ as a prefix to them.
As you likely know, with update SQL statements using the OLD_ prefix on the
input parameter name indicated that the old value of the column should be
used when executing the statement. However, if you also have a column in
your table with OLD_ as a prefix (e.g. ID and OLD_ID) this was confuising
and ambiguous when trying to figure out if it used the OLD_ID value or the
ID column's old value.
So, to solve this problem, I included new schema cache data to be pulled in
from the metatdata to help deal with the ambiguity so that IBO would
function properly. Unfortunately, this adds in a little extra overhead,
which in some cases can be substantial if your database has a large number
of columns or stored procedure parameters.
Here's what to do to avoid the ambiguity altogether...
You are able to use the prefix of OLD. Just as you do in trigger code. In
this way IBO will know that you want the old column value and it won't get
confused if you also have columns named with OLD_ as a prefix. Therefore,
that extra data from the schema will not be pulled in.
So, for example, if you were using an EditSQL value of:
UPDATE MYTABLE T
SET T.ID = :ID
, T.COL = :COL
WHERE
T.ID = :OLD_ID
You would instead use this value:
UPDATE MYTABLE T
SET T.ID = :ID
, T.COL = :COL
WHERE
T.ID = :OLD.ID
Hope this helps!
Regards,
Jason Wharton
www.ibobjects.com