If your fields are dynamically created, (rather than created at design
time), then the probable cause of the AV is that the field you refer to
does not exist yet. OnDataChange is called by a range of changes in the
query, including changes which occur before the query is fully open.

The OnValidate field works because this called by the field, rather than
the query, and so the field always exists.

You can avoid the av in OnDataChange by putting in a test, such as "If
assigned(Field) then...

Roger Vellacott
Passfield Data Systems Ltd



-----Original Message-----
From: send2iwan [mailto:send2us@...]
Sent: 10 January 2007 08:31
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] please help IsModified cause Access Violation



thanks for reply. and that's very fast.

i just looking to:
http://tech.
<http://tech.groups.yahoo.com/group/IBObjects/message/18446>
groups.yahoo.com/group/IBObjects/message/18446

and try to make that code in my project and av comes.

but now i'm moving that code to onValidateField and it's works.

--- In IBObjects@yahoogrou <mailto:IBObjects%40yahoogroups.com> ps.com,
Helen Borrie <helebor@...> wrote:

>
> At 06:12 PM 10/01/2007, you wrote:
> >i am trying this
> >
> >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?
>
> Well, you haven't shown the code that is causing the AV, but is it
> 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
>