At 05:42 AM 1/03/2008, you wrote:

>I had been getting a unique key violation on an insert that I was
>unable to understand.
>
>I solved one part by removing the unique constraint on this string
>field that didn't really belong.
>
>But now I can also understand a bit more of why the violation was
>occuring:
>
>no matter what I pass to the query's param for the insert, what
>gets posted is the value that was inserted on the first execution
>of this insert query.
>
>I can read the data from the variable that is passed to the param
>and it is ok.
>
>I can read what appears to be in the param just prior to ExecSQL
>and it still appears to be ok.
>
>But what actually gets posted - for this field only - is the value
>that was posted on the component's first execution of the program
>cycle.
>
>I hope that there is just something about preparing or unpreparing
>or something like that which I need to understand.

If you are using a generator to populate your PK then decide whether you want IBO to get the value or you want the trigger to populate it.

-- if you want IBO to do it (recommended if you are using the dataset methods for your inserts) then set the GeneratorLinks property for this field at dataset level (MyPKFieldname=aGeneratorName) or at Connection level (myTable.MyPKFieldname=aGeneratorName)

-- if you want the trigger to populate your PK then set off the Required property of the PK field and write custom InsertSQL to exclude the PK (and/or other generated fields) from your INSERT statement

Ask further if you don't understand the mechanism here.

Helen