Subject | Re: [IBO] Weirdness ? |
---|---|
Author | Robert martin |
Post date | 2007-09-11T04:56:24Z |
Hi
We have still not solved this. However I now have another problem.
There is actually a trigger on this table that will update workref if it
is NULL. We are trying to use this to get around the issue. However the
component is giving us a validation error (Workref cant be Null). I
know their is a property to disable this checking but cant find it. I
have tried paramCheck = false and CheckRequired = False, but neither of
this have been successful.
Help :)
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Robert martin wrote:
We have still not solved this. However I now have another problem.
There is actually a trigger on this table that will update workref if it
is NULL. We are trying to use this to get around the issue. However the
component is giving us a validation error (Workref cant be Null). I
know their is a property to disable this checking but cant find it. I
have tried paramCheck = false and CheckRequired = False, but neither of
this have been successful.
Help :)
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Robert martin wrote:
> Hi
>
> I have an IBOQuery running the following query (Built in code)...
>
>
> INSERT INTO WorkNewItemExtraPricing (WorkRef, ControlRef, Svrreccnt,
> StockPriceTypeRef, SellPriceSys, SellPriceNoTax)
> SELECT GEN_ID(WorkControl_Gen, 1), ' + aControlref + ', ' +
> IntToStr(RecCount) + ', StockPriceTypeRef, SellPriceSys, SellPriceNoTax
> FROM WorkNewItemExtraPricing WHERE ControlRef = ' + aControlref + ' AND
> svrRecCnt IS NULL
>
> This is part of a loop where RecCount is incremented (aControlRef
> remains the same).
>
> The idea is that there are some base entries in the table (up to 4
> records) with the same ControlRef but a null svrreccnt. The code goes
> through a loop and duplicates these entries for each svrRccnt.
>
> At a random point in the loop the query fails to execute with a PK
> violation of the WorkRef field (the PK). I don't understand why this
> is? putting a dely into the code before the .execSQL command allows it
> to go further through the loop before encountering the PK violation.
>
> The SQL is in its own transaction.
>
> Any ideas? Or is this a Firebird thing (should I post to the Firebird
> list)?
>
>
>