>Hi,
>Thank you for reply.
>
>>>If I understand correctly, you are calling an audit object from a form. I believe it is much better to have a trigger called from the table.
>
>No, I am calling audit object from triiger, ...

So far, it seems fine to me.

> ... but the object is created globally - main.prg

And what happens if you do changes from a BROWSE window? Your object won't be available.

My suggestion is to call a function, stored in the database stored procedures. That way, it will always be available. Well, perhaps you don't want to allow interactive changes, so this might be OK.

>Since the object is created in main.prg, so audit object is not able to access tables when I issue REPLACE/INSERT statement from form (private data session)

I don't fully understand what is happening to your object. However, I don't have this kind of problem, with a function called directly from the table trigger. The function just compares the field value with oldval(field) for each field in the table, and if there is a change, records it in the audit table. For me, this works without problems with private datasessions or interactive changes from the command window; and with both buffered and unbuffered data.