Subject | Re: [IBO] Help understanding query param anomaly |
---|---|
Author | ifitsx |
Post date | 2008-03-01T00:36:28Z |
Helen,
The problem isn't with the PK. I thought that it was initially, but it
was with a UNIQUE constraint that I had on a string field.
I removed that constraint - it wasn't logically appropriate anyway -
and discovered that no matter what I assign to that field's Param, the
original value assigned is maintained - which is what was
calling the error.
In other words, if I attempt to insert the following
(PK is generated in a trigger)
PK F1 F2
10 172 ABCD
11 173 EFGH
12 174 IJKL
what I get is
PK F1 F2
10 172 ABCD
11 173 ABCD
12 174 ABCD
Param[1] is always replaced with the value that was inserted
on the first insertion of the program cycle.
The variable that is used to assign the new value - which is the most
logical place to look for the problem - always reads as it should, and
so does the Param[1].AsString after it
receives it.
I've 'flushed' the component by preceding each insertion SQL with
a select SQL, opened it, and then closed it. This approach now gives
me the expected results:
PK F1 F2
10 172 ABCD
11 173 EFGH
12 174 IJKL
It seems ridiculous, but it's all I can use that works for now.
The problem isn't with the PK. I thought that it was initially, but it
was with a UNIQUE constraint that I had on a string field.
I removed that constraint - it wasn't logically appropriate anyway -
and discovered that no matter what I assign to that field's Param, the
original value assigned is maintained - which is what was
calling the error.
In other words, if I attempt to insert the following
(PK is generated in a trigger)
PK F1 F2
10 172 ABCD
11 173 EFGH
12 174 IJKL
what I get is
PK F1 F2
10 172 ABCD
11 173 ABCD
12 174 ABCD
Param[1] is always replaced with the value that was inserted
on the first insertion of the program cycle.
The variable that is used to assign the new value - which is the most
logical place to look for the problem - always reads as it should, and
so does the Param[1].AsString after it
receives it.
I've 'flushed' the component by preceding each insertion SQL with
a select SQL, opened it, and then closed it. This approach now gives
me the expected results:
PK F1 F2
10 172 ABCD
11 173 EFGH
12 174 IJKL
It seems ridiculous, but it's all I can use that works for now.