Subject | Re: [IBO] please help IsModified cause Access Violation |
---|---|
Author | Helen Borrie |
Post date | 2007-01-10T07:51:08Z |
At 06:12 PM 10/01/2007, you wrote:
anything like the following?
procedure TForm1.IB_DataSource1DataChange(Sender: TIB_StatementLink;
Statement: TIB_Statement; Field: TIB_Column);
begin
if Field.FieldName = 'SAMPLE' and Field.IsModified then
with Statement do
begin
FieldByName('AnotherField').Value := SomethingCompatible;
FieldByName('................
..........;
end;
end;
There is a danger of this kind of thing going into a loop if your
OnDataChange procedure is targetting multiple fields, since the event
would fire again once your routine altered another field and moved
on. It's a valid approach sometimes but it does require some care...
Also make sure that your code is not attempting to assign values to
any fields that are non-updatable for any reason, e.g. derived
values, calculated fields or in any situation where you have joins
without any EditSQL or KeyRelation defined that permits a particular
field to be updated.
If these things don't seem applicable, show the code that's causing
the AV and also the addresses that are reported in the AV message.
Helen
>i am trying thisWell, you haven't shown the code that is causing the AV, but is it
>
>procedure TForm1.IB_DataSource1DataChange(Sender: TIB_StatementLink;
>Statement: TIB_Statement; Field: TIB_Column);
>begin
> if Field.FieldName = 'SAMPLE' and Field.IsModified then
> begin
> // modified another fields
> end;
>end;
>
>and AV comes.
>
>how to fix this?
anything like the following?
procedure TForm1.IB_DataSource1DataChange(Sender: TIB_StatementLink;
Statement: TIB_Statement; Field: TIB_Column);
begin
if Field.FieldName = 'SAMPLE' and Field.IsModified then
with Statement do
begin
FieldByName('AnotherField').Value := SomethingCompatible;
FieldByName('................
..........;
end;
end;
There is a danger of this kind of thing going into a loop if your
OnDataChange procedure is targetting multiple fields, since the event
would fire again once your routine altered another field and moved
on. It's a valid approach sometimes but it does require some care...
Also make sure that your code is not attempting to assign values to
any fields that are non-updatable for any reason, e.g. derived
values, calculated fields or in any situation where you have joins
without any EditSQL or KeyRelation defined that permits a particular
field to be updated.
If these things don't seem applicable, show the code that's causing
the AV and also the addresses that are reported in the AV message.
Helen